![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changes between Version 3 and Version 4 of Security01
- Timestamp:
- 18/10/09 19:49:10 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Security01
v3 v4 46 46 == Organization == 47 47 48 At this point i s 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.48 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. 49 49 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. 50 50 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: … … 71 71 * At least now, compromising a LISP+Alt router may compromise the mapping system 72 72 * Compromising an ETR may compromise mapping to the EID prefixes served by that ETR 73 73 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. 74 , 74 75 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. 75 76 77 === Mapping Integrity === 78 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: 79 * Mapping data is Provided by a party authorized to provide that data (authorization). 80 * Mapping data is not modified in transit (data integrity) 81 * EID prefixes are delegated to the party corresponding to the mapping result (delegation integrity). 82 * The RLOCs in the mapping result are valid ETRs for the EID prefixes (RLOC integrity). 76 83 84 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. 85 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. 77 86 78 79 80 81 === Mapping Integrity ===82 87 83 88 === Off path Attacks === 84 89 85 === Time Shifting, Replays and Preplays === 90 Requirement: The mapping system MUST NOT allow an an off-path attacker 91 to violate mapping integrity. An off-path attacker is an attacker who 92 is not on the path that legitimate mapping messages would take. 93 94 Justification: If an off-path attacker can violate mapping integrity, 95 then the attacker can change the topology, potentially gaining the 96 capabilities of an on-path attacker when mounting attacks in the 97 data-plane at LISP EIDs. See section 3 of RFC 3352. Such attacks 98 would also break assumptions described in section 3.1 of RFC 4218, and 99 violate the requirements of sections 3.1 and 3.2 of that document. In 100 other words, if LISP does not meet this requirement then LISP will not 101 live up to the bar we set for site multi-homing solutions. 102 103 Examples of this attack would include: 104 * 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 105 * 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. 106 107 108 === Time Shifting, Replays and Pre-plays === 109 110 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. 111 112 REQUIREMENT: The mapping system MUST limit the length of time over which time shifting and replay attacks are possible to some clearly specified bound. 113 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. 114 115 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. 116 117 REQUIREMENT: Mapping systems MUST describe any pre-play attacks and explicitly evaluate whether the pre-play attack is acceptable. 118 119 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. 86 120 87 121 === Denial of Service === … … 119 153 == related Security in the IETF == 120 154 155 * 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. 121 156 * 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. 122 * 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.157 * 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. 123 158 * RFC 5533's mechanisms for handling the security issues discussed in RFC 4218 is very interesting; section 16.2 is also interesting to consider. 124 159 * 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.
