idnits 2.17.1 draft-dupont-ipsec-mipv6-03.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-25) 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], [7], [9]), 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 145: '...*authentication) MUST be accepted (i.e...' RFC 2119 keyword, line 146: '... *as verifiable) and the HAO MUST be considered as verified [11]...' RFC 2119 keyword, line 168: '... in Tunnel mode and Mobile IPv6 SHOULD...' RFC 2119 keyword, line 185: '... SA lookup and the source address MUST...' RFC 2119 keyword, line 217: '...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 (March 2003) is 7712 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: '13' is mentioned on line 780, but not defined == Missing Reference: '14' is mentioned on line 759, but not defined == Missing Reference: '15' is mentioned on line 778, but not defined == Missing Reference: '16' is mentioned on line 778, but not defined == Missing Reference: '17' is mentioned on line 814, but not defined == Missing Reference: '18' is mentioned on line 855, but not defined == Missing Reference: '19' is mentioned on line 889, 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) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-20 == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-05 Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 3 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 September 2003 Wassim Haddad 4 Helsinki University of Technology 5 March 2003 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 [7]. 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) [9] 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 thar 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 situated 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: 66 - bidirectional tunneling with the HA: 67 MN => HA -> CN (=> denotes an encapsulation) 68 CN -> HA => MN 69 The CN knows only the MN's H@ regardless whether the MN is 70 mobile or not. This mode is very safe but not optimized at all. 71 - triangular routing: 72 MN ~> CN (~> denotes the use of an extension header) 73 CN -> HA => MN 74 The MN uses a Home Address Option (HAO): it puts its Co@ which 75 is topologically correct into the source address field of the 76 IPv6 header, and puts its H@ in the HAO. 77 - optimized routing: 78 MN ~> CN 79 CN ~> MN 80 The MN uses a HAO for packets to the CN, the CN uses a Routing 81 Header (RH) and puts the MN's Co@ in the destination address 82 field of the IPv6 header, and the MN's H@ in the RH. This mode 83 raises many security concerns, mainly about the mobility 84 signaling, but is very efficient. 86 These uses of HAO and RH are in fact degenerated tunnels as 87 shown by the Deering/Zill tunneling document [10], i.e., they 88 can be considered as IPv6 in IPv6 tunnels where two addresses 89 in the outer and inner IPv6 headers are redundant so one instance 90 is removed. 92 The association between a Co@ and the H@ is named "binding" and 93 is cached by CNs. Bindings are managed (i.e., created, changed 94 and deleted) by signaling messages named Binding Updates (BUs). 96 The term node in MN is a bit misleading: mobile routers are not 97 considered by current Mobile IPv6 specifications and communications 98 in this document are always end-to-end. 100 2. IPsec Architecture and Mobile IPv6 102 IPsec defines two modes, Transport and Tunnel modes. 103 As mobile IPv6 itself is based on real or degenerated tunneling, 104 there are three possible basic interactions: 105 - Transport mode after Mobile IPv6 tunneling, 106 - Transport mode before Mobile IPv6 tunneling 107 - A combination between Tunnel mode and Mobile IPv6 tunneling. 109 2.1 Transport Mode After Mobile IPv6 111 This case is defined only when Mobile IPv6 uses real tunneling, 112 i.e., in current specifications, between the MN and its HA. 113 As the IPv6 header (and addresses!) viewed by IPsec is the outer 114 one, in general this case has no interest (the MN's outer address 115 is a transient Co@, the interesting one, the H@, is in the inner 116 header). 118 2.2 Transport Mode Before Mobile IPv6 120 In this case, the IPsec transform is applied to the payload of 121 an ordinary packet between the MN and the CN. The MN will use 122 its static/long term H@. 123 After Mobile IPv6 includes its extension header corresponding to 124 the mode used, the following cases can be depicted: 126 - the bidirectional tunneling is perfectly transparent: IPsec and 127 Mobile IPv6 do not interfere. The same consideration applies to 128 the HA => MN tunnel. 130 - the triangular routing is more interesting and gives different 131 results for the Authentication Header (AH [2]) and the 132 Encapsulating Security Payload (ESP [3]): 133 * AH authenticates both Co@ (in the IPv6 header) and the H@ 134 (in the HAO) 135 * ESP with authentication will reject fake packets because 136 the attacker may not know the authentication shared secret. 138 So with authentication the only possible attack is a "Denial 139 of Services" launched by an attacker who knows the SPI and is 140 likely able to inject fake traffic without HAO. So this is an 141 intrinsic IPsec thread. 143 *RECOMMENDATION A: Packets with a HAO matching an IPsec SA 144 *providing authentication (i.e., AH or ESP with non-null 145 *authentication) MUST be accepted (i.e., the HAO considered 146 *as verifiable) and the HAO MUST be considered as verified [11] 147 *after successful IPsec processing. 149 - the optimized routing is like triangular routing for the MN ~> 150 CN way with, in addition to recommendation A, the common way to 151 verify HAO: the "binding cache entry check". Symmetrically IPsec 152 adds nothing to the RH verification because the MN has already 153 all important informations. 155 - the optimized routing between two MNs is an interesting case 156 not yet fully addressed by Mobile IPv6 specifications [8]: 157 RH and HAO have more overhead than a plain tunnel so a 158 combined Tunnel mode with Mobile IPv6 becomes very 159 interesting in this special case... 161 2.3 Tunnel Mode not combined with Mobile IPv6 163 "Not combined" means there are two overhead, one for IPsec 164 tunneling and another one for Mobile IPv6 extra headers, when 165 obviously one encapsulation provides enough addresses (two sources 166 and two destinations) for Mobile IPv6! 168 *RECOMMENDATION B: IPsec in Tunnel mode and Mobile IPv6 SHOULD 169 *be combined in order to avoid to add their overheads. 171 2.4 Addresses of SAs 173 SAs can be characterized by: 174 - zero address (proposed inbound processing for unicast) 175 - one address (destination in IPsec inbound processing [1]) 176 - two addresses (source and destination selectors [1]) 177 - three addresses (source, destination and proxy in PF_KEY [12]) 178 - four addresses (in Tunnel mode) 180 This is a bit confusing and gives security holes and/or extra 181 checks on addresses which are highly unfriendly with Mobile IPv6. 183 The Transport mode is easy because there are always exactly two 184 addresses. For instance in inbound processing, the destination 185 address is used for the SA lookup and the source address MUST 186 be checked ([1], section 5.2.1). So this document will assume 187 the Tunnel mode is used. 189 In general, the SADB is not designed to be managed directly 190 and/or by itself, i.e., without the SPD. Addresses are handled 191 by the SPD with a pair of selectors which characterized the 192 source and the destination of the traffic which receives IPsec 193 protection. SPD entries specify the type of IPsec processing 194 (for instance one type is the bypassing of IPsec: this is needed 195 by IKE for its own messages [1]) and the parameters of SAs 196 to use or to build (using SADB_ACQUIRE PF_KEY messages [12]). 198 According to [1] the traffic selection is divided between the 199 SPD and the SADB (a SPD entry points to many matching SAs) but 200 this cannot be realized using IKE so this point is very 201 confusing, and some implementations are nearly nonconform. 203 IKE (and its successor(s)) is designed to build SAs per pairs, 204 so IPsec implementations, using PF_KEY, should comply for 205 Tunnel mode SAs with the following interpretation: 206 - the source and the destination addresses are plain addresses 207 in the general case and designate the end points of the tunnel 208 (i.e., there are the outer header addresses). 209 - the inner source address is the proxy address (and exists only 210 in the Tunnel mode). This can be something else than a plain 211 address (i.e., for instance a prefix) but not in the Mobile IPv6 212 case. The check may be performed after each IPsec inbound 213 processing [1] or at the SPD check (not the specified way but 214 the final result is the same). 216 *RECOMMENDATION C1: The source address checked after each 217 *IPsec inbound processing against the SA selector MUST be 218 *the inner header source address. 220 - the selection of the traffic to be processed is handled 221 by SPD entries. This includes the future inner addresses 222 in outbound processing. Guidelines are to use the inbound 223 processing rules for SADB design, the outbound processing 224 rules for SPD design and to complete by symmetry (with the 225 funny (?) side-effect that source and destination roles can 226 be reversed). 228 RFC 2401 [1] has detailed rules about the outer source address but 229 they are commonly misunderstood: checking it gives no extra 230 security because once a attacker can get the SPI, he can inject 231 fake traffic too. But this check harm nearly all mobility 232 mechanisms based on addresses, even nomadism a.k.a. the "road 233 warrior" case. 235 *RECOMMENDATION C2: The outer source address in Tunnel mode 236 *MUST NOT be checked after or before IPsec inbound processing. 238 This recommendation does not apply to the SPD checking, i.e., 239 step 4 of RFC 2401 [1] section 5.2.1. 241 This recommendation by itself does not solve the problem of the 242 other SA of the pair: the MN may change its Co@ and continue 243 to use the SA to the CN. But the other way/SA will work only 244 when the other SA will be updated or rebuilt with the new Co@ 245 as the destination. 247 BTW, RFC 2401 [1] specifies IPv6 in IPv4 and IPv4 in IPv6 tunnels 248 and these tunnels are taken into account in PF_KEY [12] so: 250 *RECOMMENDATION D: Dual stack (i.e., IPv4 and IPv6) IPsec 251 *implementations MUST support IPvX in IPvY Tunnel modes with 252 *any X and Y, including cases where X != Y. 254 2.5 Combined Tunnel Mode with Mobile IPv6 (Standard Case) 256 When IPsec in Tunnel mode is combined with Mobile IPv6, there 257 is one encapsulation with the fixed H@ in the inner header 258 and a transient Co@ in the outer header. Such configuration is the 259 opposite of the common Tunnel mode usage between two security 260 gateways. The CN can be itself a MN: only one detail not directly 261 related to IPsec matters: mobility has to support the simultaneous 262 movement of both peers (handled by fallback through a HA for 263 instance in Mobile IPv6, c.f. [8]). 265 Between two movements the IPsec tunnels are not very special, 266 they look like end-to-end IPsec tunnels between two peers. 267 The only unusual detail is that the outer and inner addresses 268 can be different (when the MN is not at home), which is an issue 269 for IKE. 271 The interesting case is what happens when a Co@ changes: 272 the MN should send a BU to the CN which, according to 273 recommendation C, must not be filtered out because the 274 Co@ is not the same. 276 *RECOMMENDATION E1: BU protected by an IPsec SA providing 277 *authentication MUST be considered as authenticated. 279 *RECOMMENDATION E2: In the E1 case, all BU parameters MUST 280 *be covered by the authentication. Specially when the 281 *authentication is provided by an ESP transform, the new Co@ 282 *MUST be covered by using, for instance, an alternate Co@ 283 *suboption. 285 The CN could ask for a proof that the new Co@ is not a fake one, 286 i.e., the default policy may be to check the new Co@ in order 287 to avoid reflection attacks. This check is a return routability 288 check: the CN sends a question to the MN at its new Co@ with 289 a predictable answer. In a thread on the mobile-ip mailing list, 290 we proposed to reject the first BU with a "sequence number 291 out of the window" error. 293 *RECOMMENDATION E3: The CN SHOULD have the possibility to 294 *perform a return routability check on a new Co@ before 295 *recommendations E1 and E2 are applied. 297 As explained before, to deal with the BU is not enough for 298 the CN ~> MN way. For instance, the Binding Acknowledgment (BA) 299 can be protected only when the reversed SA is updated or rebuilt. 301 *RECOMMENDATION F: Mobility signaling and IPsec SA management 302 *direct cooperation SHOULD be considered (i.e., development of 303 *this kind of mechanisms encouraged). 305 2.6 Combined Tunnel Mode with Mobile IPv6 (Home Agent Case) 307 This section does not consider traffic from the HA itself 308 which is handled by routing optimization as for a standard CN. 309 It is only about the MN <=> HA bidirectional tunnel. 311 The addresses used for this tunnel are very simple: 312 - on the MN side, inner header address is the H@, outer a Co@. 313 - on the HA side, inner header address is any valid address 314 (unicast address when used as a source address) and the 315 outer address is the HA address [8]. 316 IPsec considerations are near the same than for standard CNs. 317 In fact, things are simpler because one can assume the HA is 318 never mobile. Recommendation F applies but is not useful when 319 no IPsec SA exists, i.e., when a MN boots in visit: this will 320 be the special case in IKE considerations (next section). 322 3. IKE and Mobile IPv6 324 There are three basic issues: 325 - how to handle the multiple addresses of a MN? In the phase 326 one? In a phase two? 327 - how to establish SAs between a MN and a standard CN? 328 - how to establish SAs between a MN from a foreign link 329 and its HA the first time? 330 This document uses the name IKE [6] for the IPsec DOI [4] 331 and ISAKMP [5] framework too. Some proposals for IKEv2 [13] 332 (used as an instance of a Son-of-Ike with two phases) can be 333 found in the appendix B. 335 3.1 IKE and Identities (Phase One) 337 In the phase one, identities (IDii and IDir) designate the peers 338 so subnet and range identities may not be used. This document 339 assumes a phase one with digital signatures using a X.509 style 340 of certificates, but most of the considerations applies to 341 public key authentications too. 343 In phase one, a peer is identified by its address used for the 344 transport of IKE messages (aka the "peer address") and its 345 identity payload. Identities, in the general meaning, may be 346 present in certificates too but all cases are not equivalent: 348 - the Identity must be related to the certificate: 350 *RECOMMENDATION G: The Identity payload presented by the peer 351 *MUST be verified. For instance, when certificates are used, 352 *the Identity and the subject or an alternative subject of 353 *the certificate associated to the signature MUST match. 355 - if the Identity is an address, it must be the right address: 357 *RECOMMENDATION H: If the Identity payload presented by the 358 *peer is an address, it MUST be the same address than the one 359 *used to transport IKE messages (aka the "peer address"). 361 - same for addresses used as (alternative) subjects: 363 *RECOMMENDATION I: If an address is used as the subject or as 364 *an alternative subject of the certificate associated to the 365 *signature, then the address used to transport IKE messages 366 *(aka the "peer address") SHOULD match the subject or an 367 *alternative subject. 369 "SHOULD match" means the default policy is to perform the check. 371 - last about Identity/address checks: 373 *RECOMMENDATION J: The case where the certificate associated 374 *to the signature has no address subject or alternative subject 375 *SHOULD be considered as a special case by policies. For 376 *instance, the policy MAY specify particular constraints for 377 *this case. 379 - of course, this can be a bit annoying for MNs which must use 380 in some cases their Co@ for transport of IKE messages so: 382 *RECOMMENDATION K: The addition of a Home Address Identity, 383 *which should allow strict application of previous I and J 384 *recommendations in all MN's peer cases, SHOULD be considered 385 *in IKE. 387 Today he possibility to include addresses in identities is not 388 considered to be a good idea. The appendix B about IKEv2 will 389 propose a very different way to solve concerns addressed by 390 recommendations of this section (H-K). 392 3.2 IKE and Identities (Phase Two) 394 In the phase two (a.k.a. quick mode) identities (IDci and IDcr) 395 are optional and designate the policy rule (in the SPD or in the 396 IKE software configuration) to apply: 398 - in Tunnel mode the peer addresses will be the outer header 399 addresses, and identities can denote the traffic selector part 400 of the policy rule. 402 - without identities the SA pairs will be applied to all traffic 403 not matched by a more specific policy between the peers using 404 the same addresses than in IKE messages. This is ambiguous so: 406 *RECOMMENDATION L1: When the phase one and phases two are 407 *allowed to use different (peer) addresses to transport 408 *messages, identity payloads SHOULD be used in phases two. 410 - in Tunnel mode there is an ambiguity about the endpoint 411 addresses: 413 *RECOMMENDATION L2: When the phase one and phases two are 414 *allowed to use different addresses, the endpoint addresses used 415 *in a phase 2 context MUST be the (peer) addresses used to 416 *transport IKE messages of this phase 2. 418 - junk identities are not useful: 420 *RECOMMENDATION M: Identity payloads used in phase two SHOULD 421 *clearly denote address sets. 423 - IKE [6] explicitly provides a "proxy case" usable for mobility: 425 *RECOMMENDATION N: The policy MAY authorize the establishment of 426 *a Transport mode SA pair using an address identity payload 427 *which does not match the (peer) address used to transport 428 *IKE messages. This authorization SHOULD be based on parameters 429 *provided in the phase one authentication, for instance the 430 *phase one peer identity and certificate. 432 3.3 IKE and Mobile IPv6 (Standard Case) 434 If the MN has the choice between using its H@ or a Co@ for IKE 435 exchanges, only the first choice makes sense with a standard CN. 436 Actually, when the initiator is the CN, it always use the H@. 437 Using the Co@ is more complex and should require a new phase 438 one with each peer after a movement. 440 Note that the IKE software should not even notice that the node is 441 mobile... For the same reason, the SA pairs should use the H@ as 442 the MN address, giving an IPsec transform before Mobility case. 444 *RECOMMENDATION O: With a standard CN, the MN SHOULD ignore the 445 *fact that it is a mobile node and SHOULD use its H@ for all IKE 446 *exchanges and for its own address in the SA pairs. To avoid both 447 *IPsec and Mobile IPv6 overheads, it SHOULD negotiate the Transport 448 *mode. 450 Transport mode was designed for end-to-end communications, IMHO 451 this recommendation should be written with MUSTs! 453 3.4 IKE and Mobile IPv6 (Home Agent Case) 455 Recommendation O does not work with the HA because, when the MN 456 boots in visit, it can use its H@ only after processing of the 457 first BU by the HA. This BU MUST be protected so it can not 458 be protected by IPsec (trivial bootstrap problem). 460 In fact there are two possible MN - HA SA pairs: 461 - a SA pair for BU/BA exchange protection. 462 - a SA pair for the MN <=> HA tunnel. 464 The first SA pair is a bit hairy to establish, because the MN 465 can only use its Co@ in some circumstances: 467 *RECOMMENDATION P: If BU/BA exchanges between the MN and the HA 468 *are protected by an IPsec SA pair, the establishment of this SA 469 *pair MUST be allowed using a Co@ for the transport of all IKE 470 *messages (i.e., the MN peer address is a Co@). 472 The detailed requirements are: 473 - an API should give a suitable Co@ for communications with 474 the HA (i.e., something like getsockname() which returns 475 the Co@ for a connected socket to the HA address in place 476 of the Ho@). 477 - phase one and phase two messages are sent using this Co@. 478 - the phase one identity is not an address if no transient 479 certificate for a Co@ is available. 480 - the authentication with this identity must be allowed 481 (including when recommendation J is enforced). 482 - until the home address identity is defined and implemented, 483 the phase two identity must be an address identity using the 484 H@, and this must be allowed (according to recommendation O). 485 - the result is a SA pair between the MN with its H@ and 486 the HA with its HA Address. The most adequat is AH Transport 487 mode (enough security and best efficiency). 489 This SA pair establishment stresses the issue of relative lifetimes 490 of the phase one and the SA pair so: 492 *RECOMMENDATION Q: IKE implementations MUST support lifetimes 493 *for the phase one, which are far longer or far shorter than 494 *the lifetime of SA pairs established by phases two. 496 and with very long phase one lifetimes: 498 *RECOMMENDATION R: IKE implementations SHOULD be able to lookup 499 *a still valid phase one state from a phase two message using 500 *different (peer) addresses for transport. For instance using the 501 *ISAKMP SA SPI a.k.a. cookies [5]. 503 The SA pair for the tunnel is more easy: the only problem is 504 about policies: 505 - A solution is to dynamically create the proper policy from 506 mobility information (i.e., BUs) and to establish the SA 507 pair described in section 2.6 (combined Tunnel mode with HA). 508 One can make things a bit faster reusing the phase one 509 (c.f. recommendations R and L2). 510 - Another solution is to create a SA pair using only the MN's H@ 511 (this can be done as soon as the first BU is processed because 512 the HA can use the standard routing optimization mode for its 513 own traffic. In fact this is the default behavior), and to 514 use a to-be-defined direct cooperation mechanism between IPsec 515 and mobility to update the outer MN address in the SA pair 516 (a good use of the HIP readdress [9]). 518 4. Security Considerations 520 At the exception of recommendations F and K, all recommendations 521 made in this document are about interpretation of IPsec 522 specification details. In fact, we are convinced these 523 recommendations shall improve the security of both IPsec and 524 Mobile IPv6. 526 5. Acknowledgments 528 Some of the MN - HA ideas were developed in the authentication vs. 529 authorization brainstorming, for instance the home address identity 530 (unfortunately I don't remember who proposed this). 532 Of course the current terrible interaction between IPsec and 533 Mobile IPv6 was and still is discussed in the mobile-ip WG list 534 and from time to time in the ipsec WG list too. So many thanks 535 to the little number of persons who participate to both lists. 537 The return routability check for new Co@ was proposed by Alper 538 Yegin and makes IPsec a very good candidate in the MN - CN case 539 when it is applicable. 541 I finish with authors of "open source" IKE implementations, 542 particularly Shoichi Sakane who has written the IPsec 543 implementation (including an IKE daemon, racoon) I use. 545 6. Normative References 547 [1] S. Kent, R. Atkinson, "Security Architecture for the Internet 548 Protocol", RFC 2401, November 1998. 550 [2] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, 551 November 1998. 553 [3] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", 554 RFC 2406, November 1998. 556 [4] D. Piper, "The Internet IP Security Domain of Interpretation 557 for ISAKMP", RFC 2407, November 1998. 559 [5] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet 560 Security Association and Key Management Protocol (ISAKMP)", 561 RFC 2408, November 1998. 563 [6] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 564 RFC 2409, November 1998. 566 7. Informative References 568 [7] F. Dupont, "Mobility-aware IPsec ESP tunnels", 569 draft-dupont-movesptun-00.txt, February 2001. 571 [8] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", 572 draft-ietf-mobileip-ipv6-20.txt, January 2002. 574 [9] R. Moskowitz, "Host Identity Payload And Protocol", 575 draft-moskowitz-hip-05.txt, November 2001. 577 [10] S. Deering, B. Zill, "Redundant Address Deletion when 578 Encapsulating IPv6 in IPv6", 579 draft-deering-ipv6-encap-addr-deletion-00.txt, November 2001. 581 [11] C. Perkins, "[mobile-ip] A new proposal for handling Home 582 Address destination options", http://playground.sun.com/mobile-ip/, 583 Message-ID: <3C6C7780.4CFAA7B4@iprg.nokia.com>, February 2002. 585 [12] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, 586 Version 2", RFC 2367, July 1998. 588 8. References for Appendixes 590 [13] C. Kaufman, ed., "Proposal for the IKEv2 Protocol", 591 draft-ietf-ipsec-ikev2-05.txt, February 2003. 593 [14] B. Korver, E. Rescorla, "The Internet IP Security PKI 594 Profile of ISAKMP and PKIX", 595 draft-ietf-ipsec-pki-profile-01.txt, October 2002. 597 [15] P. Hoffman, "Adding revised identities to IKEv2", 598 http://www.vpnc.org/ietf-ipsec/, 599 Message-Id: , 600 November 2002. 602 [16] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", 603 RFC 2956, October 2000. 605 [17] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks 606 or how NATs are even more evil than you believed", 607 draft-dupont-transient-pseudonat-01.txt, December 2002. 609 [18] S. Deering and all, "IPv6 Scoped Address Architecture", 610 draft-ietf-ipngwg-scoping-arch-04.txt, June 2002. 612 [19] Franck Le and all, "Mobile IPv6 Authentication, Authorization, 613 and Accounting Requirements", 614 draft-le-aaa-mipv6-requirements-01.txt, November 2002. 616 9. Author's Address 618 Francis Dupont 619 ENST Bretagne 620 Campus de Rennes 621 2, rue de la Chataigneraie 622 BP 78 623 35512 Cesson-Sevigne Cedex 624 FRANCE 625 Fax: +33 2 99 12 70 30 626 EMail: Francis.Dupont@enst-bretagne.fr 628 Wassim Haddad 629 Helsinki University of Technology 630 Theoretical Computer Science Laboratory 631 PO BOX 9201 632 HUT 02015 633 FINLAND 634 EMail: whaddad@tcs.hut.fi 636 10. Changes from Previous Drafts 638 Addition of recommendation E3 about return routability check 639 for new Co@. 641 Addition of Appendix A (list of recommendations), B (proposals 642 for IKEv2), C (return routability) and D (scoped addresses). 644 Introduction of the "peer address" term. 646 Some rewordings (from Wassim Haddad). 648 New appendix about mobile IPsec VPN. 650 Appendix A: List of Recommendations 652 A: Packets with a HAO matching an IPsec SA providing authentication 653 (i.e., AH or ESP with non-null authentication) MUST be accepted 654 (i.e., the HAO considered as verifiable) and the HAO MUST be 655 considered as verified [11] after successful IPsec processing. 657 B: IPsec in Tunnel mode and Mobile IPv6 SHOULD be combined in 658 order to avoid to add their overheads. 660 C1: The source address checked after each IPsec inbound processing 661 against the SA selector MUST be the inner header source address. 663 C2: The outer source address in Tunnel mode MUST NOT be checked 664 after or before IPsec inbound processing. 666 D: Dual stack (i.e., IPv4 and IPv6) IPsec implementations MUST 667 support IPvX in IPvY Tunnel modes with any X and Y, including 668 cases where X != Y. 670 E1: BU protected by an IPsec SA providing authentication MUST 671 be considered as authenticated. 673 E2: In the E1 case, all BU parameters MUST be covered by the 674 authentication. Specially when the authentication is provided 675 by an ESP transform, the new Co@ MUST be covered by using, for 676 instance, an alternate Co@ suboption. 678 E3: The CN SHOULD have the possibility to perform a return 679 routability check on a new Co@ before recommendations E1 and 680 E2 are applied. 682 F: Mobility signaling and IPsec SA management direct cooperation 683 SHOULD be considered (i.e., development of this kind of 684 mechanisms encouraged). 686 G: The Identity payload presented by the peer MUST be verified. For 687 instance, when certificates are used, the Identity and the 688 subject or an alternative subject of the certificate associated 689 to the signature MUST match. 691 H: If the Identity payload presented by the peer is an address, 692 it MUST be the same address than the one used to transport 693 IKE messages (aka the "peer address"). 695 I: If an address is used as the subject or an alternative subject 696 of the certificate associated to the signature, then the address 697 used to transport IKE messages (aka the "peer address") SHOULD 698 match the subject or an alternative subject. 700 J: The case where the certificate associated to the signature has 701 no address subject or alternative subject SHOULD be considered 702 as a special case by policies. For instance, the policy MAY 703 specify particular constraints for this case. 705 K: The addition of a Home Address Identity, which should allow 706 strict application of previous I and J recommendations in all 707 MN's peer cases, SHOULD be considered in IKE. 709 L1: When the phase one and phases two are allowed to use different 710 (peer) addresses to transport messages, identity payloads SHOULD 711 be used in phases two. 713 L2: When the phase one and phases two are allowed to use different 714 addresses, the endpoint addresses used in a phase 2 context 715 MUST be the (peer) addresses used to transport IKE messages of 716 this phase 2. 718 M: Identity payloads used in phase two SHOULD denote clearly 719 address sets. 721 N: The policy MAY authorize the establishment of a Transport mode 722 SA pair using an address identity payload which does not match 723 the (peer) address used to transport IKE messages. This 724 authorization SHOULD be based on parameters provided in the 725 phase one authentication, for instance the phase one peer 726 identity and certificate. 728 O: With a standard CN, the MN SHOULD ignore the fact that it is a 729 mobile node and SHOULD use its H@ for all IKE exchanges and for 730 its own address in the SA pairs. To avoid both IPsec and Mobile 731 IPv6 overheads, it SHOULD negotiate the Transport mode. 733 P: If BU/BA exchanges between the MN and the HA are protected by 734 an IPsec SA pair, the establishment of this SA pair MUST be 735 allowed using a Co@ for the transport of all IKE messages (i.e., 736 the MN peer address is a Co@). 738 Q: IKE implementations MUST support lifetimes for the phase one 739 which are far longer or far shorter than the lifetime of SA 740 pairs established by phases two. 742 R: IKE implementations SHOULD be able to lookup still valid phase 743 one state from a phase two message using different (peer) 744 addresses for transport. For instance using the ISAKMP SA SPI 745 a.k.a. cookies [5]. 747 Appendix B: Proposals for IKEv2 749 Many recommendations are directly applicable to IKEv2 [13]: 750 - recommendations G, O, P apply without modifications. 751 - recommendations L1, L2 and N applies to traffic selectors 752 in place of phase two identities. 753 - recommendation M is integrated in IKEv2. 754 - recommendation R is partially integrated in section 2.6 755 of [13], but we propose to make very clear the IKE-SA lookup 756 MUST be done using the cookies as a SPI *only*. Note that 757 IKEv2 guarantees the uniqueness of these "SPIs". 759 [14] introduces the term "peer addresses" for the addresses used 760 for the transport of IKE messages and includes the recommendations 761 G, H and I. [15] is not directly applicable to IKEv2 but [15] (not 762 yet included in the IKEv2 draft) proposes a new form of identities 763 without any kind of binding to addresses. 765 In IKEv2 the phase one SA is named the IKE SA and when it is 766 deleted all the IPsec SAs it negotiated have to be deleted too 767 (so the recommendation Q does not stand). The idea is to solve 768 the dead peer detection issue by keepalives over the IKE SA. 770 *PROPOSAL 1: IKEv2 implementations MUST lookup IKE-SA using 771 *only the SPI at the exclusion of peer addresses. 773 Identities should not include addresses as recommended in [16] 774 so recommendations H to K are obsolete in the IKEv2 context. 775 (this is a call to adopt [15] ASAP) 777 *PROPOSAL 2: IKEv2 identity payloads MUST only use abstract 778 *identities as recommended in [16] by the IAB and proposed by [15]. 780 But this and the section 4.11 "Address and Port Agility" of [13] 781 remove any check of peer addresses which are still part of 782 established SAs, opening the door to attacks as described in 783 [17]. But mobility really needs address agility so: 785 *PROPOSAL 3: The section 4.11 should specify full address agility. 787 The first counter-measure against abuse of this address agility 788 is to protect the integrity of transport headers. The new 789 notifications NAT-DETECTION-SOURCE-IP and NAT-DETECTION- 790 DESTINATION-IP are the beginning of a solution. 792 *PROPOSAL 4: IKEv2 MUST provide a way to protect the integrity 793 *of transport parameters (peer addresses, ports and protocol). 795 *PROPOSAL 5: The default policy SHOULD be the protection of 796 *the integrity of transport parameters for IPv6. 798 These proposals defeat en-route modifications of messages, 799 i.e., fulfill some mobility requirements, but not all of 800 them because these proposals give no proof about the real 801 origin of messages, i.e., one should trust its peer. 802 The solution is of course a simple return routability check, 803 and IKEv2 already uses this kind of mechanisms in the 804 "Responder under attack" case (IKE_SA_init_reject). 806 *PROPOSAL 6: A mechanism MUST be provided in order to make return 807 *routability checks available on peer address changes. 809 *PROPOSAL 7: The default policy SHOULD be to perform 810 *return routability checks on peer address changes. 812 Now that mobility can be securely handled (this is not the 813 case for NAT traversal but we believe this issue can not be 814 solved, c.f. [17]), we can look for some dedicated improvements. 815 The fist special case to be dealt with is the MN - HA SA pair 816 to protect the BU/BA exchange a.k.a. the "home registration". 818 *PROPOSAL 8: When the policy authorizes it, a traffic selector 819 *in Transport mode MAY override peer addresses as SA selectors. 821 (this is a reformulation of recommendations N and P.) 823 The other item is to instantiate the recommendation F: 825 *PROPOSAL 9: A new mechanism MUST be defined for the update 826 *of the peer address in the SA pair (the source outer address of 827 *the inbound SA and the destination outer address of the outbound 828 *SA) without mandatory rekeying. 830 Appendix C: Return Routability 832 The proposed return routability check assumes these properties: 833 - a secret is shared with the peer, i.e., there is a proof 834 that the received packets are from the peer. 835 - an anti-replay mechanism proves the received packets are fresh. 836 If the exchange involved some hard state change (for instance the 837 proposal 9), a sequencing mechanism should be provided too. 839 The return routability check does not give a proof that the peer is 840 at the given address, it only proves the peer is on the path. 841 For more details about return routability check theory, please 842 refer to [8]. 844 Appendix D: Scoped Addresses 846 This topics is not really a Mobile IPv6 one, but in practice the 847 "mobile VPN" case there is a heavy usage of limited scope or 848 private addresses. 850 The issue is that addresses carried in identity or traffic 851 selector payloads are not clothed with zone identifiers. 852 Only the peer addresses used to transport messages have an 853 indirect indication of their zones. 855 The IPv6 scoped address architecture [18] gives the properties 856 of zones: at a given scope, zones formed a partition, i.e., 857 an interface belongs to one and only one zone. They have an 858 inclusion property too, i.e., a zone of a given scope is 859 fully included into a zone of any higher scope. This gives 860 an inheritance property which is safe when it is used in 861 the proper way: to establish SAs with global addresses with 862 IKE running over link-local addresses is safe, the opposite 863 is not. 865 *RULE: The default policy SHOULD accept scoped addresses as 866 *selectors of SAs only when they are established using peer 867 *addresses (for the transport of IKE/IKEv2/etc messages) which 868 *are in fully included zones. 870 Appendix E: mobile IPsec VPN 872 Mobile IPsec Virtual Private Networks (VPNs) provides the same kind 873 of functionality than mobile IP: the VPN client (the Mobile Node in 874 the mobility context) opens an ESP tunnel with a Security Gateway 875 (the equivalent of a Home Agent) located in the home site. 877 Even if the style of mobile IPsec VPNs are more Mobile IPv6 than 878 Mobile IPv4 (there is no equivalent of Foreign Agents for 879 instance), they can be used for the two versions of IP so this 880 appendix is about both. 882 Current mobile IPsec VPNs have no Security Gateway detection, 883 support for multiple inner addresses, prefix discovery, etc, but 884 they can be connected to a remote network access control with an 885 optional address allocation. Today they have no support for an 886 extended AAA system where the AAA infrastructure connects the local 887 and remote network access control with some assistance to the 888 initial security setup (via credentials and/or piggy-backing of IKE 889 initial exchanges [19]). 891 The layout of data packets of mobile IPsec VPNs are exactly the 892 same than for Mobile IPv6 with an ESP protected MN-HA bidirectional 893 tunnel (the outer header client address is a Care-of Address, the 894 inner one is the Home Address) at one exception: in Mobile IPv6 the 895 Home Agent is a correspondent node for its own address, for 896 instance the Home Agent sends genuine packets to the Mobile Node 897 using a Routing Header, not through the tunnel. If the 898 corresponding rule of [8] (section 9.3.2 Sending Packets to a 899 Mobile Node) is applied only to Mobile IPv6 signaling packets, 900 mobile IPsec VPNs and Mobile IPv6 are indistinguishable. 902 So mobile IPsec VPNs are a good replacement for unoptimized Mobile 903 IPv6 or for Mobile IPv4 with secure reverse tunneling. Movements 904 can be handled by peer address update mechanisms, including 905 rekeying.