idnits 2.17.1 draft-dupont-ipsec-mipv6-02.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 143: '...*authentication) MUST be accepted (i.e...' RFC 2119 keyword, line 144: '... *as verifiable) and the HAO MUST be considered as verified [11]...' RFC 2119 keyword, line 166: '... in Tunnel mode and Mobile IPv6 SHOULD...' RFC 2119 keyword, line 183: '... SA lookup and the source address MUST...' RFC 2119 keyword, line 215: '...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 (January 2003) is 7771 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 47 == Missing Reference: '13' is mentioned on line 767, but not defined == Missing Reference: '14' is mentioned on line 746, but not defined == Missing Reference: '15' is mentioned on line 765, but not defined == Missing Reference: '16' is mentioned on line 765, but not defined == Missing Reference: '17' is mentioned on line 801, but not defined == Missing Reference: '18' is mentioned on line 842, 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-19 == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-05 Summary: 13 errors (**), 0 flaws (~~), 9 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 June 2003 January 2003 5 How to make IPsec more mobile IPv6 friendly 7 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Abstract 35 IPsec specifications [1-6] do not work well with any mobility 36 device based on addresses [7]. Mobile IPv6 interaction with IPsec 37 is still far from being well achieved. This is mainly due to bad 38 interpretations of IPsec specifications. HIP (Host Identity 39 Payload) [9] should change this regrettable situation. 41 This document specifies some points where improvements can be 42 made in many current implementations, on the way of making IPsec 43 more suitable for Mobile IPv6. 45 1. Introduction 47 This document assumes thar the reader knows IPsec (i.e., [1-6]) 48 but not Mobile IPv6. This section explains how Mobile IPv6 works. 50 In Mobile IPv6, each Mobile Node (MN) is always identified by 51 its Home Address (H@), regardless of its current point of 52 attachment to the Internet. While situated away from its home, 53 a MN is also associated with a Care-of Address (Co@), which 54 provides information about the mobile node's current location. 55 IPv6 packets from a Correspondent Node (CN) addressed to a MN's 56 H@ are transparently routed to its Co@. 58 The MN has a special CN, the Home Agent (HA), which is used to 59 intercept packets addressed to the MN's H@ on the home link and 60 to forward them to the MN at its current Co@ through a tunnel. 62 End-to-end communications between a MN and a CN can use one of 63 these three modes: 64 - bidirectional tunneling with the HA: 65 MN => HA -> CN (=> denotes an encapsulation) 66 CN -> HA => MN 67 The CN knows only the MN's H@ regardless whether the MN is 68 mobile or not. This mode is very safe but not optimized at all. 69 - triangular routing: 70 MN ~> CN (~> denotes the use of an extension header) 71 CN -> HA => MN 72 The MN uses a Home Address Option (HAO): it puts its Co@ which 73 is topologically correct into the source address field of the 74 IPv6 header, and puts its H@ in the HAO. 75 - optimized routing: 76 MN ~> CN 77 CN ~> MN 78 The MN uses a HAO for packets to the CN, the CN uses a Routing 79 Header (RH) and puts the MN's Co@ in the destination address 80 field of the IPv6 header, and the MN's H@ in the RH. This mode 81 raises many security concerns, mainly about the mobility 82 signaling, but is very efficient. 84 These uses of HAO and RH are in fact degenerated tunnels as 85 shown by the Deering/Zill tunneling document [10], i.e., they 86 can be considered as IPv6 in IPv6 tunnels where two addresses 87 in the outer and inner IPv6 headers are redundant so one instance 88 is removed. 90 The association between a Co@ and the H@ is named "binding" and 91 is cached by CNs. Bindings are managed (i.e., created, changed 92 and deleted) by signaling messages named Binding Updates (BUs). 94 The term node in MN is a bit misleading: mobile routers are not 95 considered by current Mobile IPv6 specifications and communications 96 in this document are always end-to-end. 98 2. IPsec Architecture and Mobile IPv6 100 IPsec defines two modes, Transport and Tunnel modes. 101 As mobile IPv6 itself is based on real or degenerated tunneling, 102 there are three possible basic interactions: 103 - Transport mode after Mobile IPv6 tunneling, 104 - Transport mode before Mobile IPv6 tunneling 105 - A combination between Tunnel mode and Mobile IPv6 tunneling. 107 2.1 Transport Mode After Mobile IPv6 109 This case is defined only when Mobile IPv6 uses real tunneling, 110 i.e., in current specifications, between the MN and its HA. 111 As the IPv6 header (and addresses!) viewed by IPsec is the outer 112 one, in general this case has no interest (the MN's outer address 113 is a transient Co@, the interesting one, the H@, is in the inner 114 header). 116 2.2 Transport Mode Before Mobile IPv6 118 In this case, the IPsec transform is applied to the payload of 119 an ordinary packet between the MN and the CN. The MN will use 120 its static/long term H@. 121 After Mobile IPv6 includes its extension header corresponding to 122 the mode used, the following cases can be depicted: 124 - the bidirectional tunneling is perfectly transparent: IPsec and 125 Mobile IPv6 do not interfere. The same consideration applies to 126 the HA => MN tunnel. 128 - the triangular routing is more interesting and gives different 129 results for the Authentication Header (AH [2]) and the 130 Encapsulating Security Payload (ESP [3]): 131 * AH authenticates both Co@ (in the IPv6 header) and the H@ 132 (in the HAO) 133 * ESP with authentication will reject fake packets because 134 the attacker may not know the authentication shared secret. 136 So with authentication the only possible attack is a "Denial 137 of Services" launched by an attacker who knows the SPI and is 138 likely able to inject fake traffic without HAO. So this is an 139 intrinsic IPsec thread. 141 *RECOMMENDATION A: Packets with a HAO matching an IPsec SA 142 *providing authentication (i.e., AH or ESP with non-null 143 *authentication) MUST be accepted (i.e., the HAO considered 144 *as verifiable) and the HAO MUST be considered as verified [11] 145 *after successful IPsec processing. 147 - the optimized routing is like triangular routing for the MN ~> 148 CN way with, in addition to recommendation A, the common way to 149 verify HAO: the "binding cache entry check". Symmetrically IPsec 150 adds nothing to the RH verification because the MN has already 151 all important informations. 153 - the optimized routing between two MNs is an interesting case 154 not yet fully addressed by Mobile IPv6 specifications [8]: 155 RH and HAO have more overhead than a plain tunnel so a 156 combined Tunnel mode with Mobile IPv6 becomes very 157 interesting in this special case... 159 2.3 Tunnel Mode not combined with Mobile IPv6 161 "Not combined" means there are two overhead, one for IPsec 162 tunneling and another one for Mobile IPv6 extra headers, when 163 obviously one encapsulation provides enough addresses (two sources 164 and two destinations) for Mobile IPv6! 166 *RECOMMENDATION B: IPsec in Tunnel mode and Mobile IPv6 SHOULD 167 *be combined in order to avoid to add their overheads. 169 2.4 Addresses of SAs 171 SAs can be characterized by: 172 - zero address (proposed inbound processing for unicast) 173 - one address (destination in IPsec inbound processing [1]) 174 - two addresses (source and destination selectors [1]) 175 - three addresses (source, destination and proxy in PF_KEY [12]) 176 - four addresses (in Tunnel mode) 178 This is a bit confusing and gives security holes and/or extra 179 checks on addresses which are highly unfriendly with Mobile IPv6. 181 The Transport mode is easy because there are always exactly two 182 addresses. For instance in inbound processing, the destination 183 address is used for the SA lookup and the source address MUST 184 be checked ([1], section 5.2.1). So this document will assume 185 the Tunnel mode is used. 187 In general, the SADB is not designed to be managed directly 188 and/or by itself, i.e., without the SPD. Addresses are handled 189 by the SPD with a pair of selectors which characterized the 190 source and the destination of the traffic which receives IPsec 191 protection. SPD entries specify the type of IPsec processing 192 (for instance one type is the bypassing of IPsec: this is needed 193 by IKE for its own messages [1]) and the parameters of SAs 194 to use or to build (using SADB_ACQUIRE PF_KEY messages [12]). 196 According to [1] the traffic selection is divided between the 197 SPD and the SADB (a SPD entry points to many matching SAs) but 198 this cannot be realized using IKE so this point is very 199 confusing, and some implementations are nearly nonconform. 201 IKE (and its successor(s)) is designed to build SAs per pairs, 202 so IPsec implementations, using PF_KEY, should comply for 203 Tunnel mode SAs with the following interpretation: 204 - the source and the destination addresses are plain addresses 205 in the general case and designate the end points of the tunnel 206 (i.e., there are the outer header addresses). 207 - the inner source address is the proxy address (and exists only 208 in the Tunnel mode). This can be something else than a plain 209 address (i.e., for instance a prefix) but not in the Mobile IPv6 210 case. The check may be performed after each IPsec inbound 211 processing [1] or at the SPD check (not the specified way but 212 the final result is the same). 214 *RECOMMENDATION C1: The source address checked after each 215 *IPsec inbound processing against the SA selector MUST be 216 *the inner header source address. 218 - the selection of the traffic to be processed is handled 219 by SPD entries. This includes the future inner addresses 220 in outbound processing. Guidelines are to use the inbound 221 processing rules for SADB design, the outbound processing 222 rules for SPD design and to complete by symmetry (with the 223 funny (?) side-effect that source and destination roles can 224 be reversed). 226 RFC 2401 [1] has detailed rules about the outer source address but 227 they are commonly misunderstood: checking it gives no extra 228 security because once a attacker can get the SPI, he can inject 229 fake traffic too. But this check harm nearly all mobility 230 mechanisms based on addresses, even nomadism a.k.a. the "road 231 warrior" case. 233 *RECOMMENDATION C2: The outer source address in Tunnel mode 234 *MUST NOT be checked after or before IPsec inbound processing. 236 This recommendation does not apply to the SPD checking, i.e., 237 step 4 of RFC 2401 [1] section 5.2.1. 239 This recommendation by itself does not solve the problem of the 240 other SA of the pair: the MN may change its Co@ and continue 241 to use the SA to the CN. But the other way/SA will work only 242 when the other SA will be updated or rebuilt with the new Co@ 243 as the destination. 245 BTW, RFC 2401 [1] specifies IPv6 in IPv4 and IPv4 in IPv6 tunnels 246 and these tunnels are taken into account in PF_KEY [12] so: 248 *RECOMMENDATION D: Dual stack (i.e., IPv4 and IPv6) IPsec 249 *implementations MUST support IPvX in IPvY Tunnel modes with 250 *any X and Y, including cases where X != Y. 252 2.5 Combined Tunnel Mode with Mobile IPv6 (Standard Case) 254 When IPsec in Tunnel mode is combined with Mobile IPv6, there 255 is one encapsulation with the fixed H@ in the inner header 256 and a transient Co@ in the outer header. Such configuration is the 257 opposite of the common Tunnel mode usage between two security 258 gateways. The CN can be itself a MN: only one detail not directly 259 related to IPsec matters: mobility has to support the simultaneous 260 movement of both peers (handled by fallback through a HA for 261 instance in Mobile IPv6, c.f. [8]). 263 Between two movements the IPsec tunnels are not very special, 264 they look like end-to-end IPsec tunnels between two peers. 265 The only unusual detail is that the outer and inner addresses 266 can be different (when the MN is not at home), which is an issue 267 for IKE. 269 The interesting case is what happens when a Co@ changes: 270 the MN should send a BU to the CN which, according to 271 recommendation C, must not be filtered out because the 272 Co@ is not the same. 274 *RECOMMENDATION E1: BU protected by an IPsec SA providing 275 *authentication MUST be considered as authenticated. 277 *RECOMMENDATION E2: In the E1 case, all BU parameters MUST 278 *be covered by the authentication. Specially when the 279 *authentication is provided by an ESP transform, the new Co@ 280 *MUST be covered by using, for instance, an alternate Co@ 281 *suboption. 283 The CN could ask for a proof that the new Co@ is not a fake one, 284 i.e., the default policy may be to check the new Co@ in order 285 to avoid reflection attacks. This check is a return routability 286 check: the CN sends a question to the MN at its new Co@ with 287 a predictable answer. In a thread on the mobile-ip mailing list, 288 we proposed to reject the first BU with a "sequence number 289 out of the window" error. 291 *RECOMMENDATION E3: The CN SHOULD have the possibility to 292 *perform a return routability check on a new Co@ before 293 *recommendations E1 and E2 are applied. 295 As explained before, to deal with the BU is not enough for 296 the CN ~> MN way. For instance, the Binding Acknowledgment (BA) 297 can be protected only when the reversed SA is updated or rebuilt. 299 *RECOMMENDATION F: Mobility signaling and IPsec SA management 300 *direct cooperation SHOULD be considered (i.e., development of 301 *this kind of mechanisms encouraged). 303 2.6 Combined Tunnel Mode with Mobile IPv6 (Home Agent Case) 305 This section does not consider traffic from the HA itself 306 which is handled by routing optimization as for a standard CN. 307 It is only about the MN <=> HA bidirectional tunnel. 309 The addresses used for this tunnel are very simple: 310 - on the MN side, inner header address is the H@, outer a Co@. 311 - on the HA side, inner header address is any valid address 312 (unicast address when used as a source address) and the 313 outer address is the HA address [8]. 314 IPsec considerations are near the same than for standard CNs. 315 In fact, things are simpler because one can assume the HA is 316 never mobile. Recommendation F applies but is not useful when 317 no IPsec SA exists, i.e., when a MN boots in visit: this will 318 be the special case in IKE considerations (next section). 320 3. IKE and Mobile IPv6 322 There are three basic issues: 323 - how to handle the multiple addresses of a MN? In the phase 324 one? In a phase two? 325 - how to establish SAs between a MN and a standard CN? 326 - how to establish SAs between a MN from a foreign link 327 and its HA the first time? 328 This document uses the name IKE [6] for the IPsec DOI [4] 329 and ISAKMP [5] framework too. Some proposals for IKEv2 [13] 330 (used as an instance of a Son-of-Ike with two phases) can be 331 found in the appendix B. 333 3.1 IKE and Identities (Phase One) 335 In the phase one, identities (IDii and IDir) designate the peers 336 so subnet and range identities may not be used. This document 337 assumes a phase one with digital signatures using a X.509 style 338 of certificates, but most of the considerations applies to 339 public key authentications too. 341 In phase one, a peer is identified by its address used for the 342 transport of IKE messages (aka the "peer address") and its 343 identity payload. Identities, in the general meaning, may be 344 present in certificates too but all cases are not equivalent: 346 - the Identity must be related to the certificate: 348 *RECOMMENDATION G: The Identity payload presented by the peer 349 *MUST be verified. For instance, when certificates are used, 350 *the Identity and the subject or an alternative subject of 351 *the certificate associated to the signature MUST match. 353 - if the Identity is an address, it must be the right address: 355 *RECOMMENDATION H: If the Identity payload presented by the 356 *peer is an address, it MUST be the same address than the one 357 *used to transport IKE messages (aka the "peer address"). 359 - same for addresses used as (alternative) subjects: 361 *RECOMMENDATION I: If an address is used as the subject or as 362 *an alternative subject of the certificate associated to the 363 *signature, then the address used to transport IKE messages 364 *(aka the "peer address") SHOULD match the subject or an 365 *alternative subject. 367 "SHOULD match" means the default policy is to perform the check. 369 - last about Identity/address checks: 371 *RECOMMENDATION J: The case where the certificate associated 372 *to the signature has no address subject or alternative subject 373 *SHOULD be considered as a special case by policies. For 374 *instance, the policy MAY specify particular constraints for 375 *this case. 377 - of course, this can be a bit annoying for MNs which must use 378 in some cases their Co@ for transport of IKE messages so: 380 *RECOMMENDATION K: The addition of a Home Address Identity, 381 *which should allow strict application of previous I and J 382 *recommendations in all MN's peer cases, SHOULD be considered 383 *in IKE. 385 Today he possibility to include addresses in identities is not 386 considered to be a good idea. The appendix B about IKEv2 will 387 propose a very different way to solve concerns addressed by 388 recommendations of this section (H-K). 390 3.2 IKE and Identities (Phase Two) 392 In the phase two (a.k.a. quick mode) identities (IDci and IDcr) 393 are optional and designate the policy rule (in the SPD or in the 394 IKE software configuration) to apply: 396 - in Tunnel mode the peer addresses will be the outer header 397 addresses, and identities can denote the traffic selector part 398 of the policy rule. 400 - without identities the SA pairs will be applied to all traffic 401 not matched by a more specific policy between the peers using 402 the same addresses than in IKE messages. This is ambiguous so: 404 *RECOMMENDATION L1: When the phase one and phases two are 405 *allowed to use different (peer) addresses to transport 406 *messages, identity payloads SHOULD be used in phases two. 408 - in Tunnel mode there is an ambiguity about the endpoint 409 addresses: 411 *RECOMMENDATION L2: When the phase one and phases two are 412 *allowed to use different addresses, the endpoint addresses used 413 *in a phase 2 context MUST be the (peer) addresses used to 414 *transport IKE messages of this phase 2. 416 - junk identities are not useful: 418 *RECOMMENDATION M: Identity payloads used in phase two SHOULD 419 *clearly denote address sets. 421 - IKE [6] explicitly provides a "proxy case" usable for mobility: 423 *RECOMMENDATION N: The policy MAY authorize the establishment of 424 *a Transport mode SA pair using an address identity payload 425 *which does not match the (peer) address used to transport 426 *IKE messages. This authorization SHOULD be based on parameters 427 *provided in the phase one authentication, for instance the 428 *phase one peer identity and certificate. 430 3.3 IKE and Mobile IPv6 (Standard Case) 432 If the MN has the choice between using its H@ or a Co@ for IKE 433 exchanges, only the first choice makes sense with a standard CN. 434 Actually, when the initiator is the CN, it always use the H@. 435 Using the Co@ is more complex and should require a new phase 436 one with each peer after a movement. 438 Note that the IKE software should not even notice that the node is 439 mobile... For the same reason, the SA pairs should use the H@ as 440 the MN address, giving an IPsec transform before Mobility case. 442 *RECOMMENDATION O: With a standard CN, the MN SHOULD ignore the 443 *fact that it is a mobile node and SHOULD use its H@ for all IKE 444 *exchanges and for its own address in the SA pairs. To avoid both 445 *IPsec and Mobile IPv6 overheads, it SHOULD negotiate the Transport 446 *mode. 448 Transport mode was designed for end-to-end communications, IMHO 449 this recommendation should be written with MUSTs! 451 3.4 IKE and Mobile IPv6 (Home Agent Case) 453 Recommendation O does not work with the HA because, when the MN 454 boots in visit, it can use its H@ only after processing of the 455 first BU by the HA. This BU MUST be protected so it can not 456 be protected by IPsec (trivial bootstrap problem). 458 In fact there are two possible MN - HA SA pairs: 459 - a SA pair for BU/BA exchange protection. 460 - a SA pair for the MN <=> HA tunnel. 462 The first SA pair is a bit hairy to establish, because the MN 463 can only use its Co@ in some circumstances: 465 *RECOMMENDATION P: If BU/BA exchanges between the MN and the HA 466 *are protected by an IPsec SA pair, the establishment of this SA 467 *pair MUST be allowed using a Co@ for the transport of all IKE 468 *messages (i.e., the MN peer address is a Co@). 470 The detailed requirements are: 471 - an API should give a suitable Co@ for communications with 472 the HA (i.e., something like getsockname() which returns 473 the Co@ for a connected socket to the HA address in place 474 of the Ho@). 475 - phase one and phase two messages are sent using this Co@. 476 - the phase one identity is not an address if no transient 477 certificate for a Co@ is available. 478 - the authentication with this identity must be allowed 479 (including when recommendation J is enforced). 480 - until the home address identity is defined and implemented, 481 the phase two identity must be an address identity using the 482 H@, and this must be allowed (according to recommendation O). 483 - the result is a SA pair between the MN with its H@ and 484 the HA with its HA Address. The most adequat is AH Transport 485 mode (enough security and best efficiency). 487 This SA pair establishment stresses the issue of relative lifetimes 488 of the phase one and the SA pair so: 490 *RECOMMENDATION Q: IKE implementations MUST support lifetimes 491 *for the phase one, which are far longer or far shorter than 492 *the lifetime of SA pairs established by phases two. 494 and with very long phase one lifetimes: 496 *RECOMMENDATION R: IKE implementations SHOULD be able to lookup 497 *a still valid phase one state from a phase two message using 498 *different (peer) addresses for transport. For instance using the 499 *ISAKMP SA SPI a.k.a. cookies [5]. 501 The SA pair for the tunnel is more easy: the only problem is 502 about policies: 503 - A solution is to dynamically create the proper policy from 504 mobility information (i.e., BUs) and to establish the SA 505 pair described in section 2.6 (combined Tunnel mode with HA). 506 One can make things a bit faster reusing the phase one 507 (c.f. recommendations R and L2). 508 - Another solution is to create a SA pair using only the MN's H@ 509 (this can be done as soon as the first BU is processed because 510 the HA can use the standard routing optimization mode for its 511 own traffic. In fact this is the default behavior), and to 512 use a to-be-defined direct cooperation mechanism between IPsec 513 and mobility to update the outer MN address in the SA pair 514 (a good use of the HIP readdress [9]). 516 4. Security Considerations 518 At the exception of recommendations F and K, all recommendations 519 made in this document are about interpretation of IPsec 520 specification details. In fact, we are convinced these 521 recommendations shall improve the security of both IPsec and 522 Mobile IPv6. 524 5. Acknowledgments 526 Some of the MN - HA ideas were developed in the authentication vs. 527 authorization brainstorming, for instance the home address identity 528 (unfortunately I don't remember who proposed this). 530 Of course the current terrible interaction between IPsec and 531 Mobile IPv6 was and still is discussed in the mobile-ip WG list 532 and from time to time in the ipsec WG list too. So many thanks 533 to the little number of persons who participate to both lists. 535 The return routability check for new Co@ was proposed by Alper 536 Yegin and makes IPsec a very good candidate in the MN - CN case 537 when it is applicable. 539 Wassim Haddad helped me to make this version of the document 540 a bit more readable. 542 I finish with authors of "open source" IKE implementations, 543 particularly Shoichi Sakane who has written the IPsec 544 implementation (including an IKE daemon, racoon) I use. 546 6. Normative References 548 [1] S. Kent, R. Atkinson, "Security Architecture for the Internet 549 Protocol", RFC 2401, November 1998. 551 [2] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, 552 November 1998. 554 [3] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", 555 RFC 2406, November 1998. 557 [4] D. Piper, "The Internet IP Security Domain of Interpretation 558 for ISAKMP", RFC 2407, November 1998. 560 [5] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet 561 Security Association and Key Management Protocol (ISAKMP)", 562 RFC 2408, November 1998. 564 [6] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 565 RFC 2409, November 1998. 567 7. Informative References 569 [7] F. Dupont, "Mobility-aware IPsec ESP tunnels", 570 draft-dupont-movesptun-00.txt, February 2001. 572 [8] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", 573 draft-ietf-mobileip-ipv6-19.txt, October 2002. 575 [9] R. Moskowitz, "Host Identity Payload And Protocol", 576 draft-moskowitz-hip-05.txt, November 2001. 578 [10] S. Deering, B. Zill, "Redundant Address Deletion when 579 Encapsulating IPv6 in IPv6", 580 draft-deering-ipv6-encap-addr-deletion-00.txt, November 2001. 582 [11] C. Perkins, "[mobile-ip] A new proposal for handling Home 583 Address destination options", http://playground.sun.com/mobile-ip/, 584 Message-ID: <3C6C7780.4CFAA7B4@iprg.nokia.com>, February 2002. 586 [12] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, 587 Version 2", RFC 2367, July 1998. 589 8. References for Appendixes 591 [13] C. Kaufman, ed., "Proposal for the IKEv2 Protocol", 592 draft-ietf-ipsec-ikev2-04.txt, January 2003. 594 [14] B. Korver, E. Rescorla, "The Internet IP Security PKI 595 Profile of ISAKMP and PKIX", 596 draft-ietf-ipsec-pki-profile-01.txt, October 2002. 598 [15] P. Hoffman, "Adding revised identities to IKEv2", 599 http://www.vpnc.org/ietf-ipsec/, 600 Message-Id: , 601 November 2002. 603 [16] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", 604 RFC 2956, October 2000. 606 [17] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks 607 or how NATs are even more evil than you believed", 608 draft-dupont-transient-pseudonat-01.txt, December 2002. 610 [18] S. Deering and all, "IPv6 Scoped Address Architecture", 611 draft-ietf-ipngwg-scoping-arch-04.txt, June 2002. 613 9. Author's Address 615 Francis Dupont 616 ENST Bretagne 617 Campus de Rennes 618 2, rue de la Chataigneraie 619 BP 78 620 35512 Cesson-Sevigne Cedex 621 FRANCE 622 Fax: +33 2 99 12 70 30 623 EMail: Francis.Dupont@enst-bretagne.fr 625 10. Changes from Previous Drafts 627 Addition of recommendation E3 about return routability check 628 for new Co@. 630 Addition of Appendix A (list of recommendations), B (proposals 631 for IKEv2), C (return routability) and D (scoped addresses). 633 Introduction of the "peer address" term. 635 Some rewordings (from Wassim Haddad). 637 Appendix A: List of Recommendations 639 A: Packets with a HAO matching an IPsec SA providing authentication 640 (i.e., AH or ESP with non-null authentication) MUST be accepted 641 (i.e., the HAO considered as verifiable) and the HAO MUST be 642 considered as verified [11] after successful IPsec processing. 644 B: IPsec in Tunnel mode and Mobile IPv6 SHOULD be combined in 645 order to avoid to add their overheads. 647 C1: The source address checked after each IPsec inbound processing 648 against the SA selector MUST be the inner header source address. 650 C2: The outer source address in Tunnel mode MUST NOT be checked 651 after or before IPsec inbound processing. 653 D: Dual stack (i.e., IPv4 and IPv6) IPsec implementations MUST 654 support IPvX in IPvY Tunnel modes with any X and Y, including 655 cases where X != Y. 657 E1: BU protected by an IPsec SA providing authentication MUST 658 be considered as authenticated. 660 E2: In the E1 case, all BU parameters MUST be covered by the 661 authentication. Specially when the authentication is provided 662 by an ESP transform, the new Co@ MUST be covered by using, for 663 instance, an alternate Co@ suboption. 665 E3: The CN SHOULD have the possibility to perform a return 666 routability check on a new Co@ before recommendations E1 and 667 E2 are applied. 669 F: Mobility signaling and IPsec SA management direct cooperation 670 SHOULD be considered (i.e., development of this kind of 671 mechanisms encouraged). 673 G: The Identity payload presented by the peer MUST be verified. For 674 instance, when certificates are used, the Identity and the 675 subject or an alternative subject of the certificate associated 676 to the signature MUST match. 678 H: If the Identity payload presented by the peer is an address, 679 it MUST be the same address than the one used to transport 680 IKE messages (aka the "peer address"). 682 I: If an address is used as the subject or an alternative subject 683 of the certificate associated to the signature, then the address 684 used to transport IKE messages (aka the "peer address") SHOULD 685 match the subject or an alternative subject. 687 J: The case where the certificate associated to the signature has 688 no address subject or alternative subject SHOULD be considered 689 as a special case by policies. For instance, the policy MAY 690 specify particular constraints for this case. 692 K: The addition of a Home Address Identity, which should allow 693 strict application of previous I and J recommendations in all 694 MN's peer cases, SHOULD be considered in IKE. 696 L1: When the phase one and phases two are allowed to use different 697 (peer) addresses to transport messages, identity payloads SHOULD 698 be used in phases two. 700 L2: When the phase one and phases two are allowed to use different 701 addresses, the endpoint addresses used in a phase 2 context 702 MUST be the (peer) addresses used to transport IKE messages of 703 this phase 2. 705 M: Identity payloads used in phase two SHOULD denote clearly 706 address sets. 708 N: The policy MAY authorize the establishment of a Transport mode 709 SA pair using an address identity payload which does not match 710 the (peer) address used to transport IKE messages. This 711 authorization SHOULD be based on parameters provided in the 712 phase one authentication, for instance the phase one peer 713 identity and certificate. 715 O: With a standard CN, the MN SHOULD ignore the fact that it is a 716 mobile node and SHOULD use its H@ for all IKE exchanges and for 717 its own address in the SA pairs. To avoid both IPsec and Mobile 718 IPv6 overheads, it SHOULD negotiate the Transport mode. 720 P: If BU/BA exchanges between the MN and the HA are protected by 721 an IPsec SA pair, the establishment of this SA pair MUST be 722 allowed using a Co@ for the transport of all IKE messages (i.e., 723 the MN peer address is a Co@). 725 Q: IKE implementations MUST support lifetimes for the phase one 726 which are far longer or far shorter than the lifetime of SA 727 pairs established by phases two. 729 R: IKE implementations SHOULD be able to lookup still valid phase 730 one state from a phase two message using different (peer) 731 addresses for transport. For instance using the ISAKMP SA SPI 732 a.k.a. cookies [5]. 734 Appendix B: Proposals for IKEv2 736 Many recommendations are directly applicable to IKEv2 [13]: 737 - recommendations G, O, P apply without modifications. 738 - recommendations L1, L2 and N applies to traffic selectors 739 in place of phase two identities. 740 - recommendation M is integrated in IKEv2. 741 - recommendation R is partially integrated in section 2.6 742 of [13], but we propose to make very clear the IKE-SA lookup 743 MUST be done using the cookies as a SPI *only*. Note that 744 IKEv2 guarantees the uniqueness of these "SPIs". 746 [14] introduces the term "peer addresses" for the addresses used 747 for the transport of IKE messages and includes the recommendations 748 G, H and I. [15] is not directly applicable to IKEv2 but [15] (not 749 yet included in the IKEv2 draft) proposes a new form of identities 750 without any kind of binding to addresses. 752 In IKEv2 the phase one SA is named the IKE SA and when it is 753 deleted all the IPsec SAs it negotiated have to be deleted too 754 (so the recommendation Q does not stand). The idea is to solve 755 the dead peer detection issue by keepalives over the IKE SA. 757 *PROPOSAL 1: IKEv2 implementations MUST lookup IKE-SA using 758 *only the SPI at the exclusion of peer addresses. 760 Identities should not include addresses as recommended in [16] 761 so recommendations H to K are obsolete in the IKEv2 context. 762 (this is a call to adopt [15] ASAP) 764 *PROPOSAL 2: IKEv2 identity payloads MUST only use abstract 765 *identities as recommended in [16] by the IAB and proposed by [15]. 767 But this and the section 4.11 "Address and Port Agility" of [13] 768 remove any check of peer addresses which are still part of 769 established SAs, opening the door to attacks as described in 770 [17]. But mobility really needs address agility so: 772 *PROPOSAL 3: The section 4.11 should specify full address agility. 774 The first counter-measure against abuse of this address agility 775 is to protect the integrity of transport headers. The new 776 notifications NAT-DETECTION-SOURCE-IP and NAT-DETECTION- 777 DESTINATION-IP are the beginning of a solution. 779 *PROPOSAL 4: IKEv2 MUST provide a way to protect the integrity 780 *of transport parameters (peer addresses, ports and protocol). 782 *PROPOSAL 5: The default policy SHOULD be the protection of 783 *the integrity of transport parameters for IPv6. 785 These proposals defeat en-route modifications of messages, 786 i.e., fulfill some mobility requirements, but not all of 787 them because these proposals give no proof about the real 788 origin of messages, i.e., one should trust its peer. 789 The solution is of course a simple return routability check, 790 and IKEv2 already uses this kind of mechanisms in the 791 "Responder under attack" case (IKE_SA_init_reject). 793 *PROPOSAL 6: A mechanism MUST be provided in order to make return 794 *routability checks available on peer address changes. 796 *PROPOSAL 7: The default policy SHOULD be to perform 797 *return routability checks on peer address changes. 799 Now that mobility can be securely handled (this is not the 800 case for NAT traversal but we believe this issue can not be 801 solved, c.f. [17]), we can look for some dedicated improvements. 802 The fist special case to be dealt with is the MN - HA SA pair 803 to protect the BU/BA exchange a.k.a. the "home registration". 805 *PROPOSAL 8: When the policy authorizes it, a traffic selector 806 *in Transport mode MAY override peer addresses as SA selectors. 808 (this is a reformulation of recommendations N and P.) 810 The other item is to instantiate the recommendation F: 812 *PROPOSAL 9: A new mechanism MUST be defined for the update 813 *of the peer address in the SA pair (the source outer address of 814 *the inbound SA and the destination outer address of the outbound 815 *SA) without mandatory rekeying. 817 Appendix C: Return Routability 819 The proposed return routability check assumes these properties: 820 - a secret is shared with the peer, i.e., there is a proof 821 that the received packets are from the peer. 822 - an anti-replay mechanism proves the received packets are fresh. 823 If the exchange involved some hard state change (for instance the 824 proposal 9), a sequencing mechanism should be provided too. 826 The return routability check does not give a proof that the peer is 827 at the given address, it only proves the peer is on the path. 828 For more details about return routability check theory, please 829 refer to [8]. 831 Appendix D: Scoped Addresses 833 This topics is not really a Mobile IPv6 one, but in practice the 834 "mobile VPN" case there is a heavy usage of limited scope or 835 private addresses. 837 The issue is that addresses carried in identity or traffic 838 selector payloads are not clothed with zone identifiers. 839 Only the peer addresses used to transport messages have an 840 indirect indication of their zones. 842 The IPv6 scoped address architecture [18] gives the properties 843 of zones: at a given scope, zones formed a partition, i.e., 844 an interface belongs to one and only one zone. They have an 845 inclusion property too, i.e., a zone of a given scope is 846 fully included into a zone of any higher scope. This gives 847 an inheritance property which is safe when it is used in 848 the proper way: to establish SAs with global addresses with 849 IKE running over link-local addresses is safe, the opposite 850 is not. 852 *RULE: The default policy SHOULD accept scoped addresses as 853 *selectors of SAs only when they are established using peer 854 *addresses (for the transport of IKE/IKEv2/etc messages) which 855 *are in fully included zones.