idnits 2.17.1 draft-saucez-lisp-mapping-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 20, 2011) is 4806 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-09 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-05 == Outdated reference: A later version (-03) exists of draft-saucez-lisp-security-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Saucez 3 Internet-Draft O. Bonaventure 4 Intended status: Informational Universite catholique de Louvain 5 Expires: August 24, 2011 February 20, 2011 7 Securing LISP Mapping replies 8 draft-saucez-lisp-mapping-security-00 10 Abstract 12 The security of the mappings is crucial for the success of the 13 Locator/Identifier Separation Protocol (LISP). This draft discusses 14 two options to allow LISP xTR to verify the authenticity of LISP Map- 15 Replies. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 24, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Mapping security levels . . . . . . . . . . . . . . . . . . . 4 65 3. Requirements to secure Mapping information . . . . . . . . . . 4 66 4. Mapping Authentication Mechanisms . . . . . . . . . . . . . . 6 67 4.1. Mapping Authenticity Base . . . . . . . . . . . . . . . . 6 68 4.2. Signed Mappings . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 The Locator/Identifier Separation Protocol (LISP) is currently being 78 developed with the LISP IETF working group [I-D.ietf-lisp]. LISP can 79 be conceptually divided in two different parts : 81 o LISP data plane that defines the format and the processing of LISP 82 encapsulated packets on xTRs 84 o LISP control plane that defines how an ITR obtains mapping 85 information about a destination EID and manages this information. 87 The LISP control plane plays a key role from a security viewpoint in 88 the entire operation of LISP. LISP xTRs exchange mapping information 89 by using Map-Requests and Map-Replies. It is important to note that 90 the LISP control plane messages are used for three different purposes 91 by ITRs and ETRs: 93 o When a LISP ITR does not know any mapping information for an EID, 94 it sends a LISP Map-Request through the LISP Mapping system. The 95 LISP Mapping system will ensure that the LISP Map-Request will 96 reach a LISP Mapping Server or a LISP ETR that is authoritative 97 for the requested EID. A LISP ETR will then send a LISP Map-Reply 98 directly to the originating LISP ITR. 100 o When a mapping information times out on a LISP ITR, the ITR will 101 need to refresh the mapping by either sending a LISP Map-Request 102 through the LISP Mapping System or directly to one of the LISP ETR 103 that is responsible for the expired mapping. One of the 104 authoritative LISP ETR will then send a LISP Map-Reply directly to 105 the originating LISP ITR. 107 o A LISP ITR may send a LISP Map-Request directly to a LISP ETR to 108 verify its reachability. The ETR will confirm its reachability by 109 sending a LISP Map-Reply back. 111 The security of the LISP control plane is crucial for the security of 112 LISP. A detailed discussion on the security of LISP may be found in 113 [I-D.saucez-lisp-security]. The current LISP specifications do not 114 provide a secure LISP Mapping System. The ALT [I-D.ietf-lisp-alt] 115 Mapping system relies on BGP sessions established manually over 116 tunnels between LISP xTRs and LISP Mapping Servers. ALT assumes that 117 such a mapping system will be secure since it is operated by trusted 118 operators. Unfortunately, the experience with BGP on the global 119 Internet has shown that this is not a valid assumption and that 120 additional techniques are required to secure a routing system that 121 relies on BGP. 123 This document is organized as follows. In Section 2 we present the 124 different levels of security that can be provided and analyze their 125 respective advantages and drawbacks. In Section 4 we discuss several 126 families of solutions that can be designed to improve the security of 127 the LISP control plane. 129 2. Mapping security levels 131 The level security of a mapping is determined by the level of 132 confidence that a LISP xTR can have on information obtained through 133 it. 135 By using nonce mechanism as described in the LISP specifications, a 136 LISP ITR can be confident that a Map-Reply it receives has been sent 137 by the LISP ETR that it queried. This is relevant when an ITR sends 138 a Map-Request directly to a LISP ETR that it already knows. However, 139 when a LISP ITR sends a Map-Request through the LISP mapping system, 140 the Map-Reply may come from any LISP ETR and that fact that it 141 contains the same nonce as in the LISP Map-Request only proves that 142 it was generated in response to a specific Map-Request. Indeed, the 143 64-bits nonce that must be returned by the ETR mitigates the risk of 144 injection attacks where an attacker inject Map-Replies containing 145 invalid information. Unfortunately, if the attacker is on path, it 146 may intercept the Map-Request and extract its nonce. It can then 147 generate a Map-Reply that looks authentic for the ITR as the nonce in 148 the reply is valid. The nonce thus provides only a simple way of 149 authenticating the Map-Replies when man-in-the middle attacks are not 150 possible. 152 If messages can be tampered, or if man-in-the middle attacks are 153 possible, or if the mapping system may be abused to deliver to a 154 hostile ETR a Map-Request sent by an ITR, we need a better security 155 than the nonce. 157 3. Requirements to secure Mapping information 159 LISP Map-Reply messages contain several types of mapping information. 160 In this section, we evaluate the security risks if an attacker is 161 able to inject invalid mapping information. We consider that the 162 LISP nonce protects against injection of Map-Reply messages by an 163 off-path attacker and discuss two types of attackers: 165 An attacker that temporarily resides on the path between an ITR and 166 an ETR and is able to perform a man-in-the-middle attack by modifying 167 Map-Reply messages exchanged between these xTRs. We call this 168 attacker the on-path attacker in this document. 170 A malicious xTR or LISP-MS that receives legitimate Map-Request 171 messages from ITRs but returns crafted Map-Reply messages. We call 172 this attacker the malicious xTR in this document. 174 The mapping information and their associated security risk is 175 presented below: 177 o EID prefix and mask length. By changing the EID prefix in a Map- 178 Reply message, an on-path attacker could cause denial of service 179 attacks of blackhole traffic by placing in the Map-Reply message a 180 less specific EID prefix than in the original Map-Reply. A 181 malicious xTR could also return a less specific prefix and 182 blackhole traffic. 184 o Locator. The locators are probably the most important information 185 in the LISP Map-Reply messages since they indicate where 186 encapsulated packets should be sent to reach a given EID prefix. 187 By changing locators, an on-path attacker could redirect traffic 188 to another LISP ETR where it can perform man-in-the-middle attacks 189 on encapsulated packets more easily. By injecting incorrect 190 RLOCs, a malicious xTR could also redirect encapsulated traffic to 191 a LISP ETR where it can easily perform a man-in-the-middle attack. 193 o Priority and Multicast Priority. If an attacker is able to change 194 the priority associated to a locator in a mapping, it could force 195 an ITR to send encapuslated packets over another path than the 196 intended path. It can also make any RLOC unused by setting it a 197 255 priority. 199 o Weight and Multicast Weight. This field is used to influence how 200 load balancing should be performed when several locators have the 201 same priority. By changing weight, an attacker could move 202 encapsulated packets over different paths. 204 o Record TTL. By lowering the record TTL, an attacker could force 205 an ITR to send more frequently Map-Request messages. By 206 increasing the record TTL, an attacker could ensure that a fake 207 mapping information is used for a longer time by its victim. A 208 temporarily on-path attacker could use a long record to ensure 209 that a malicious mapping remains in the victim ITR EID-to-RLOC 210 cache for a long period of time. 212 o Version. By changing the Version of a mapping, an attacker could 213 trigger a loop of mapping updates at the ITR. Indeed, if the 214 version is invalid, when the ITR receives a packet from the EID it 215 received the mapping for, it will send a Map-Request as the 216 version does not correspond. If the attacker can control the 217 version of the Map-Reply, this scheme can be repeated 218 indefinitely. 220 o Reachability. If an attacker is able to change the reachability 221 bit associated to a locator, it could force a LISP ITR to test the 222 reachability of this locator. 224 Based on the analysis above, the most critical information in the 225 mapping placed in LISP Map-Reply messages are the EID prefixes and 226 the locators. From a security viewpoint, it is important for a LISP 227 ITR to be able to verify the validity of the link between an EID 228 prefix and a set of locators. 230 4. Mapping Authentication Mechanisms 232 To authenticate the mappings, several techniques can be used. 233 Authenticating mapping information is similar to validate DNS 234 responses and also related to the validation of BGP prefixes in the 235 global interdomain routing system. In this section, we discuss the 236 applicability of two techniques that have been designed to secure 237 interdomain routing to secure LISP mappings. 239 4.1. Mapping Authenticity Base 241 The first technique that was developed to verify the authenticity of 242 BGP announcements are the prefix allocation databases maintained by 243 the Regional Internet Registries. Each RIR maintains a database, 244 typically in RPSL format, that contains the list of all the prefixes 245 that have been allocated to a given AS. An AS can use this 246 information to verify the received BGP advertisements. Some 247 operators use filters that are automatically derived from the RIR 248 databases and installed on their BGP import filters. Experience 249 shows that this method works reasonably well in some regions and that 250 it is able to prevent misconfiguration problems. However, it can be 251 difficult to maintain the RIR databases up-to-date. 253 The allocation of EID prefixes by RIRs has not yet been precisely 254 discussed within the LISP working group, but a possible approach 255 could be as follows. Sites obtain EID prefixes from a RIR or a LIR 256 and register on the RIR database the locators of the ETR that serve 257 each allocated EID prefix. The list of locators that are associated 258 to an EID prefix is only the list of the potential locators. The RIR 259 database, unlike the NERD mapping system would not contain detailed 260 information about the mapping such as priorities or weights. This 261 information may change with time and should be obtained by querying 262 the mapping system. 264 When an ITR needs a mapping for an EID prefix that it does not know, 265 it queries the mapping system as usual and receives an 266 unauthenticated Map-Reply. Two techniques could be developed to 267 allow the ITR to verify the validity of the received Map-Reply based 268 on the information stored in the RIR databases. A first option is 269 that the network administrator that is responsible for an ITR 270 downloads regularly the RIR database and derives filters for all the 271 valid pairs of EID prefix - RLOC. These filters are regularly pushed 272 on the LISP ITRs and are used to verify each received LISP Map-Reply. 273 A second solution is to allow each LISP ITR to directly query the RIR 274 database by using either an existing protocol such as whois or a new 275 protocol to be developed. This allows the ITR to verify in realtime 276 the LISP Map-Replies that it receives, but imposes a possibly high 277 load on the RIR databases. 279 The advantage of using the RIR databases is that there is already a 280 lot of operational experience with them. However, the load on the 281 RIR databases can be high. Furthermore, updating the RIR databases 282 might be difficult for LISP ETRs that use dynamic routing locators, 283 e.g. RLOCs assigned by DHCP. 285 4.2. Signed Mappings 287 The Mapping Authenticity Base approach has the advantage of keeping 288 the Map-Reply processing light at the ITR and the ETR. 289 Unfortunately, running the authenticity base could cause 290 administrative and cost overhead and the system has still some 291 security weaknesses. 293 Instead of using a separated infrastructure to authenticate the 294 mappings, we can embed the authentication scheme directly in the 295 mapping messages. With this approach, each mapping message is 296 signed. 298 To reduce the processing at the ETR, we will consider that only the 299 Map-Replies are signed. We still have to determine if it is required 300 to authenticate the Map-Requests. 302 Depending on the security level that has to be reached, different 303 part of the mapping have to be signed. 305 Adding a field in the Map-Reply that is the signature of the hash of 306 the ETR address and the nonce is not sufficient as it does not 307 protect against tempering, it only confirms that the Map-Reply has 308 been initially generated by the appropriated ETR the content may have 309 been tempered. 311 For a higher level of security, a certificate has to be used, the 312 certificate gives the EID prefix and the proof that the EID prefix 313 belongs to the ETR (e.g., the certificate is signed by a well-known 314 EID registry). A field is added to the Map-Reply and contains the 315 signature of the hash of the ETR address, the nonce and the EID 316 prefix. This signature prove that the EID prefix belongs to the ETR 317 and that the correct ETR has been queried. The set of RLOCs and the 318 mapping attributes may still have been tempered. 320 To also prove that the locators are valid and thus avoid divert 321 traffic attacks, the same principle as before can be followed but the 322 certificate adds the list of valid RLOCs for the EID prefix. The 323 signature covers the ETR address, the nonce, the EID prefix and the 324 RLOCs. 326 To reach an ultimate security level, the technique from above can be 327 used but it has to be applied to all the mapping fields, the ETR 328 address and the nonce. 330 When signing the entire message improves the security by virtually 331 prohibiting any modification of the message, it can cause an 332 important overhead at the ETR and the signature cannot be pre- 333 computed (i.e., the nonce makes the message changing every time. On 334 the contrary, signing only some parts of the message could allow one 335 to pre-compute the signature and thus make the generation of a Map- 336 Reply not more complex than the generation of a Map-Reply without a 337 signature. 339 An attack can at most replay a mapping that has been valid in the 340 past. The injection of old mappings by attackers can be mitigate if 341 the certificate associated to the mapping are limited in time. This 342 expiration date has to be set accordingly to the security needs of 343 the site generating the mapping. 345 When the signature does not cover the all message, pre-computation 346 can be used to compute the signature. In this case, the signature is 347 computed when the mapping is installed in the local mapping database. 349 The pre-computation of the signature allows to avoid the cost of 350 computing the signature at each request on the ETRs and thus make the 351 ETR insensible to DDoS attacks that could target an ETR by asking it 352 to perform time consuming cryptography operations. 354 The validation of the signature at the ITR is always present but its 355 impact is limited compared to doing signatures at the ETR on the fly. 356 In addition, if the ITR is overloaded, it could decide to postpone 357 the authenticity check but use the mapping anyway. 359 We can also propose intermediate security level where only some part 360 of the mapping are authenticated. We suggest to cover the TTL, the 361 EID prefix and the list of [locator, priority, weight] tuples. We 362 removed the reachability information from the authentication as it is 363 more volatile than the mappings and signature computation would be 364 triggered after every reachability change. At a first glance, not 365 signing the reachability seems to be a mistake because an attacker 366 could set all the reachability bit of each RLOC to zero and thus 367 block the traffic. However, as for locator status bits, we are 368 considering this information as a hint, a reachability change has to 369 be validated first with a reachability algorithm before effectively 370 considering the reachability change. Indeed, the reachability is a 371 local consideration. 373 5. Security Considerations 375 This document is entirely devoted to the security 377 6. Conclusion 379 TO DO 381 7. Acknowledgments 383 The authors would like to gratefully acknowledge Luigi Iannone for 384 his insights. 386 8. Informative References 388 [I-D.ietf-lisp] 389 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 390 "Locator/ID Separation Protocol (LISP)", 391 draft-ietf-lisp-09 (work in progress), October 2010. 393 [I-D.ietf-lisp-alt] 394 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 395 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-05 396 (work in progress), October 2010. 398 [I-D.saucez-lisp-security] 399 Saucez, D., Iannone, L., and O. Bonaventure, "LISP 400 Security Threats", draft-saucez-lisp-security-01 (work in 401 progress), July 2010. 403 Authors' Addresses 405 Damien Saucez 406 Universite catholique de Louvain 407 Place St. Barbe 2 408 Louvain-la-Neuve, B-1348 409 Belgium 411 Email: damien.saucez@uclouvain.be 412 URI: http://inl.info.ucl.ac.be 414 Olivier Bonaventure 415 Universite catholique de Louvain 416 Place St. Barbe 2 417 Louvain-la-Neuve, B-1348 418 Belgium 420 Email: olivier.bonaventure@uclouvain.be 421 URI: http://inl.info.ucl.ac.be