idnits 2.17.1 draft-dupont-ipsec-mipv6-00.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. == 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], [8], [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 137: '...*authentication) MUST be accepted (i.e...' RFC 2119 keyword, line 138: '... *verifiable) and the HAO MUST be considered as verified [11]...' RFC 2119 keyword, line 157: '... in tunnel mode and Mobile IPv6 SHOULD...' RFC 2119 keyword, line 172: '... SA lookup and the source address MUST...' RFC 2119 keyword, line 198: '...essing against the SA selector MUST be...' (20 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 2002) is 8105 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 46 ** 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-15 == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-05 Summary: 12 errors (**), 0 flaws (~~), 3 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 August 2002 February 2002 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] does not work well with Mobile IPv6 [7] 36 and with any mobility device based on addresses [8] even if HIP [9] 37 should change this regrettable situation. 39 But many problems come directly from bad or dubious interpretations 40 of IPsec specifications, so this document presents many points 41 where many current implementations can be improved (i.e. become 42 more Mobile IPv6 friendly). 44 1. Introduction 46 This document assumes the reader knows IPsec (i.e. [1-6]) but not 47 Mobile IPv6, so this section explains how Mobile IPv6 works. 49 In Mobile IPv6, each Mobile Node (MN) is always identified by 50 its Home Address (H@), regardless of its current point of 51 attachment to the Internet. While situated away from its home, 52 a MN is also associated with a Care-of Address (Co@), which 53 provides information about the mobile node's current location. 54 IPv6 packets from a Correspondent Node (CN) addressed to a MN's H@ 55 are transparently routed to its Co@. 57 A MN has a special CN, the Home Agent (HA), which is used to 58 intercept packets addressed to the MN's H@ on the home link and to 59 forward them to the MN at its current Co@ through a tunnel. 61 End-to-end communications between a MN and a CN can use one of 62 these 3 modes: 63 - bidirectional tunneling with the HA: 64 MN => HA -> CN (=> denotes an encapsulation) 65 CN -> HA => MN 66 The CN knows only the MN's H@ and in fact even does not know 67 the MN is mobile. This mode is very safe but not optimized 68 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 Home Address Option for packets to the CN, 79 the CN uses a Routing Header (RH) and puts the MN's Co@ in the 80 destination address field of the IPv6 header, and puts the 81 MN's H@ in the RH. This mode raises many security concerns, 82 mainly about the mobility signaling, but is very efficient. 83 This use of HAO and RH are in fact degenerated tunnels as shown 84 by the Deering/Zill tunneling document [10], i.e. they can be 85 considered as IPv6 in IPv6 tunnels where two addresses in 86 the outer and inner IPv6 headers are redundant so deleted. 88 The term node in MN is a bit misleading: mobile routers are not 89 considered by current Mobile IPv6 specifications and communications 90 in this document are always end-to-end. 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 2. IPsec Architecture and Mobile IPv6 98 IPsec defines two modes, transport and tunnel modes. 99 As mobile IPv6 itself is based on real or degenerated tunneling, 100 there are three possible basic interactions: transport mode 101 after Mobile IPv6 tunneling, transport mode before Mobile IPv6 102 tunneling, combination between tunnel mode and Mobile IPv6 103 tunneling. 105 2.1 Transport Mode After Mobile IPv6 107 This case is defined only when Mobile IPv6 uses real tunneling, 108 i.e. in current specifications between the MN and its HA. 109 As the IPv6 header (and addresses!) viewed by IPsec is the outer 110 one, in general this case has no interest (the MN's outer address 111 is a transient Co@, the interesting one, the H@, is in the inner 112 header). 114 2.2 Transport Mode Before Mobile IPv6 116 In this case the IPsec transform is applied to the payload of 117 an ordinary packet between the MN and the CN, using for the MN 118 its static/long term H@, and *after* Mobile IPv6 may add its 119 extension header corresponding to its mode: 120 - bidirectional tunneling is perfectly transparent: IPsec and 121 Mobile IPv6 don't interfere. The same consideration 122 applies to the HA=>MN tunnel. 123 - triangular routing is more interesting and gives different 124 results for the Authentication Header (AH [2]) and the 125 Encapsulating Security Payload (ESP [3]): 126 * AH authenticates both Co@ (in the IPv6 header) and the H@ 127 (in the HAO) 128 * ESP with authentication will reject fake packets because 129 the attacker can't know the authentication key. 130 So with authentication the only possible attack is a denial 131 of services from an attacker who knows the SPI and is likely 132 be able to inject fake traffic without HAO. So this is an 133 intrinsic IPsec thread. 135 *RECOMMENDATION A: packets with a HAO matching an IPsec SA 136 *providing authentication (i.e. AH or ESP with non-null 137 *authentication) MUST be accepted (i.e. the HAO considered as 138 *verifiable) and the HAO MUST be considered as verified [11] 139 *after successful IPsec processing. 140 - optimized routing is like triangular routing for the MN~>CN 141 way with, in addition to recommendation A, the common way 142 to verify HAO: binding cache entry check. Symmetrically 143 IPsec adds nothing for the RH verification because the MN 144 has already all the interesting informations. 145 - optimized routing between two MNs is an interesting case 146 not yet fully addressed by Mobile IPv6 specifications [7]: 147 RH and HAO have more overhead than a plain tunnel so a 148 combined tunnel mode with Mobile IPv6 becomes very 149 interesting in this special case... 151 2.3 Tunnel Mode not combined with Mobile IPv6 153 Not combined means there are two overhead, one for IPsec tunneling, 154 another for Mobile IPv6 extra headers, when obviously one 155 encapsulation provides enough addresses (two sources and two 156 destinations) for Mobile IPv6! 157 *RECOMMENDATION B: IPsec in tunnel mode and Mobile IPv6 SHOULD 158 *be combined in order to avoid to add their overheads. 160 2.4 Addresses of SAs 162 SAs can be characterized by: 163 - one address (destination in IPsec inbound processing [1]) 164 - two addresses (source and destination selectors [1]) 165 - three addresses (source, destination and proxy in PF_KEY [12]) 166 - four addresses (in tunnel mode) 167 This is a bit confusing and gives security holes and/or extra 168 checks on addresses which are highly Mobile IPv6 unfriend. 170 Transport mode is easy because there are always exactly two 171 addresses. For instance in inbound processing the destination 172 address is used for the SA lookup and the source address MUST 173 be checked ([1], section 5.2.1). So this document will assume 174 the tunnel mode is used. 176 In general, the SADB is not designed to be managed directly 177 and/or itself, i.e. without the SPD. Addresses are handled 178 by the SPD with a pair of selectors which characterized the 179 source and the destination of the traffic which receives IPsec 180 protection. SPD entries specify the type of IPsec processing 181 (for instance one type is the bypassing of IPsec: this is needed 182 by IKE for its own messages [1]) and the parameters of SAs 183 to use or to build (using SADB_ACQUIRE PF_KEY messages [12]). 185 IKE (and its successor(s)) is designed to build SAs per pairs 186 so IPsec implementations using PF_KEY follow (or should follow) 187 for tunnel mode SAs this interpretation: 188 - the source and the destination addresses are plain addresses 189 in the general case and designed the end nodes of the tunnel 190 (i.e. there are the outer header addresses). 191 - the inner source address is the proxy address (and exists 192 only in tunnel mode). This can be something else than a plain 193 address (i.e. for instance a prefix) but not in the Mobile IPv6 194 case. The check can be performed after each IPsec inbound 195 processing [1] or at the SPD check (not the specified way 196 by the final result is the same). 197 *RECOMMENDATION C1: the source address checked after each 198 *IPsec inbound processing against the SA selector MUST be 199 *the inner header source address. 200 - the selection of the traffic to be processed is handled 201 by SPD entries. This includes the future inner addresses 202 in outbound processing: guidelines are to use the inbound 203 processing rules for SADB design, the outbound processing 204 rules for SPD design and to complete by symmetry (with the 205 funny (?) side-effect that source and destination roles can 206 be reversed). 208 RFC 2401 [1] has detailed rules about the outer source address 209 but they are commonly misunderstood: to check it gives no 210 extra security because when (where!) a attacker can get the SPI 211 he can inject fake traffic too. But this check harm near all 212 mobility mechanisms based on addresses, even nomadism aka 213 the "road warrior" case. 214 *RECOMMENDATION C2: the outer source address in tunnel mode 215 *MUST NOT be checked after or before IPsec inbound processing. 216 This recommendation doesn't apply to the SPD checking, i.e. 217 step 4 of RFC 2401 [1] section 5.2.1. 218 This recommendation by itself doesn't solve the problem of the 219 other SA of the pair: the MN can change its Co@ and continue 220 to use the SA to the CN but the other way/SA will work only 221 when the other SA will change or rebuild with the new Co@ 222 as the destination. 224 BTW RFC 2401 [1] specifies IPv6 in IPv4 and IPv4 in IPv6 tunnels 225 and these tunnels are taken into account in PF_KEY [12] so: 226 *RECOMMENDATION D: dual stack (i.e. IPv4 and IPv6) IPsec 227 *implementations MUST support IPvX in IPvY tunnel modes with 228 *any X and Y, including cases where X != Y. 230 2.5 Combined Tunnel Mode with Mobile IPv6 (Standard Case) 232 When IPsec in tunnel mode is combined with Mobile IPv6 there 233 is one encapsulation with fixed/H@ in the inner header and 234 transient/Co@ in the outer header, the opposite of the 235 common tunnel mode usage between two security gateways. 236 The CN can be itself a MN: only one detail not directly 237 related to IPsec changes: mobility has to support the 238 simultaneous movement of both peers (handled by fallback 239 through a HA for instance in Mobile IPv6, cf. [7]). 241 Between two movements the IPsec tunnels are not very special, 242 they look like end-to-end IPsec tunnels between two peers. 243 The only unusual detail is the outer and inner addresses can be 244 different (they are if a MN is not at home) but this is 245 an issue for IKE. 247 The interesting case is what happens when a Co@ changes: 248 the MN should send a BU to the CN which, according to 249 recommendation C, must not be filtered out because the 250 Co@ is not the same. 251 *RECOMMENDATION E1: BU protected by an IPsec SA providing 252 *authentication MUST be considered as authenticated. 253 *RECOMMENDATION E2: in the E1 case, all BU parameters MUST 254 *be covered by the authentication, specially when the 255 *authentication is provided by an ESP transform, the new Co@ 256 *MUST be covered, for instance using an alternate Co@ suboption. 258 As explained before, to deal with the BU is not enough for 259 the CN~>MN way. For instance, the Binding Acknowledgment (BA) 260 can be protected only when the reversed SA is updated or rebuilt. 261 *RECOMMENDATION F: mobility signaling and IPsec SA management 262 *direct cooperation SHOULD be considered (i.e. development of 263 *this kind of mechanisms encouraged). 265 2.6 Combined Tunnel Mode with Mobile IPv6 (Home Agent Case) 267 This section doesn't consider traffic from the HA itself 268 which is handled by routing optimization as for a standard CN, 269 but is about the MN<=>HA tunnels. This document assumes that 270 the tunnel is bidirectional even the Mobile IPv6 is not (yet) 271 very clear about this. 273 The addresses used for these tunnels are very simple: 274 - on the MN side, inner header address is the H@, outer a Co@. 275 - on the HA side, inner header address is any valid address 276 (unicast address when used as a source address) and the 277 outer address is the HA address [7]. 278 IPsec considerations are near the same than for standard CNs, 279 in fact things are simpler because one can assume the HA is 280 never mobile. Recommendation F applies but is not useful when 281 no IPsec SA exists, i.e. when a MN boots in visit: this will 282 be the special case in IKE considerations (next section). 284 3. IKE and Mobile IPv6 286 There are three basic issues: 287 - how to handle the multiple addresses of a MN? In the phase 288 one? In a phase two? 289 - how to establish SAs between a MN and a standard CN? 290 - how to establish SAs between a MN from a foreign link 291 and its HA the first time? 292 This document uses the name IKE [6] for the IPsec DOI [4] 293 and ISAKMP [5] framework too. 295 3.1 IKE and Identities (Phase One) 297 In the phase one identities (IDii and IDir) design the peers so 298 subnet and range identities can not be used. This document 299 assumes phase one with digital signatures using a X.509 style 300 of certificates but most of the considerations applies to 301 public key authentications too. 303 In phase one a peer is identified by its address used for the 304 transport of IKE messages and its identity payload. Identities 305 in the general meaning can be present in certificates too but 306 all cases are not equivalent: 307 - the Identity must be related to the certificate: 308 *RECOMMENDATION G: the Identity payload presented by the peer 309 *MUST be verified, for instance certificates are used, the 310 *Identity and the subject or an alternative subject of the 311 *certificate associated to the signature MUST match. 312 - if the Identity is an address, it must be the right address. 313 *RECOMMENDATION H: if the Identity payload presented by the 314 *peer is an address, it MUST be the same address than the one 315 *used for transport of IKE messages. 316 - same for addresses used as (alternative) subjects: 317 *RECOMMENDATION I: if an address is used as the subject or 318 *an alternative subject of the certificate associated to the 319 *signature, the address used for transport of IKE messages 320 *SHOULD match the subject or an alternative subject. 321 "SHOULD match" means the default policy is to perform the check. 322 - last about Identity/address checks: 323 *RECOMMENDATION J: the case where the certificate associated 324 *to the signature has no address subject or alternative subject 325 *SHOULD be considered as a special case by policies, for instance 326 *the policy MAY specify particular constraints for this case. 327 - of course, this can be a bit annoying for MNs which must use 328 in some cases their Co@ for transport of IKE messages so: 329 *RECOMMENDATION K: the addition of a Home Address Identity 330 *which should allow strict application of previous I and J 331 *recommendations in all cases for a MN's peer SHOULD be 332 *considered in IKE and its successor(s). 334 3.2 IKE and Identities (Phase Two) 336 In the phase two (aka quick mode) identities (IDci and IDcr) are 337 optional and design the policy rule (in the SPD or in the IKE 338 software configuration) to apply: 339 - in tunnel mode the peer addresses will be the outer header 340 addresses, and identities can denote the traffic selector part 341 of the policy rule. 343 - without identities the SA pairs will be applied to all traffic 344 not matched by a more specific policy between the peers using 345 the same addresses than in IKE messages. This is ambiguous so: 346 *RECOMMENDATION L1: when the phase one and phases two are 347 *allowed to use different addresses, identity payloads MUST be 348 *used in phases two. 349 - in tunnel mode there is an ambiguity about the peer addresses: 350 *RECOMMENDATION L2: when the phase one and phases two are 351 *allowed to use different addresses, the peer addresses used 352 *in a phase 2 context MUST be the addresses used for the 353 *transport of IKE messages of this phase 2. 354 - junk identities are not useful: 355 *RECOMMENDATION M: identity payloads used in phase two SHOULD 356 *denote clearly address sets. 357 - IKE [6] explicitly provides a "proxy case" usable for mobility: 358 *RECOMMENDATION N: the policy MAY authorize the establishment of 359 *a transport mode SA pair using an address identity payload 360 *which doesn't match the address used for transport of IKE 361 *messages. This authorization SHOULD be based on parameters 362 *provided in the phase one authentication, for instance the 363 *phase one peer identity and certificate. 365 3.3 IKE and Mobile IPv6 (Standard Case) 367 If the MN has the choice between using its H@ or a Co@ for IKE 368 exchanges, only the first choice makes sense with a standard CN: 369 - to use the Co@ is more complex and can require a new phase one 370 with each peer after a movement. 371 - when the CN is the initiator it always use the H@. 372 Note the IKE software should not even know the node is mobile... 373 For the same reason, the SA pairs should use the H@ as the MN 374 address, giving an IPsec transform before Mobility case: 375 *RECOMMENDATION O: with a standard CN, the MN SHOULD ignore 376 *it is a mobile node and SHOULD use its H@ for all IKE exchanges 377 *and for its own address in the SA pairs. To avoid both IPsec 378 *and Mobile IPv6 overheads, it SHOULD negotiate the transport mode. 379 Transport mode was designed for end-to-end communications, IMHO 380 this recommendation should be written with MUSTs! 382 3.4 IKE and Mobile IPv6 (Home Agent Case) 384 Recommendation O doesn't work with the HA because when the MN 385 boots in visit it can use its H@ only after processing of the 386 first BU by the HA. This BU MUST be protected so it can not 387 be protected by IPsec (trivial bootstrap problem). 389 In fact there are two possible MN-HA SA pairs: 390 - a SA pair for BU/BA exchange protection. 391 - a SA pair for the MN<=>HA tunnels. 393 The first SA pair is a bit hairy to establish because the MN 394 can only use its Co@ in some circumstances: 395 *RECOMMENDATION P: if BU/BA exchanges between the MN and the HA 396 *are protected by an IPsec SA pairs, establishment of this SA 397 *pair MUST be allowed using a Co@ for all IKE messages. 398 The detailed requirements are: 399 - an API should give a suitable Co@ for communications with 400 the HA (i.e. something like getsockname() which returns 401 the Co@ for a connected socket in place of the Ho@). 402 - phase one and phase two messages are sent using this Co@. 403 - phase one identity is not an address if no transient 404 certificate for the Co@ is available. 405 - the authentication with this identity must be allowed 406 (including when recommendation J is enforced). 407 - until the home address identity is defined and implemented, 408 the phase two identity must be an address identity with the H@, 409 and this must be allowed (according to recommendation O). 410 - the result is a SA pair between the MN with its H@ and 411 the HA with its HA Address, the favorite is AH transport mode 412 (enough security and best efficiency). 413 This SA pair establishment stresses the issue of relative lifetimes 414 of the phase one and the SA pair so: 415 *RECOMMENDATION Q: IKE implementations MUST support lifetimes 416 *for the phase one which are far longer or far shorter than 417 *the lifetime of SA pairs established by phases two. 418 and with very long phase one lifetimes: 419 *RECOMMENDATION R: IKE implementations SHOULD be able to lookup 420 *still valid phase one state from a phase two message using 421 *different addresses for transport, for instance using the 422 *ISAKMP SA SPI aka cookies [5]. 424 The SA pair for tunnels is more easy: the only problem is with 425 policies: 426 - a solution is dynamically create the proper policy from 427 mobility information (i.e. BUs) and to establish the SA 428 pair described in section 2.6 (combined tunnel mode with HA). 429 One can make things a bit faster reusing the phase one 430 (cf recommendations R and L2). 431 - another solution is to create a SA pair using only the MN's H@ 432 (this can be done as soon as the first BU is processed because 433 the HA can use the standard routing optimization mode for its 434 own traffic, in fact this is the default behavior) and to 435 use a to-be-defined direct cooperation between IPsec and 436 mobility to update the outer MN address in the SA pair 437 (a good use of the HIP readdress [9]). 439 4. Security Considerations 441 At the exception of recommendations F and K, all recommendations 442 made in this document are about interpretation of IPsec 443 specification details. In fact, we are convinced these 444 recommendations shall improve the security of both IPsec and 445 Mobile IPv6. 447 5. Acknowledgments 449 Some of the MN-HA ideas were developed in the authentication vs. 450 authorization brainstorming, for instance the home address identity 451 (unfortunately I don't remember who proposed this). 453 Of course the current terrible interaction between IPsec and 454 Mobile IPv6 was and still is discussed in the mobile-ip WG list 455 and from time to time in the ipsec WG list too. So many thanks 456 to the little number of persons who participate to both lists. 458 I finish with authors of "open source" IKE implementations, 459 particularly Shoichi Sakane who has written the IPsec 460 implementation (including an IKE daemon, racoon) I use. 462 6. Normative References 464 [1] S. Kent, R. Atkinson, "Security Architecture for the Internet 465 Protocol", RFC 2401, November 1998. 467 [2] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, 468 November 1998. 470 [3] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 471 (ESP)", RFC 2406, November 1998. 473 [4] D. Piper, "The Internet IP Security Domain of Interpretation 474 for ISAKMP", RFC 2407, November 1998. 476 [5] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet 477 Security Association and Key Management Protocol (ISAKMP)", 478 RFC 2408, November 1998. 480 [6] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 481 RFC 2409, November 1998. 483 7. Informative References 485 [7] D. Johnson, C. Perkins, "Mobility Support in IPv6", 486 draft-ietf-mobileip-ipv6-15.txt, July 2001. 488 [8] F. Dupont, "Mobility-aware IPsec ESP tunnels", 489 draft-dupont-movesptun-00.txt, February 2001. 491 [9] R. Moskowitz, "Host Identity Payload And Protocol", 492 draft-moskowitz-hip-05.txt, November 2001. 494 [10] S. Deering, B. Zill, "Redundant Address Deletion when 495 Encapsulating IPv6 in IPv6", 496 draft-deering-ipv6-encap-addr-deletion-00.txt, November 2001. 498 [11] C. Perkins, "[mobile-ip] A new proposal for handling Home 499 Address destination options", http://playground.sun.com/mobile-ip/, 500 Message-ID: <3C6C7780.4CFAA7B4@iprg.nokia.com>, February 2002. 502 [12] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, 503 Version 2", RFC 2367, July 1998. 505 8. Author's Address 507 Francis Dupont 508 ENST Bretagne 509 Campus de Rennes 510 2, rue de la Chataigneraie 511 BP 78 512 35512 Cesson-Sevigne Cedex 513 FRANCE 514 Fax: +33 2 99 12 70 30 515 EMail: Francis.Dupont@enst-bretagne.fr