[secdir] SECDIR review of draft-ietf-lisp-16

[Matt Lepinski <[e-mail]>]

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document is the core LISP specification. It specifies the basic operation of LIST ITRs (Ingress Tunnel Router) and ETRs (Egress Tunnel Routers) as well as the syntax for LISP mapping messages which the ITR uses to determine to which ETR it should tunnel a packet in order to reach a given endpoint. This document describes a basic mode of operation where LISP mapping messages are sent over the standard Internet routing topology.

After reading this document, I believe that "poisoning" of the mapping cache (i.e., placing false entries in the mapping cache) is not adequately addressed in the security considerations of this document. I accept that the use of a nonce and return-routability checks to reduce the ability of an off-path adversary to get false mapping data into the mapping cache. However, I believe there are still significant residual vulnerabilities that are not adequately addressed in the security considerations.

For instance consider the following scenarios in which an adversary can get "false" mappings accepted into an ITR's mapping cache. (My apologies if I misunderstood the specification in one of the following scenarios)
-- The adversary is on the path for a mapping reply from an ETR to an ITR. The adversary alters the mapping response, leaving the nonce unchanged, but placing its own IP address as the "locator" in the record being returned.
-- The adversary is on the path for a mapping request from an ITR to an ETR. Instead of forwarding the mapping response, the adversary fabricates a reply to the mapping request with its own IP address as the "locator" in the record being returned.
-- The adversary believes that it is likely on the path from a particular ETR X to some EID Y. The adversary sends a LISP encapsulated data packet with Y as the source of the inner data packet, and the adversary itself as the source of the outer LISP encapsulating header. In such a case, the ETR may "glean" the mapping that the adversary is the TR responsible for EID Y. It will then "verify" (See Section 6.2) this mapping by sending a map-request to EID Y. If the adversary is correct and is indeed on the path of this map-request, then the adversary poisons the mapping cache as in the previous case.

Note that all of the above vulnerabilities require that the adversary be on the path of some LISP packet. The security considerations of the document states that attacks by on-path adversaries aren't an issue because on-path adversaries can already do lots of bad things in the current internet routing architecture. However, I believe that "poisoning" the mapping cache is new capability that provides additional capabilities to an on-path adversary that do not exist in today's non-LISP Internet. In particular, Internet routing is transient in the sense that if an adversary is on the path of particular packet between A and B, it is likely that there will be many future packets between A and B for which the adversary is not on the path. However, if the adversary can get a "false" mapping entry accepted into a mapping cache with a long TTL, then the adversary can ensure that he is on the path between all future packets until the TTL expires.

The benefit that an adversary derives from "poisoning" a mapping cache is that by being on the path between an ITR and some EID, he can put himself on the path for all traffic to a prefix that contains the EID. (That is, by being on the path to 10.0.98.116, an adversary can become on an on-path attacker for all traffic to 10.0/16). This vulnerability is related to the discussion in 6.1.5.1, (Note to authors, please place a reference to Section 6.1.5.1 in your security considerations section.) however, as long as this vulnerability exists, it gives an on-path adversary additional capability beyond what such an adversary could accomplish on a non-LISP Internet.

Finally, I believe that the capabilities on an "on-path" attacker are especially cause for concern when mapping requests and responses are routing using an alternative topology. (My apologies if I have misunderstood draft-ietf-lisp-alt). In particular, it seems that if an adversary is "on the path" that a mapping request for EID Y from ITR X follows in the alternative topology, then he can poison the cache of ITR Y and become an on-path attacker for all future traffic from ITR X to EID Y ... even though the adversary was never on the path to EID Y in the standard topology. (And again, the adversary isn't just putting himself on the path to EID Y, he's putting himself on the path to all traffic in some prefix containing EID Y.) This final case is particularly troubling to me because I am concerned about the case where it is easier for an adversary to insert himself into an Alternative topology path (by attacking the routing protocol) than it is for him to insert himself into a standard topology path. For instance, the SIDR working group has recently completed work (RFC editor's queue) that can provide protection against a certain class of mis-origination attacks on BGP using a Resource Public Key Infrastructure. If this technology were employed to protect certain autonomous systems in the standard topology, the use of LISP-ALT would seem to defeat such protection by allowing the adversary to perform the mis-origination attack in the alternative topology to by-pass the protection implemented in the standard topology.

One last note to the authors, in the first paragraph of the security considerations where off-path adversaries are discussed, it would be helpful to reference the specific section where you discuss return-routability mechanisms for data-plane-triggered mappings. (It wasn't clear to me the first time I read that, what exactly you were referring to and so a reference back to earlier text would be helpful.)

Thanks
- Matt Lepinski