12. Security Considerations
12. Security Considerations
It is believed that most of the security mechanisms will be part of the mapping database service when using control-plane procedures for obtaining EID-to-RLOC mappings. For data-plane-triggered mappings, as described in this specification, protection is provided against ETR spoofing by using route-returnability (see Section 3) mechanisms evidenced by the use of a 24-bit 'Nonce' field in the LISP encapsulation header and a 64-bit 'Nonce' field in the LISP control message.
The nonce, coupled with the ITR accepting only solicited Map-Replies, provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It is hard for off-path attackers to launch attacks against these LISP mechanisms, as they do not have the nonce values. Sending a large number of packets to accidentally find the right nonce value is possible but would already by itself be a denial-of-service (DoS) attack. On-path attackers can perform far more serious attacks, but on-path attackers can launch serious attacks in the current Internet as well, including eavesdropping, blocking, or redirecting traffic. See more discussion on this topic in Section 6.1.5.1.
LISP does not rely on a PKI or a more heavyweight authentication system. These systems challenge one of the primary design goals of LISP -- scalability.
DoS attack prevention will depend on implementations rate-limiting Map-Requests and Map-Replies to the control plane as well as rate-limiting the number of data-triggered Map-Replies.
An incorrectly implemented or malicious ITR might choose to ignore the Priority and Weights provided by the ETR in its Map-Reply. This traffic-steering would be limited to the traffic that is sent by this ITR's site and no more severe than if the site initiated a bandwidth DoS attack on (one of) the ETR's ingress links. The ITR's site would typically gain no benefit from not respecting the Weights and would likely receive better service by abiding by them.
To deal with map-cache exhaustion attempts in an ITR/PITR, the implementation should consider putting a maximum cap on the number of entries stored with a reserve list for special or frequently accessed sites. This should be a configuration policy control set by the network administrator who manages ITRs and PITRs. When overlapping EID-Prefixes occur across multiple Map-Cache entries, the integrity of the set must be wholly maintained. So, if a more-specific entry cannot be added due to reaching the maximum cap, then none of the less-specific entries should be stored in the map-cache.
Given that the ITR/PITR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance are issues to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. In general, it is difficult to defend against cache-thrashing attacks. It should be noted that an undersized cache in an ITR/PITR not only causes adverse effects on the site or region it supports but may also cause increased Map-Request loads on the mapping system.
"Piggybacked" mapping data as discussed in Section 6.1.3 specifies how to handle such mappings and includes the possibility for an ETR to temporarily accept such a mapping before verification when running in "trusted" environments. In such cases, there is a potential threat that a fake mapping could be inserted (even if only for a short period) into a map-cache. As noted in Section 6.1.3, an ETR MUST be specifically configured to run in such a mode and might usefully only consider some specific ITRs as also running in that same trusted environment.
There is a security risk implicit in the fact that ETRs generate the EID-Prefix to which they are responding. An ETR can claim a shorter prefix than it is actually responsible for. Various mechanisms to ameliorate or resolve this issue will be examined in the future [LISP-SEC].
Spoofing of inner-header addresses of LISP-encapsulated packets is possible, as with any tunneling mechanism. ITRs MUST verify the source address of a packet to be an EID that belongs to the site's EID-Prefix range prior to encapsulation. An ETR must only decapsulate and forward datagrams with an inner-header destination that matches one of its EID-Prefix ranges. If, upon receipt and decapsulation, the destination EID of a datagram does not match one of the ETR's configured EID-Prefixes, the ETR MUST drop the datagram. If a LISP-encapsulated packet arrives at an ETR, it SHOULD compare the inner-header source EID address and the outer-header source RLOC address with the mapping that exists in the mapping database. Then,
when spoofing attacks occur, the outer-header source RLOC address can be used to trace back the attack to the source site, using existing operational tools.
This experimental specification does not address automated key management (AKM). BCP 107 [RFC4107] provides guidance in this area. In addition, at the time of this writing, substantial work is being undertaken to improve security of the routing system [RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC]. Future work on LISP should address the issues discussed in BCP 107 as well as other open security considerations, which may require changes to this specification.