idnits 2.17.1 draft-dupont-ipsec-mipv6-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The abstract seems to contain references ([1-6], [8], [10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 150: '...*authentication) MUST be accepted (i.e...' RFC 2119 keyword, line 151: '... *as verifiable) and the HAO MUST be considered as verified [12]...' RFC 2119 keyword, line 170: '... in Tunnel mode and Mobile IPv6 SHOULD...' RFC 2119 keyword, line 188: '... SA lookup and the source address MUST...' RFC 2119 keyword, line 222: '...essing against the SA selector MUST be...' (61 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2004) is 7368 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) -- Looks like a reference, but probably isn't: '1-6' on line 49 == Missing Reference: '14' is mentioned on line 765, but not defined == Missing Reference: '15' is mentioned on line 788, but not defined == Missing Reference: '16' is mentioned on line 783, but not defined == Missing Reference: '17' is mentioned on line 823, but not defined == Missing Reference: '18' is mentioned on line 792, but not defined == Missing Reference: '19' is mentioned on line 865, but not defined == Missing Reference: '20' is mentioned on line 899, but not defined ** Obsolete normative reference: RFC 2401 (ref. '1') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '2') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '3') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '4') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. '6') (Obsoleted by RFC 4306) -- No information found for draft-haddad-mip6-bub - is the name correct? Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Francis Dupont 2 INTERNET DRAFT ENST Bretagne 3 Expires in August 2004 Wassim Haddad 4 Helsinki University of Technology 5 February 2004 7 How to make IPsec more mobile IPv6 friendly 9 11 Status of this Memo 13 This document is an Internet Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "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 Distribution of this memo is unlimited. 35 Abstract 37 IPsec specifications [1-6] do not work well with any mobility 38 device based on addresses [8]. Mobile IPv6 interaction with IPsec 39 is still far from being well achieved. This is mainly due to bad 40 interpretations of IPsec specifications. HIP (Host Identity 41 Payload) [10] should change this regrettable situation. 43 This document specifies some points where improvements can be 44 made in many current implementations, on the way of making IPsec 45 more suitable for Mobile IPv6. 47 1. Introduction 49 This document assumes that the reader knows IPsec (i.e., [1-6]) 50 but not Mobile IPv6. This section explains how Mobile IPv6 works. 52 In Mobile IPv6, each Mobile Node (MN) is always identified by 53 its Home Address (H@), regardless of its current point of 54 attachment to the Internet. While located away from its home, 55 a MN is also associated with a Care-of Address (Co@), which 56 provides information about the mobile node's current location. 57 IPv6 packets from a Correspondent Node (CN) addressed to a MN's 58 H@ are transparently routed to its Co@. 60 The MN has a special CN, the Home Agent (HA), which is used to 61 intercept packets addressed to the MN's H@ on the home link and 62 to forward them to the MN at its current Co@ through a tunnel. 64 End-to-end communications between a MN and a CN can use one of 65 these three modes: 67 - bidirectional tunneling with the HA: 68 MN => HA -> CN (=> denotes an encapsulation) 69 CN -> HA => MN 70 The CN knows only the MN's H@ regardless whether the MN is 71 mobile or not. This mode is very safe but not optimized at all. 73 - triangular routing: 74 MN ~> CN (~> denotes the use of an extension header) 75 CN -> HA => MN 76 The MN uses a Home Address Option (HAO): it puts its Co@ which 77 is topologically correct into the source address field of the 78 IPv6 header, and puts its H@ in the HAO. 80 - optimized routing: 81 MN ~> CN 82 CN ~> MN 83 The MN uses a HAO for packets to the CN, the CN uses a Routing 84 Header (RH) and puts the MN's Co@ in the destination address 85 field of the IPv6 header, and the MN's H@ in the RH. This mode 86 raises many security concerns, mainly about the mobility 87 signaling, but is very efficient. 89 These uses of HAO and RH are in fact degenerated tunnels as 90 shown by the Deering/Zill tunneling document [11], i.e., they 91 can be considered as IPv6 in IPv6 tunnels where two addresses 92 in the outer and inner IPv6 headers are redundant so one instance 93 is removed. 95 The association between a Co@ and the H@ is named "binding" and 96 is cached by CNs. Bindings are managed (i.e., created, changed 97 and deleted) by signaling messages named Binding Updates (BUs). 99 The term node in MN is a bit misleading: mobile routers are not 100 considered by current Mobile IPv6 specifications and communications 101 in this document are always end-to-end. 103 2. IPsec Architecture and Mobile IPv6 105 IPsec defines two modes, Transport and Tunnel modes. 106 As mobile IPv6 itself is based on real or degenerated tunneling, 107 there are three possible basic interactions: 108 - Transport mode after Mobile IPv6 tunneling, 109 - Transport mode before Mobile IPv6 tunneling 110 - A combination between Tunnel mode and Mobile IPv6 tunneling. 112 2.1 Transport Mode After Mobile IPv6 114 This case is defined only when Mobile IPv6 uses real tunneling, 115 i.e., in current specifications, between the MN and its HA. 116 As the IPv6 header (and addresses!) viewed by IPsec is the outer 117 one, in general this case has no interest (the MN's outer address 118 is a transient Co@, the interesting one, the H@, is in the inner 119 header). 121 2.2 Transport Mode Before Mobile IPv6 123 In this case, the IPsec transform is applied to the payload of 124 an ordinary packet between the MN and the CN. The MN will use 125 its static/long term H@. 126 After Mobile IPv6 includes its extension header corresponding to 127 the mode used, the following cases can be depicted: 129 - the bidirectional tunneling is perfectly transparent: IPsec and 130 Mobile IPv6 do not interfere. The same consideration applies to 131 the HA => MN tunnel. 133 - the triangular routing is more interesting and gives different 134 results for the Authentication Header (AH [2]) and the 135 Encapsulating Security Payload (ESP [3]): 137 * AH authenticates both Co@ (in the IPv6 header) and the H@ 138 (in the HAO) 140 * ESP with authentication will reject fake packets because 141 the attacker may not know the authentication shared secret. 143 So with authentication the only possible attack is a "Denial 144 of Services" launched by an attacker who knows the SPI and is 145 likely able to inject fake traffic without HAO. So this is an 146 intrinsic IPsec thread. 148 *RECOMMENDATION A: Packets with a HAO matching an IPsec SA 149 *providing authentication (i.e., AH or ESP with non-null 150 *authentication) MUST be accepted (i.e., the HAO considered 151 *as verifiable) and the HAO MUST be considered as verified [12] 152 *after successful IPsec processing. 154 - the optimized routing is similar to the triangular routing for 155 the MN ~> CN way and, in addition to recommendation A, the 156 common way to verify HAO is through the "binding cache entry 157 check". Symmetrically IPsec adds nothing to the RH check 158 because the MN has already all important informations. 160 - the optimized routing between two MNs has been addressed in 161 the Binding Update Backhauling proposal [9]. 163 2.3 Tunnel Mode not combined with Mobile IPv6 165 "Not combined" means the presence of two overheads, one for IPsec 166 tunneling and another one for Mobile IPv6 extra headers. It is 167 obvious in this case that one encapsulation provides enough 168 addresses (two sources and two destinations) for Mobile IPv6. 170 *RECOMMENDATION B: IPsec in Tunnel mode and Mobile IPv6 SHOULD 171 *be combined in order to avoid to add their overheads. 173 2.4 Addresses of SAs 175 SAs can be characterized by: 177 - zero address (proposed inbound processing for unicast) 178 - one address (destination in IPsec inbound processing [1]) 179 - two addresses (source and destination selectors [1]) 180 - three addresses (source, destination and proxy in PF_KEY [13]) 181 - four addresses (in Tunnel mode) 183 This is a bit confusing and gives security holes and/or extra 184 checks on addresses which are highly unfriendly with Mobile IPv6. 186 The Transport mode is easy because there are always exactly two 187 addresses. For instance in inbound processing, the destination 188 address is used for the SA lookup and the source address MUST 189 be checked ([1], section 5.2.1). So this document will assume 190 the Tunnel mode is used. 192 In general, the SADB is not designed to be managed directly 193 and/or by itself, i.e., without the SPD. Addresses are handled 194 by the SPD with a pair of selectors characterizing the source and 195 the destination of the traffic which receives IPsec protection. 196 SPD entries specify the type of IPsec processing (for instance 197 one type is the bypassing of IPsec: this is needed by IKE for its 198 own messages [1]) and the parameters of SAs to use or to build 199 (using SADB_ACQUIRE PF_KEY messages [13]). 201 According to [1] the traffic selection is divided between the 202 SPD and the SADB (a SPD entry points to many matching SAs) but 203 this cannot be realized using IKE so this point is very 204 confusing, and some implementations are nearly nonconform. 206 IKE (and its successor(s)) is designed to build SAs per pairs, 207 so IPsec implementations, using PF_KEY, should comply for Tunnel 208 mode SAs with the following interpretation: 210 - the source and the destination addresses are plain addresses 211 in the general case and designate the end points of the tunnel 212 (i.e., they are the outer header addresses). 214 - the inner source address is the proxy address (and exists only 215 in the Tunnel mode). This can be different from a plain 216 address (i.e., it can be for instance a prefix) but not in the 217 Mobile IPv6 case. The check may be performed after each IPsec 218 inbound processing [1] or at the SPD check (not the specified 219 way but the final result is the same). 221 *RECOMMENDATION C1: The source address checked after each 222 *IPsec inbound processing against the SA selector MUST be 223 *the inner header source address. 225 - the selection of the traffic to be processed is handled 226 by SPD entries. This includes the future inner addresses 227 in outbound processing. Guidelines are to use the inbound 228 processing rules for SADB design, the outbound processing 229 rules for SPD design and to complete by symmetry (with the 230 funny (?) side-effect that source and destination roles can 231 be reversed). 233 RFC 2401 [1] has detailed rules about the outer source address 234 but they are commonly misunderstood: checking it gives no extra 235 security because once a attacker can get the SPI, he can inject 236 fake traffic too. But this check harm nearly all mobility 237 mechanisms based on addresses, even nomadism a.k.a. the "road 238 warrior" case. 240 *RECOMMENDATION C2: The outer source address in Tunnel mode 241 *MUST NOT be checked after or before IPsec inbound processing. 243 This recommendation does not apply to the SPD checking, i.e., 244 step 4 of RFC 2401 [1] section 5.2.1. 246 This recommendation by itself does not solve the problem of the 247 other SA of the pair: the MN may change its Co@ and continue 248 to use the SA to the CN. But the other way/SA will work only 249 when the other SA will be updated or rebuilt with the new Co@ 250 as the destination. 252 BTW, RFC 2401 [1] specifies IPv6 in IPv4 and IPv4 in IPv6 tunnels 253 and these tunnels are taken into account in PF_KEY [13] so: 255 *RECOMMENDATION D: Dual stack (i.e., IPv4 and IPv6) IPsec 256 *implementations MUST support IPvX in IPvY Tunnel modes with 257 *any X and Y, including cases where X != Y. 259 2.5 Combined Tunnel Mode with Mobile IPv6 (Standard Case) 261 When IPsec in Tunnel mode is combined with Mobile IPv6, there 262 is one encapsulation with the fixed H@ in the inner header 263 and a transient Co@ in the outer header. Such configuration is 264 the opposite of the common Tunnel mode usage between two security 265 gateways. 267 Between two movements, the IPsec tunnels are not very special, 268 they look like end-to-end IPsec tunnels between two peers. 269 The only unusual detail is that the outer and inner addresses 270 can be different (when the MN is not at home), which is an issue 271 for IKE. 273 The interesting case is what happens when a Co@ changes: 274 the MN should send a BU to the CN which, according to 275 recommendation C, must not be filtered out because the 276 Co@ is not the same. 278 *RECOMMENDATION E1: BU protected by an IPsec SA providing 279 *authentication MUST be considered as authenticated. 281 *RECOMMENDATION E2: In the E1 case, all BU parameters MUST 282 *be covered by the authentication. Especially when the 283 *authentication is provided by an ESP transform, the new Co@ 284 *MUST be covered by using, for instance, an alternate Co@ 285 *suboption. 287 The CN could ask for a proof that the new Co@ is not a fake one, 288 i.e., the default policy may be to check the new Co@ in order 289 to avoid reflection attacks. This check is a return routability 290 check: the CN sends a question to the MN at its new Co@ with 291 a predictable answer. In a thread on the mobile-ip mailing list, 292 we proposed to reject the first BU with a "sequence number 293 out of the window" error. 295 *RECOMMENDATION E3: The CN SHOULD have the possibility to 296 *perform a return routability check on a new Co@ before 297 *recommendations E1 and E2 are applied. 299 As explained before, to deal with the BU is not enough for 300 the CN ~> MN way. For instance, the Binding Acknowledgment (BA) 301 can be protected only when the reversed SA is updated or rebuilt. 303 *RECOMMENDATION F: Mobility signaling and IPsec SA management 304 *direct cooperation SHOULD be considered (i.e., development of 305 *this kind of mechanisms encouraged). 307 2.6 Combined Tunnel Mode with Mobile IPv6 (Home Agent Case) 309 This section does not consider traffic from the HA itself 310 which is handled by routing optimization as for a standard CN. 311 It is only about the MN <=> HA bidirectional tunnel. 313 The addresses used for this tunnel are very simple: 315 - on the MN side, inner header address is the H@, outer a Co@. 316 - on the HA side, inner header address is any valid address 317 (unicast address when used as a source address) and the 318 outer address is the HA address [7]. 320 IPsec considerations are near the same than for standard CNs. 321 In fact, things are simpler because one can assume the HA is 322 never mobile. Recommendation F applies but is not useful when 323 no IPsec SA exists, i.e., when a MN boots in visit: this will 324 be the special case in IKE considerations (next section). 326 3. IKE and Mobile IPv6 328 There are three basic issues: 330 - how to handle the multiple addresses of a MN? In the phase 331 one? In a phase two? 332 - how to establish SAs between a MN and a standard CN? 333 - how to establish SAs between a MN from a foreign link and its 334 HA the first time? 336 This document uses the name IKE [6] for the IPsec DOI [4] 337 and ISAKMP [5] framework too. Some proposals for IKEv2 [13] 338 (used as an instance of a Son-of-Ike with two phases) can be 339 found in the appendix B. 341 3.1 IKE and Identities (Phase One) 343 In the phase one, identities (IDii and IDir) designate the peers, 344 so subnet and range identities may not be used. This document 345 assumes a phase one with digital signatures using a X.509 style 346 of certificates, but most of the considerations applies to public 347 key authentications too. 349 In a phase one, a peer is identified by its address used for the 350 transport of IKE messages (aka the "peer address") and its 351 identity payload. Identities, in the general meaning, may be 352 present in certificates too but all cases are not equivalent: 354 - the Identity must be related to the certificate: 356 *RECOMMENDATION G: The Identity payload presented by the peer 357 *MUST be verified. For instance, when certificates are used, 358 *the Identity and the subject or an alternative subject of 359 *the certificate associated to the signature MUST match. 361 - if the Identity is an address, it must be the right address: 363 *RECOMMENDATION H: If the Identity payload presented by the 364 *peer is an address, it MUST be the same address than the one 365 *used to transport IKE messages (aka the "peer address"). 367 - same for addresses used as (alternative) subjects: 369 *RECOMMENDATION I: If an address is used as the subject or as 370 *an alternative subject of the certificate associated to the 371 *signature, then the address used to transport IKE messages 372 *(aka the "peer address") SHOULD match the subject or an 373 *alternative subject. 375 "SHOULD match" means the default policy is to perform the check. 377 - last about Identity/address checks: 379 *RECOMMENDATION J: The case where the certificate associated 380 *to the signature has no address subject or alternative subject 381 *SHOULD be considered as a special case by policies. For 382 *instance, the policy MAY specify particular constraints for 383 *this case. 385 - of course, this can be a bit annoying for MNs which must use 386 in some cases their Co@ for transport of IKE messages so: 388 *RECOMMENDATION K: The addition of a Home Address Identity, 389 *which should allow strict application of previous I and J 390 *recommendations in all MN's peer cases, SHOULD be considered 391 *in IKE. 393 Today the possibility to include addresses in identities is not 394 considered to be a good idea. The appendix B about IKEv2 will 395 propose a very different way to solve concerns addressed by 396 recommendations of this section (H-K). 398 3.2 IKE and Identities (Phase Two) 400 In the phase two (a.k.a. quick mode) identities (IDci and IDcr) 401 are optional and designate the policy rule (in the SPD or in the 402 IKE software configuration) to apply: 404 - in Tunnel mode the peer addresses will be the outer header 405 addresses, and identities can denote the traffic selector part 406 of the policy rule. 408 - without identities the SA pairs will be applied to all traffic 409 not matched by a more specific policy between the peers using 410 the same addresses than in IKE messages. This is ambiguous so: 412 *RECOMMENDATION L1: When the phase one and phases two are 413 *allowed to use different (peer) addresses to transport 414 *messages, identity payloads SHOULD be used in phases two. 416 - in Tunnel mode there is an ambiguity about the endpoint 417 addresses: 419 *RECOMMENDATION L2: When the phase one and phases two are 420 *allowed to use different addresses, the endpoint addresses 421 *used in a phase 2 context MUST be the (peer) addresses used 422 *to transport IKE messages of this phase 2. 424 - junk identities are not useful: 426 *RECOMMENDATION M: Identity payloads used in phase two SHOULD 427 *clearly denote address sets. 429 - IKE [6] explicitly provides a "proxy case" usable for mobility: 431 *RECOMMENDATION N: The policy MAY authorize the establishment 432 *of a Transport mode SA pair using an address identity payload 433 *which does not match the (peer) address used to transport IKE 434 *messages. This authorization SHOULD be based on parameters 435 *provided in the phase one authentication, for instance the 436 *phase one peer identity and certificate. 438 3.3 IKE and Mobile IPv6 (Standard Case) 440 If the MN has the choice between using its H@ or a Co@ for IKE 441 exchanges, only the first choice makes sense with a standard CN. 442 Actually, when the initiator is the CN, it always uses the H@. 443 Using the Co@ is more complex and should require a new phase one 444 with each peer after a movement. 446 Note that the IKE software should not even notice that the node is 447 mobile... For the same reason, the SA pairs should use the H@ as 448 the MN address, giving an IPsec transform before Mobility case. 450 *RECOMMENDATION O: With a standard CN, the MN SHOULD ignore the 451 *fact that it is a mobile node and SHOULD use its H@ for all IKE 452 *exchanges and for its own address in the SA pairs. To avoid both 453 *IPsec and Mobile IPv6 overheads, it SHOULD negotiate the Transport 454 *mode. 456 Transport mode was designed for end-to-end communications, IMHO 457 this recommendation should be written with MUSTs! 459 3.4 IKE and Mobile IPv6 (Home Agent Case) 461 Recommendation O does not work with the HA because, when the MN 462 boots in visit, it can use its H@ only after processing of the 463 first BU by the HA. This BU MUST be protected so it can not be 464 protected by IPsec (trivial bootstrap problem). 466 In fact there are two possible MN - HA SA pairs: 467 - a SA pair for BU/BA exchange protection. 468 - a SA pair for the MN <=> HA tunnel. 470 The first SA pair is a bit hairy to establish, because the MN can 471 only use its Co@ in some circumstances: 473 *RECOMMENDATION P: If BU/BA exchanges between the MN and the HA 474 *are protected by an IPsec SA pair, the establishment of this SA 475 *pair MUST be allowed using a Co@ for the transport of all IKE 476 *messages (i.e., the MN peer address is a Co@). 478 The detailed requirements are: 480 - an API should give a suitable Co@ for communications with 481 the HA (i.e., something like getsockname() which returns 482 the Co@ for a connected socket to the HA address in place 483 of the Ho@). 484 - phase one and phase two messages are sent using this Co@. 485 - the phase one identity is not an address if no transient 486 certificate for a Co@ is available. 487 - the authentication with this identity must be allowed 488 (including when recommendation J is enforced). 489 - until the home address identity is defined and implemented, 490 the phase two identity must be an address identity using the 491 H@, and this must be allowed (according to recommendation O). 492 - the result is a SA pair between the MN with its H@ and the HA 493 with its HA Address. The most adequat is AH Transport mode 494 (enough security and best efficiency). 496 This SA pair establishment stresses the issue of relative lifetimes 497 of the phase one and the SA pair so: 499 *RECOMMENDATION Q: IKE implementations MUST support lifetimes 500 *for the phase one, which are far longer or far shorter than 501 *the lifetime of SA pairs established by phases two. 503 and with very long phase one lifetimes: 505 *RECOMMENDATION R: IKE implementations SHOULD be able to lookup 506 *a still valid phase one state from a phase two message using 507 *different (peer) addresses for transport. For instance using the 508 *ISAKMP SA SPI a.k.a. cookies [5]. 510 The SA pair for the tunnel is more easy: the only problem is 511 about policies: 512 - A solution is to dynamically create the proper policy from 513 mobility information (i.e., BUs) and to establish the SA pair 514 described in section 2.6 (combined Tunnel mode with HA). One 515 can make things a bit faster reusing the phase one 516 (c.f. recommendations R and L2). 517 - Another solution is to create a SA pair using only the MN's H@ 518 (this can be done as soon as the first BU is processed because 519 the HA can use the standard routing optimization mode for its 520 own traffic. In fact this is the default behavior), and to use 521 a to-be-defined direct cooperation mechanism between IPsec and 522 mobility to update the outer MN address in the SA pair 523 (a good use of the HIP readdress [10]). 525 4. Security Considerations 527 At the exception of recommendations F and K, all recommendations 528 made in this document are about interpretation of IPsec 529 specification details. In fact, we are convinced these 530 recommendations shall improve the security of both IPsec and 531 Mobile IPv6. 533 5. Acknowledgments 535 Some of the MN - HA ideas were developed in the authentication vs. 536 authorization brainstorming, for instance the home address identity 537 (unfortunately I don't remember who proposed this). 539 Of course the current terrible interaction between IPsec and 540 Mobile IPv6 was and still is discussed in the mobile-ip WG list 541 and from time to time in the ipsec WG list too. So many thanks 542 to the little number of persons who participate to both lists. 544 The return routability check for new Co@ was proposed by Alper 545 Yegin and makes IPsec a very good candidate in the MN - CN case 546 when it is applicable. 548 I finish with authors of "open source" IKE implementations, 549 particularly Shoichi Sakane who has written the IPsec 550 implementation (including an IKE daemon, racoon) I use. 552 6. Normative References 554 [1] S. Kent, R. Atkinson, "Security Architecture for the Internet 555 Protocol", RFC 2401, November 1998. 557 [2] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, 558 November 1998. 560 [3] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", 561 RFC 2406, November 1998. 563 [4] D. Piper, "The Internet IP Security Domain of Interpretation 564 for ISAKMP", RFC 2407, November 1998. 566 [5] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet 567 Security Association and Key Management Protocol (ISAKMP)", 568 RFC 2408, November 1998. 570 [6] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 571 RFC 2409, November 1998. 573 [7] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", 574 draft-ietf-mobileip-ipv6-24.txt, June 2003. 576 7. Informative References 578 [8] F. Dupont, "Mobility-aware IPsec ESP tunnels", 579 draft-dupont-movesptun-00.txt, February 2001. 581 [9] W. Haddad and all, "Binding Update Backhauling", 582 draft-haddad-mip6-bub-01.txt, February 2004. 584 [10] R. Moskowitz and all, "Host Identity Payload And Protocol", 585 draft-moskowitz-hip-09.txt, February 2004. 587 [11] S. Deering, B. Zill, "Redundant Address Deletion when 588 Encapsulating IPv6 in IPv6", 589 draft-deering-ipv6-encap-addr-deletion-00.txt, November 2001. 591 [12] C. Perkins, "[mobile-ip] A new proposal for handling Home 592 Address destination options", http://playground.sun.com/mobile-ip/, 593 Message-ID: <3C6C7780.4CFAA7B4@iprg.nokia.com>, February 2002. 595 [13] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, 596 Version 2", RFC 2367, July 1998. 598 8. References for Appendixes 600 [14] C. Kaufman, ed., "Proposal for the IKEv2 Protocol", 601 draft-ietf-ipsec-ikev2-12.txt, January 2004. 603 [15] B. Korver, E. Rescorla, "The Internet IP Security PKI 604 Profile of ISAKMP and PKIX", 605 draft-ietf-ipsec-pki-profile-03.txt, July 2003. 607 [16] P. Hoffman, "Adding revised identities to IKEv2", 608 http://www.vpnc.org/ietf-ipsec/, 609 Message-Id: , 610 November 2002. 612 [17] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", 613 RFC 2956, October 2000. 615 [18] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks 616 or how NATs are even more evil than you believed", 617 draft-dupont-transient-pseudonat-02.txt, October 2003. 619 [19] S. Deering and all, "IPv6 Scoped Address Architecture", 620 draft-ietf-ipv6-scoping-arch-00.txt, June 2003. 622 [20] Franck Le and all, "Mobile IPv6 Authentication, Authorization, 623 and Accounting Requirements", 624 draft-le-aaa-mipv6-requirements-02.txt, April 2003. 626 9. Author's Address 628 Francis Dupont 629 ENST Bretagne 630 Campus de Rennes 631 2, rue de la Chataigneraie 632 CS 17607 633 35576 Cesson-Sevigne Cedex 634 FRANCE 635 Fax: +33 2 99 12 70 30 636 EMail: Francis.Dupont@enst-bretagne.fr 638 Wassim Haddad 639 Helsinki University of Technology 640 Theoretical Computer Science Laboratory 641 PO BOX 9201 642 HUT 02015 643 Finland 644 EMail: whaddad@tcs.hut.fi 646 10. Changes from Previous Drafts 648 Addition of recommendation E3 about return routability check 649 for new Co@. 651 Addition of Appendix A (list of recommendations), B (proposals 652 for IKEv2), C (return routability) and D (scoped addresses). 654 Introduction of the "peer address" term. 656 Some rewordings (from Wassim Haddad). 658 New appendix about mobile IPsec VPN. 660 Appendix A: List of Recommendations 662 A: Packets with a HAO matching an IPsec SA providing authentication 663 (i.e., AH or ESP with non-null authentication) MUST be accepted 664 (i.e., the HAO considered as verifiable) and the HAO MUST be 665 considered as verified [12] after successful IPsec processing. 667 B: IPsec in Tunnel mode and Mobile IPv6 SHOULD be combined in 668 order to avoid to add their overheads. 670 C1: The source address checked after each IPsec inbound processing 671 against the SA selector MUST be the inner header source address. 673 C2: The outer source address in Tunnel mode MUST NOT be checked 674 after or before IPsec inbound processing. 676 D: Dual stack (i.e., IPv4 and IPv6) IPsec implementations MUST 677 support IPvX in IPvY Tunnel modes with any X and Y, including 678 cases where X != Y. 680 E1: BU protected by an IPsec SA providing authentication MUST 681 be considered as authenticated. 683 E2: In the E1 case, all BU parameters MUST be covered by the 684 authentication. Specially when the authentication is provided 685 by an ESP transform, the new Co@ MUST be covered by using, for 686 instance, an alternate Co@ suboption. 688 E3: The CN SHOULD have the possibility to perform a return 689 routability check on a new Co@ before recommendations E1 and 690 E2 are applied. 692 F: Mobility signaling and IPsec SA management direct cooperation 693 SHOULD be considered (i.e., development of this kind of 694 mechanisms encouraged). 696 G: The Identity payload presented by the peer MUST be verified. For 697 instance, when certificates are used, the Identity and the 698 subject or an alternative subject of the certificate associated 699 to the signature MUST match. 701 H: If the Identity payload presented by the peer is an address, 702 it MUST be the same address than the one used to transport 703 IKE messages (aka the "peer address"). 705 I: If an address is used as the subject or an alternative subject 706 of the certificate associated to the signature, then the address 707 used to transport IKE messages (aka the "peer address") SHOULD 708 match the subject or an alternative subject. 710 J: The case where the certificate associated to the signature has 711 no address subject or alternative subject SHOULD be considered 712 as a special case by policies. For instance, the policy MAY 713 specify particular constraints for this case. 715 K: The addition of a Home Address Identity, which should allow 716 strict application of previous I and J recommendations in all 717 MN's peer cases, SHOULD be considered in IKE. 719 L1: When the phase one and phases two are allowed to use different 720 (peer) addresses to transport messages, identity payloads SHOULD 721 be used in phases two. 723 L2: When the phase one and phases two are allowed to use different 724 addresses, the endpoint addresses used in a phase 2 context 725 MUST be the (peer) addresses used to transport IKE messages of 726 this phase 2. 728 M: Identity payloads used in phase two SHOULD denote clearly 729 address sets. 731 N: The policy MAY authorize the establishment of a Transport mode 732 SA pair using an address identity payload which does not match 733 the (peer) address used to transport IKE messages. This 734 authorization SHOULD be based on parameters provided in the 735 phase one authentication, for instance the phase one peer 736 identity and certificate. 738 O: With a standard CN, the MN SHOULD ignore the fact that it is a 739 mobile node and SHOULD use its H@ for all IKE exchanges and for 740 its own address in the SA pairs. To avoid both IPsec and Mobile 741 IPv6 overheads, it SHOULD negotiate the Transport mode. 743 P: If BU/BA exchanges between the MN and the HA are protected by 744 an IPsec SA pair, the establishment of this SA pair MUST be 745 allowed using a Co@ for the transport of all IKE messages (i.e., 746 the MN peer address is a Co@). 748 Q: IKE implementations MUST support lifetimes for the phase one 749 which are far longer or far shorter than the lifetime of SA 750 pairs established by phases two. 752 R: IKE implementations SHOULD be able to lookup still valid phase 753 one state from a phase two message using different (peer) 754 addresses for transport. For instance using the ISAKMP SA SPI 755 a.k.a. cookies [5]. 757 Appendix B: Proposals for IKEv2 759 Many recommendations are directly applicable to IKEv2 [14]: 760 - recommendations G, O, P apply without modifications. 761 - recommendations L1, L2 and N applies to traffic selectors 762 in place of phase two identities. 763 - recommendation M is integrated in IKEv2. 764 - recommendation R is partially integrated in section 2.6 765 of [14], but we propose to make very clear the IKE-SA lookup 766 MUST be done using the cookies as a SPI *only*. Note that 767 IKEv2 guarantees the uniqueness of these "SPIs". 769 [15] introduces the term "peer addresses" for the addresses used 770 for the transport of IKE messages and includes the recommendations 771 G, H and I. [16] is not directly applicable to IKEv2 but [16] (not 772 yet included in the IKEv2 draft) proposes a new form of identities 773 without any kind of binding to addresses. 775 In IKEv2 the phase one SA is named the IKE SA and when it is 776 deleted all the IPsec SAs it negotiated have to be deleted too 777 (so the recommendation Q does not stand). The idea is to solve 778 the dead peer detection issue by keepalives over the IKE SA. 780 *PROPOSAL 1: IKEv2 implementations MUST lookup IKE-SA using 781 *only the SPI at the exclusion of peer addresses. 783 Identities should not include addresses as recommended in [16] 784 so recommendations H to K are obsolete in the IKEv2 context. 785 (this is a call to adopt [15] ASAP) 787 *PROPOSAL 2: IKEv2 identity payloads MUST only use abstract 788 *identities as recommended in [17] by the IAB and proposed by [15]. 789 But this and the section 4.11 "Address and Port Agility" of [13] 790 remove any check of peer addresses which are still part of 791 established SAs, opening the door to attacks as described in 792 [18]. But mobility really needs address agility so: 794 *PROPOSAL 3: The section 4.11 should specify full address agility. 796 The first counter-measure against abuse of this address agility 797 is to protect the integrity of transport headers. The new 798 notifications NAT-DETECTION-SOURCE-IP and NAT-DETECTION- 799 DESTINATION-IP are the beginning of a solution. 801 *PROPOSAL 4: IKEv2 MUST provide a way to protect the integrity 802 *of transport parameters (peer addresses, ports and protocol). 804 *PROPOSAL 5: The default policy SHOULD be the protection of 805 *the integrity of transport parameters for IPv6. 807 These proposals defeat en-route modifications of messages, 808 i.e., fulfill some mobility requirements, but not all of 809 them because these proposals give no proof about the real 810 origin of messages, i.e., one should trust its peer. 811 The solution is of course a simple return routability check, 812 and IKEv2 already uses this kind of mechanisms in the 813 "Responder under attack" case (IKE_SA_init_reject). 815 *PROPOSAL 6: A mechanism MUST be provided in order to make return 816 *routability checks available on peer address changes. 818 *PROPOSAL 7: The default policy SHOULD be to perform 819 *return routability checks on peer address changes. 821 Now that mobility can be securely handled (this is not the 822 case for NAT traversal but we believe this issue can not be 823 solved, c.f. [17]), we can look for some dedicated improvements. 824 The fist special case to be dealt with is the MN - HA SA pair 825 to protect the BU/BA exchange a.k.a. the "home registration". 827 *PROPOSAL 8: When the policy authorizes it, a traffic selector 828 *in Transport mode MAY override peer addresses as SA selectors. 830 (this is a reformulation of recommendations N and P.) 832 The other item is to instantiate the recommendation F: 834 *PROPOSAL 9: A new mechanism MUST be defined for the update 835 *of the peer address in the SA pair (the source outer address of 836 *the inbound SA and the destination outer address of the outbound 837 *SA) without mandatory rekeying. 839 Appendix C: Return Routability 841 The proposed return routability check assumes these properties: 842 - a secret is shared with the peer, i.e., there is a proof 843 that the received packets are from the peer. 844 - an anti-replay mechanism proves the received packets are fresh. 846 If the exchange involved some hard state change (for instance the 847 proposal 9), a sequencing mechanism should be provided too. 849 The return routability check does not give a proof that the peer is 850 at the given address, it only proves the peer is on the path. 851 For more details about return routability check theory, please 852 refer to [7]. 854 Appendix D: Scoped Addresses 856 This topics is not really a Mobile IPv6 one, but in practice the 857 "mobile VPN" case there is a heavy usage of limited scope or 858 private addresses. 860 The issue is that addresses carried in identity or traffic 861 selector payloads are not clothed with zone identifiers. 862 Only the peer addresses used to transport messages have an 863 indirect indication of their zones. 865 The IPv6 scoped address architecture [19] gives the properties 866 of zones: at a given scope, zones formed a partition, i.e., 867 an interface belongs to one and only one zone. They have an 868 inclusion property too, i.e., a zone of a given scope is 869 fully included into a zone of any higher scope. This gives 870 an inheritance property which is safe when it is used in 871 the proper way: to establish SAs with global addresses with 872 IKE running over link-local addresses is safe, the opposite 873 is not. 875 *RULE: The default policy SHOULD accept scoped addresses as 876 *selectors of SAs only when they are established using peer 877 *addresses (for the transport of IKE/IKEv2/etc messages) which 878 *are in fully included zones. 880 Appendix E: mobile IPsec VPN 882 Mobile IPsec Virtual Private Networks (VPNs) provides the same kind 883 of functionality than mobile IP: the VPN client (the Mobile Node in 884 the mobility context) opens an ESP tunnel with a Security Gateway 885 (the equivalent of a Home Agent) located in the home site. 887 Even if the style of mobile IPsec VPNs are more Mobile IPv6 than 888 Mobile IPv4 (there is no equivalent of Foreign Agents for 889 instance), they can be used for the two versions of IP so this 890 appendix is about both. 892 Current mobile IPsec VPNs have no Security Gateway detection, 893 support for multiple inner addresses, prefix discovery, etc, but 894 they can be connected to a remote network access control with an 895 optional address allocation. Today they have no support for an 896 extended AAA system where the AAA infrastructure connects the local 897 and remote network access control with some assistance to the 898 initial security setup (via credentials and/or piggy-backing of IKE 899 initial exchanges [20]). 901 The layout of data packets of mobile IPsec VPNs are exactly the 902 same than for Mobile IPv6 with an ESP protected MN-HA bidirectional 903 tunnel (the outer header client address is a Care-of Address, the 904 inner one is the Home Address) at one exception: in Mobile IPv6 the 905 Home Agent is a correspondent node for its own address, for 906 instance the Home Agent sends genuine packets to the Mobile Node 907 using a Routing Header, not through the tunnel. If the 908 corresponding rule of [7] (section 9.3.2 Sending Packets to a 909 Mobile Node) is applied only to Mobile IPv6 signaling packets, 910 mobile IPsec VPNs and Mobile IPv6 are indistinguishable. 912 So mobile IPsec VPNs are a good replacement for unoptimized Mobile 913 IPv6 or for Mobile IPv4 with secure reverse tunneling. Movements 914 can be handled by peer address update mechanisms, including 915 rekeying.