Analyzing LISP Attacks: a Proposal

This page presents a proposed way to look at security threats to LISP. At this time, it is the individual opinion of those listed below. The goal is to get to something agreed to by a small, self-organized team, and then take it to the WG.

• Sam Hartman

If you agree with what's here now, feel free to add your name above and start contributing. If there are some issues you'd need to resolve first, then talk to those above and see if your ideas are on the same page enough to join this proposal. If not, please feel free to take our text , edit it somewhere else and get it to be something you agree with. You can also start completely from scratch or provide a set of deltas off of what's here. This is all an IETF contribution in the full sense of the appropriate BCPs.

Goals of LISP Security

• LISP will not make Internet security worse
• LISP will not create an architecture in which ongoing IETF-wide security goals such as the SIDR working group or BCP 84 are made more difficult.

The big question is what does it mean to make the Internet security worse and what is the current security model of the Internet. In answering these sorts of questions, we'll refer a lot to a number of IETF consensus documents. The point here is not to invoke a lot of past process, but simply to invoke descriptions of problems and ways of thinking about things that have received the consensus of the IETF or of some working group. We don't want to define this all ourselves, we want to build on what others have already done. We'll trying to distinguish BCP documents, which are presumed to have the consensus of the IETF, from informational documents, for which judging consensus is harder.

BCP 72, RFC 3552, provides summaries of classes of attacks. In section 3.1 of that document is a discussion of limited attacks; attacks can be categorized based on the capabilities that an attacker needs to have in order to mount them. While that document does not directly state this, the difficulty of the attack often depends on the capabilities required. So, one of the most important things to consider when evaluating whether LISP decreases the security of the Internet is whether it moves an attack from one category to another--for example, LISP would decrease the security of the Internet if LISP moved an attack from requiring an attacker to being on-path to permitting off-path attackers to mount that attack. Of particular interest is the discussion of topology in section 3.4.

Organization

At this point is unclear whether to organize the discussion around analyzing the security of the existing protocol or around security requirements. It would be better to describe things in terms of requirements, but that become too abstract. Where points can be made in terms of requirements, they will be. After requirements have been articulated, discussing specific attacks will almost certainly be useful. Even when discussing requirements, the requirements will be motivated by preventing classes of attacks. So, the motivation for a requirement or a specific attack will look similar. In each case, we describe:

• What prevents the attack on the Internet today?
• What (if any) previous IETF thinking suggests the attack is important to consider
• The consequences of the attack

Then we describe either the requirements or the attack.

Mapping in General

Mapping Integrity

Off path Attacks

Time Shifting, Replays and Preplays

Denial of Service

Mapping System In Specific

Between the ITR and the Map Resolver

The mapping system core

Between the Map server and the ETR

Between the ETR and the ITR

Data Plane

Denial of Service

Address Spoofing

Integrity of Control Information

related Security in the IETF

• RFC 4218 describes the threat analysis for site multihoming for IPv6 systems. Section 4 of this document is most applicable, although section 3 describes today's assumptions. While LISP was not a multi6 contender, almost all the analysis in this document also applies to LISP. It will need to be extended to IPv4 as well. While this document is informational, it did receive significant input.
• RFC 4225 describe the security design and background for Mobile IPv6 route optimization. While we're not exactly in the same space, the same concerns apply. This is again an informational document that received significant review.
• RFC 5533's mechanisms for handling the security issues discussed in RFC 4218 is very interesting; section 16.2 is also interesting to consider.
• RFC 4219 describes "things to think about" in IPv6 multihoming. While most of the security issues were broken out into RFC 4218, this is still a very important read.
• RFC 4889 section 4.8 and 5.8 may be useful.
• draft-bagnulo-shim6-ingress-filtering-01. may have been useful although it is ex pired; someone should read this and see if it has anything to say for LISP