wiki:Security01

Version 4 (modified by hartmans-ietf@…, 13 years ago) (diff)

--

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 it 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

Attacks on the Internet mapping system are generally considered quite serious. Many higher layers distinguish between on-path and off-path attacks, so the ability to change the topology so that you, as an attacker, are on-path is valuable. Similarly, ingress and egress filtering establish security barriers that help prevent attacks, so being able to attack the mapping system and change the topology to appear to be inside a particular address range can be valuable. Se RFC 3552 section 3.4.

Today's Internet mapping system involves several components:

  • ARP or Neighbor Discovery handles on-link mapping.
  • The local IGP (OSPF, ISIS, etc) handles mapping within an organization
  • BGP handles global Internet mapping

In general, ARP and ND are fairly easy to attack in most environments. As a result, it is often possible for one node on a link to attack the mapping system and receive packets destined for another node on the link. In addition some link types allow every node on a link to observe packets.

However, some environments do require mechanisms to protect against these attacks; RFC 3971 specifies mechanisms to protect neighbor discovery. The mechanisms for protecting ARP are more ad-hoc and typically focus more around configuration choices than a cryptographic protocol, but they do exist and are important in some environments.

It's generally easy for an attacker who compromises a router to compromise the mapping system, at least within a limited domain. There is work under way in the SIDR working group to look at reducing the trust placed in each router, but that is fairly long-term work. In LISP terms, this probably means that:

  • At least now, compromising a LISP+Alt router may compromise the mapping system
  • Compromising an ETR may compromise mapping to the EID prefixes served by that ETR That is, we propose to describe these attacks as residual threats for LISP+Alt and LISP respectively. It is an open question when we will require that a mapping system do better than the security model of Lisp+Alt today: it seems that the IETF is headed down the path that may eventually lead to making stronger requirements for BGP security. Presumably these requirements would also apply to LISP+Alt. So, the set of desired security properties for a mapping system are likely to be stronger than we expect to get with LISP+Alt without something SIDR-like in LISP+Alt.

, However, ETRs should not be trusted so much that compromising one ETR leads to compromising the mapping of unrelated EID prefixes, just as compromising most customer site routers does not involve compromising mapping of addresses belonging to other customers.

Mapping Integrity

The primary security goal of the mapping system is to provide integrity protection for mapping data. The consumer of mapping data wants the assurance that:

  • Mapping data is Provided by a party authorized to provide that data (authorization).
  • Mapping data is not modified in transit (data integrity)
  • EID prefixes are delegated to the party corresponding to the mapping result (delegation integrity).
  • The RLOCs in the mapping result are valid ETRs for the EID prefixes (RLOC integrity).

Together these properties can be thought of as mapping integrity. The final two properties (delegation and RLOC integrity) can be thought of as part of the authorization decision: we can think of an ETR is being authorized to map its EID prefixes to a particular set of RLOCs. However in this discussion, we will decompose the three aspects of authorization: is an approved party generating the mapping information, is the mapped prefix delegated, and is that prefix actually reachable by the RLOCs in question. Whenever we talk about authorization, the question of authentication also comes up. In order to discuss whether an appropriate party is authorized, we need to think about how the authenticated identity of that party is known.

Off path Attacks

Requirement: The mapping system MUST NOT allow an an off-path attacker to violate mapping integrity. An off-path attacker is an attacker who is not on the path that legitimate mapping messages would take.

Justification: If an off-path attacker can violate mapping integrity, then the attacker can change the topology, potentially gaining the capabilities of an on-path attacker when mounting attacks in the data-plane at LISP EIDs. See section 3 of RFC 3352. Such attacks would also break assumptions described in section 3.1 of RFC 4218, and violate the requirements of sections 3.1 and 3.2 of that document. In other words, if LISP does not meet this requirement then LISP will not live up to the bar we set for site multi-homing solutions.

Examples of this attack would include:

  • If the wrong party could successfully issue a map register for a prefix, that would be an off-path attack on mapping integrity. Today, the MAC in the map register message provides protection against this attack
  • draft-bagnulo-lisp-threat-01 section 3.1 describes off-path attacks on mapping integrity. The attack threats have been reduced somewhat since that draft was published by minimizing data gleaning.

Time Shifting, Replays and Pre-plays

A time shifting attack allows an attacker who was previously on-path to mount attacks than an off-path attacker cannot normally mount. A replay attack allows an attacker to replay some protocol mechanism and gain some advantage. In the context of the mapping system, a replay would allow an attacker to replay old mapping information that created an advantage for the attacker. A pre-play attack allows an on-path attacker to gain some advantage by responding before some other party.

REQUIREMENT: The mapping system MUST limit the length of time over which time shifting and replay attacks are possible to some clearly specified bound.

The mapping system MUST either avoid replay attacks entirely or explain why permitting a particular replay attack within a limited time bound provides an overall improvement in the system design.

Justification: Long term replay attacks can allow a party to violate mapping integrity long after an update. Attackers could become on-path on the data plane. In addition, errors or past security compromises can be impossible to correct if these attacks are not bounded. Section 4.1.2 of RFC 4218, section 4.1.4 of RFC 4218 and section 3.1.6 of RFC 4225 discuss previous IETF thinking on time-shifting and replay attacks in mapping protocols. The conclusions are similar.

REQUIREMENT: Mapping systems MUST describe any pre-play attacks and explicitly evaluate whether the pre-play attack is acceptable.

Justification: Forbidding pre-play attacks could prove very difficult. However depending on the deployment model, being on-path may imply much less trust at certain points than others. So on-path attacks like pre-play attacks may be important to consider in some situations.

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

Interworking

Address Spoofing

Denial of Service

Theft of Service

Multicast

related Security in the IETF

  • draft-bagnulo-lisp-threat-01 describes oa preliminary threat analysis of the LISP data plane. Some attacks described have been fixed; others are still present. The structure of the document and the method of analysis are very valuable.
  • 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 describes 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