idnits 2.17.00 (12 Aug 2021) /tmp/idnits52521/draft-haddad-mext-enhanced-reachability-test-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 4815 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3792 (ref. 'CGA') ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-dupont-mipv6-rrcookie-05 == Outdated reference: A later version (-03) exists of draft-haddad-mipshop-netflood-defense-02 == Outdated reference: A later version (-01) exists of draft-haddad-csi-symbiotic-sendproxy-00 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions for IPv6 W. Haddad 3 (Mext) 4 Internet-Draft F. Dupont 5 Intended status: Standards Track ISC 6 Expires: September 9, 2009 March 8, 2009 8 Enabling an Enhanced Care-of Address Reachability Test for the Home 9 Agent 10 draft-haddad-mext-enhanced-reachability-test-03 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 9, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This memo aims to improve Mobile IPv6 protocol security by enabling 49 an enhanced care-of address rechability test for the home agent. The 50 main goals are to discourage a rogue mobile node from misleading its 51 home agent to flood a targeted foreign network and to empower the 52 latter to thwart this type of attack if launched at a later stage. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. Goals and Assumptions . . . . . . . . . . . . . . . . . . . . 5 59 4. Proposed Mechanism . . . . . . . . . . . . . . . . . . . . . . 6 60 5. New Options and Messages Formats . . . . . . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 Mobile IPv6 protocol (described in [MIPv6]) describes two different 70 modes for handling data packet exchange when the mobile node (MN) is 71 located in a foreign network. These two modes, namely the 72 bidirectional tunneling (BT) and route optimization (RO), have two 73 commonalities. The first one is the mechanism used to update the HA 74 after each IP handoff and requires the MN to send a binding update 75 (BU) message to its HA immediately after configuring a care-of 76 address (CoA). A second commonality is the HA's reaction upon 77 receiving a valid BU message and can be described as a blind trust in 78 the MN claim(s) regarding its new CoA(s). The common consequence is 79 that the HA will always tunnel data packets to the MN's new location 80 without conducting any reachability test on the new claimed CoA. 82 This memo aims first and foremost to avoid the potential consequences 83 of lack of CoA reachability test on the HA side. For this purpose, 84 it introduces an enhanced and seamless CoA test which makes launching 85 a network flooding attack complicated enough to discourage a rogue MN 86 from misleading its HA to flood a particular target. In addition, it 87 empowers the targeted network to thwart such attack if launched at a 88 later stage. 90 2. Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [TERM]. 96 3. Goals and Assumptions 98 The suggested work is motivated by two main goals. An explicit goal 99 is to improve MIPv6 overall security without increasing the signaling 100 message load on the MN. For this purpose, the key exchange in the 101 proposed mechanism is performed between the MN's HA and the new AR. 102 It should be noted here that repeating the same CoA reachability test 103 as the one which is periodically performed between the MN and its 104 CN(s), i.e., as part of the return routability procedure, will result 105 in a significant increase in the amount of signaling messages on the 106 MN side as it needs also to be repeated periodically in order to be 107 efficient. 109 The resulting improvement from the proposed mechanism should also 110 benefit other protocols which have been designed around MIPv6, e.g., 111 network mobility protocol (described in [NEMO]). Another goal is to 112 strengthen the network's ability to thwart network flooding attack 113 launched via the MN's HA by improving the network protective means, 114 in the same way as has already been suggested in the network flooding 115 defense mechanism (described in [NFD]) for the enhanced route 116 optimization (described in [ERO]). 118 Another implicit goal is to provide yet another strong incentive to 119 deploy the secure neighbor discovery protocol (described in [SeND]), 120 as the proposed mechanism assumes that SeND is deployed. This means 121 that the MN is CGA enabled (as described in [CGA]) and is able to 122 exploit all protective features provided by SeND on the link. 124 4. Proposed Mechanism 126 In order to address the issues and uncertainties described earlier, 127 we introduce in the following an enhanced secure and seamless CoA 128 reachability test which is triggered by the MN's HA upon receiving a 129 valid BU message from the MN. The suggested reachability test does 130 not directly involve the MN and does not affect the HA treatment of 131 the BU message (as described in RFC3775) nor does it increase the 132 overall latency. In fact, the suggested mechanism involves the MN in 133 three ways. The first one is not new as it has already been used in 134 NFD and consists on establishing a 'symbiotic' relationship (SR) with 135 the AR (described in [SRP]). The second requirement put on the MN is 136 to "partially" inform its HA about the new SR related to its claimed 137 CoA, its new AR's IP address, the AR's public key as well as 138 providing the HA a link to the AR's certificate. Clearly, these 139 information will be sent in the BU message and thus, require defining 140 new options. The third and last requirement is to send also the HA's 141 IPv6 address and its public key to the new AR. Again, this 142 information should be sent in new options carried in one message used 143 during a neighbor discovery protocol (described in [NDP]) exchange, 144 e.g., the router solicitation (RtSol) message. 146 Establishing an SR with the AR requires the MN to incorporate special 147 parameters in order to generate the 128-bit random parameter 148 (RAN(128)) to be used to configure its CGA address. As described in 149 the SRP mechanism, this means that the RAN(128) used together with 150 the MN's public key and other parameters to generate the 64-bit 151 interface identifier (IID) should in turn, be generated from the AR's 152 public key and another "inner" random 128-bit parameter 153 (I_RAND(128)). The MN should then encrypt the I_RAND(128) with the 154 AR's public key and send it to the AR in an NDP message signed with 155 the MN's CGA private key. In addition, the MN MUST also include the 156 HA's IPv6 address and may also provide the HA's public key. These 157 two parameters will be stored by the AR together with the MN's SR and 158 its public key. 160 On the HA side, the MN must include in the BU message the AR's IPv6 161 address, its public key and a link to its certificate, i.e., the same 162 as the one obtained by the MN when attaching to the AR link. In 163 addition, the MN must include in an encrypted form a 128-bit 164 parameter derived from hashing RAND(128) and called HRAND(128)). 166 As mentioned earlier, the design of the suggested CoA reachability 167 test should avoid increasing the latency. For this purpose, it is 168 highly recommended that the HA triggers the CoA reachability test 169 immediately after launching the DAD procedure for the MN's IPv6 home 170 address, following the receipt of a valid BU message. Triggering an 171 enhanced CoA reachability test requires the HA to send a new message 172 called "Binding Confirm Request (BCR)" to the MN's AR in which, it 173 must insert the MN's new claimed CoA, a nonce and disclose what it 174 knows about the SR established between the MN and its AR by 175 authenticating the message with HRAND(128). In addition, the HA MAY 176 sign the BCR message. 178 Upon receiving a BCR message, the AR starts first by checking if the 179 queried CoA is stored in its cache memory. Then it fetches the MN's 180 corresponding SR and uses it to validate the HA knowledge by checking 181 the message authenticity. If the HA's public key is available, and 182 only if the authentication is valid, then the AR proceeds to check 183 also the signature. If the authentication is valid (and the 184 signature if it is provided), then the AR should immediately reply by 185 sending a "Binding Confirm (BC)" message in which, it MUST insert the 186 nonce, authenticate it with HRAND(128) and sign it with its private 187 key. 189 When the HA gets a BC message from the AR, it starts first by 190 checking the nonce then validates the message authenticity. Then it 191 verifies the signature by using the AR's public key already stored in 192 the MN's corresponding entry. It becomes clear by now that the AR's 193 signature is a key feature as it allows the HA to validate the 194 certificate provided by the MN and provides a solid proof to the HA 195 about the AR's role and topological location. Hence, if the 196 signature is valid, then the HA can consider with enough confidence 197 that the MN has indeed visited the AR and exchanged NDP messages with 198 it and an SR has been accepted. Furthermore, it also serves as an 199 indication to the HA that the AR is now empowered to repel any 200 malicious behavior that can emanate from the MN, e.g., launching a 201 flooding attack at a later stage. It follows that the CoA 202 reachability test does not need to be repeated periodically. 204 After completing a successful reachability test, i.e., performed in 205 parallel with the DAD procedure in the home network, the HA starts 206 tunneling data packets to the MN's new CoA. As already mentioned, 207 the presence of the SR between the MN and its AR will prevent the MN 208 from moving away at some point, and launching a flooding attack by 209 keeping sending acknowledgment messages to the CN, e.g., using 210 another interface. In fact, in case such an attack is launched, the 211 AR will quickly detect the MN's absence on the link and securely 212 request the HA to halt the data packets flow to the MN's CoA. Note 213 that in our context, making a secure request to the HA implies that 214 the AR MUST send the SR established by the MN without encryption and 215 must sign the message with its private key. This also means that 216 processing such request on the HA side means that it has to check 217 first if the SR is valid by hashing it and comparing the hash to the 218 corresponding HRAND(128). 220 5. New Options and Messages Formats 222 TBD 224 6. Security Considerations 226 This document introduces an enhanced and seamless CoA reachability 227 test especially designed to be used by the HA in order to check the 228 MN's topological location and compare it to the claimed CoA. In 229 fact, the proposed mechanism enables to address uncertainties 230 surrounding a potential network flooding threat in MIPv6 protocol as 231 well as in its derivative(s). Consequently, the main goal is to 232 improve the security in MIPv6 in a way which does not directly 233 involve the MN and does not require a periodic exchange of signaling 234 messages. 236 The proposed mechanism is inspired from the NFD mechanism which is 237 tightly based on the SR concept to enable replacing the periodic CoA 238 reachability test on the CN side. In other words, the presence of an 239 SR does not require adding new parameters in order to secure the 240 exchange between the HA and the AR, although this is possible. 242 Our suggested protocol also assumes that the HA is always interested 243 in validating the MN's claimed CoA prior to any data traffic 244 redirection to the new claimed CoA. Such assumption severely limits 245 the MN's manoeuvrability room for bypassing such test since the 246 absence of any information regarding the AR and SR in the BU message 247 will lead the HA to test the MN's CoA reachability using a state 248 cookie as described in [CTSC], i.e., by asking the MN directly upon 249 receiving a valid BU message. In such scenario, if the MN has 250 established an SR with the AR but avoided disclosing it to its HA, 251 then it will have to answer the reachability test by itself which 252 implies sending an additional mobility signaling message. Otherwise, 253 i.e., in the absence of an SR, the AR won't forward the message sent 254 by the HA to its final destination in which case, the MN won't be 255 able to answer the reachability test nor to get its data traffic. 256 This also means that the MN won't be able to launch any attack as it 257 will be practically considered by the AR as non-existing on its link. 259 7. References 261 7.1. Normative References 263 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 264 RFC 3792, March 2005. 266 [ERO] Vogt, C., Arkko, J., and W. Haddad, "Enhanced Route 267 Optimization for Mobile IPv6", RFC 4866, June 2006. 269 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 270 for IPv6", RFC 3775, June 2004. 272 [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 273 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 274 September 2007. 276 [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 277 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 278 January 2005. 280 [SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. 281 Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971, 282 March 2005. 284 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 285 Requirement Levels", RFC 2119, BCP , March 1997. 287 7.2. Informative References 289 [CTSC] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 290 using a State Cookie", Internet 291 Draft, draft-dupont-mipv6-rrcookie-05.txt, November 2007. 293 [NFD] Haddad, W. and M. Naslund, "On Using 'Symbiotic 294 Relationship' to Repel Network Flooding Attack", Internet 295 Draft, draft-haddad-mipshop-netflood-defense-02.txt, 296 October 2008. 298 [SRP] Haddad, W. and M. Naslund, "On Secure Neighbor Discovery 299 Proxying Using 'Symbiotic' Relationship", Internet 300 Draft, draft-haddad-csi-symbiotic-sendproxy-00.txt, 301 October 2008. 303 Authors' Addresses 305 Wassim Haddad 306 US 308 Phone: +1 646 2568041 309 Email: wmhaddad@gmail.com 311 Francis Dupont 312 ISC 314 Email: Francis.Dupont@fdupont.fr