[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                          F. Dupont
Internet-Draft                                                    Point6
Expires: May 22, 2006                                  November 18, 2005


                  Address Management for IKE version 2
                   draft-dupont-ikev2-addrmgmt-08.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 22, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The current IKEv2 proposal lacks an address management feature.  As
   it is compatible with the NAT traversal capability, this document
   specifies a complete address management with support for multi-homing
   and mobility, and fulfill mobike IETF working group goals 1, 2, 3, 4,
   and 6.







Dupont                    Expires May 22, 2006                  [Page 1]

Internet-Draft        Address Management for IKEv2         November 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Simplicity, Performance and Security . . . . . . . . . . .  3
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Multi-homing requirements  . . . . . . . . . . . . . . . .  4
     2.4.  Mobility requirements  . . . . . . . . . . . . . . . . . .  4
   3.  Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Kept points from/clarification to the IKEv2 draft 17 . . .  6
     3.2.  Minor points . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Peer address notifications . . . . . . . . . . . . . . . .  7
     3.4.  Explicit peer address update payload . . . . . . . . . . .  7
     3.5.  Open issues  . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Peer Address Notification Format  . . . . . . . . . . 11
   Appendix B.  Peer Address Update Payload Format  . . . . . . . . . 12
   Appendix C.  NAT Prevention Notification Format  . . . . . . . . . 14
   Appendix D.  Return Routability Cookie Notification Format . . . . 15
   Appendix E.  PF_KEY version 2 SADB_X_ADDUPD  . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

























Dupont                    Expires May 22, 2006                  [Page 2]

Internet-Draft        Address Management for IKEv2         November 2005


1.  Introduction

   This document proposes an address management for IKEv2 [1] for all
   the IETF mobike working group goals [4] at the exception of the goal
   5 (handled by [5]).

   In this document, the addresses used to transport IKE messages are
   named the "peer addresses" (term introduced by [6]).  These peer
   addresses should no more be directly or indirectly included in
   identities ([7] and [8]) as it is commonly done for IKEv1.

   The current IKEv2 draft [1] often makes the implicit assumption that
   an address identifies a node when nodes behind a NAT can share the
   same address and a node can use many different addresses.  This must
   be taken into account in implementations, for instance by reading
   this document before writing code...

   This document describes the goals of an address management for IKEv2,
   including the requirements for multi-homing and mobility support
   (this part will be removed as soon as the mobike requirements
   document [9] is finalized), and finishes by a concrete proposal.

   In this document, open questions are introduced by the word NOTE and
   will be refined in a dedicated section.


2.  Goals

   The goals of the address management proposed in the document can be
   divided in some general goals and in requirements for the three
   mechanisms which can change the peer addresses.

2.1.  Simplicity, Performance and Security

   The address management should be as simple as possible, i.e., it
   should introduce minimal additions to the current IKEv2 draft [1] and
   each addition should be justified.

   The performance is an important criterion.  For instance, rekeying
   can update the peer addresses of an IKE SA or an IPsec SA pair, but
   rekeying is too expensive and a specific solution is needed.

   As a security protocol, IKEv2 should get a high security level.
   Unfortunately we already showed that the NAT traversal feature comes
   with a security issue (the transient pseudo-NAT attack [10]).

   Such problems introduced by the peer address flexibility must be
   described in this document and at least be mitigated by options in



Dupont                    Expires May 22, 2006                  [Page 3]

Internet-Draft        Address Management for IKEv2         November 2005


   configurations.  For instance, the NAT traversal feature should never
   be enabled when one knows that there can not be a NAT as today in
   IPv6.

   An other example of an insecure mechanism is to use the addresses in
   IP headers of CREATE_CHILD_SA messages as the endpoint addresses of
   the new IPsec SAs without further control on them: peer addresses
   must be managed.

2.2.  Terminology

   The addresses of the two peers are named "peer addresses".  With
   other words the peer addresses are the addresses IKE runs over but
   this document extends this basic definition.  The primary peer
   address of a peer is initialized to the address used to transport
   messages of the initial exchanges, other addresses are "alternate
   peer addresses".

   The proxy case is the setup of transport mode IPsec SAs on the behalf
   of another party, i.e., transport mode IPsec SAs where the traffic
   selectors do not match the primary peer addresses.

2.3.  Multi-homing requirements

   In this document, the support of multi-homing is the support of nodes
   with several global addresses.  Some of the addresses can be "better"
   than others, or "better" for some destinations.  Some can, from time
   to time, be unavailable.

   The main requirement for the support of multi-homing is the
   management of a set of peer addresses for each peer.  The set can be
   partially ordered or some subsets can be loosely associated with some
   destinations (i.e., some subsets of the other peer address set, this
   is needed when a destination address can be reached only using
   particular source addresses).

   For the communication between multi-addressed hosts, the support of
   the proxy case can be useful because it provides an easy way to setup
   transport mode IPsec SAs with different addresses from one IKE SA.
   In such cases the other party is in fact the same host, this
   dramatically simplifies the authorization issue.

2.4.  Mobility requirements

   In the context of Mobile IPv6 ([11] and for the special case of Home
   Agents [12]), the interaction of Mobility and IPsec was analyzed in
   another document [13].  This document assumes an IPv6 context as
   Mobile IPv6 is the most powerful mobility proposal available today.



Dupont                    Expires May 22, 2006                  [Page 4]

Internet-Draft        Address Management for IKEv2         November 2005


   An IPv6 mobile node is another type of multi-addressed node with:
   -  a care-of address in a prefix of the visited link.
      The care-of address is used to route packets.
   -  the home address in a prefix of the home link.
      The home address is used to identify the mobile node.

   The care-of address is transient and usually the mobile node can not
   provide a proof that it is the node using it.  So it has to be
   trusted and a return routability check (i.e., an enforced answer from
   this address) should be used if it is not.

   With a common correspondent, the mobility is transparent and there is
   no reason to use another address than the home address.  For
   optimized schemes, without an implementation of header compression in
   ESP tunnel mode (the goal 5 of mobike [4]) the choice between a
   transport mode using triangular routing (IPsec can be used to verify
   home address options) and a tunnel mode with routing optimization is
   not clear.  But this case does not add new requirement, i.e., the
   home agent case includes them.

   With the home agent, there are three main cases (c.f. [12]):

   -  The mobility signaling which is mandatory protected and raises a
      specific issue in its initial phase: the IKE SA must be setup
      using the care-of address as the peer address but this IKE SA is
      used to build an IPsec SA pair with the home address as traffic
      selector.  This IPsec SA will protect the home registration which
      will make the home address available.  This can be considered as a
      specialized proxy case.

   -  Other genuine communications between the home agent and the mobile
      node can be covered by the proxy case support too.  Note this is
      the only case at the exception of signaling where mobility behaves
      in a different way than a mobile IPsec VPN (so we proposed to
      relax the corresponding rule in a future version of [11] and
      [12]).

   -  The traffic relayed by the home agent through a tunnel with the
      mobile node can be partially or fully protected by IPsec SA
      pair(s).  Encapsulation should be performed only once, including
      for degenerated (but not for free) encapsulation like the home
      address option or the mobility routing header.

   In all cases of interaction with the home agent, the mobile node peer
   address should be a care-of address.  When the mobile node moves,
   another care-of address is used and some SAs, including the IKE SA,
   must be updated to use the new address.




Dupont                    Expires May 22, 2006                  [Page 5]

Internet-Draft        Address Management for IKEv2         November 2005


   Usually the previous peer address is no more usable.  In order to
   avoid a trivial denial of services, a strong sequencing of updates is
   required with a way to cancel possible pending updates when fast
   multiple handoff happen.

   The IPsec pair which protects the mobility signaling uses the home
   address as its traffic selector for the mobile node.  It must not be
   updated at each handoff.  The update mechanism must provide a fine
   grain (i.e., per SA) update.


3.  Proposal

   The proposal for an address management in IKEv2 is spawn from the NAT
   traversal mechanisms, mainly with a new peer address update payload.
   But there are some points that have to be kept or clarify as they
   already are in the current IKEv2 draft [1].

3.1.  Kept points from/clarification to the IKEv2 draft 17

   The peer addresses MUST be stable during the initial exchanges, i.e.,
   the IKE_SA_INIT and IKE_AUTH exchanges MUST be transported using the
   same peer address pair.

   The peer addresses are used to transport messages.  The reply to a
   request MUST be sent to the source of the request from the
   destination request, i.e., addresses and ports are reversed between
   the request and its reply.  There is no exception to this rule.

   For tunnel mode IPsec SAs, the endpoint addresses are the primary
   peer addresses.  We don't propose an alternate way to specify them.
   The same requirement applies to transport mode IPsec SAs at the
   exception of the proxy case.

3.2.  Minor points

   In retransmission of requests or responses, copies of messages do not
   include peer addresses.  So a peer MAY retransmit an IKE message from
   or to a different address.

   The primary peer addresses are IKE SA parameters and are specified by
   the IKE_SA_INIT exchange.  Note that when NAT traversal is not
   active, they are implicitly protected by the NAT_DETECTION or
   NAT_PREVENTION notifications.

   All the text below applies only to the case where NAT traversal is
   not active.  Everything relative to transport mode, including the
   proxy case, is dealt with in [2].



Dupont                    Expires May 22, 2006                  [Page 6]

Internet-Draft        Address Management for IKEv2         November 2005


   Return routability checks are done using an informational exchange
   carrying a RR_COOKIE notification in order to get a proof the probed
   peer really receives the request.  Of course the reply MUST contain
   the same RR_COOKIE notification than the request.

3.3.  Peer address notifications

   The peer address notifications are copied from the current
   NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
   notifications.  They includes the peer source or destination address
   with its family and an operation code.  They MUST be in an encrypted
   payload.  Operations are MARK, ADD and DELETE (last two for alternate
   addresses, see open issue section for the empty set one and the
   delete operation on the primary peer address).

   All messages after the first exchange involving an alternate peer
   address MUST include at least one peer address notification for each
   peer, i.e., at least one for the source and at least one for the
   destination.

   Such messages belong to IKE_AUTH or CREATE_CHILD_SA exchanges, or
   carry the peer address update payload defined below, or are pure peer
   address set management (add/delete).

   They provide a cryptographically proof of no en-route alteration of
   the peer addresses and enable operations on the sets of peer
   addresses, i.e., change of the primary peer address of a peer,
   addition to and deletion from the peer address set of a peer.

   When the peer address notifications are not supported, the capability
   to use an alternate peer address, and only this, is lost.

   As these notifications do not transport zone indications, they MUST
   NOT be used for ambiguous not-global addresses.  But it is still
   possible to use a not-global address in the IKE_SA_INIT exchange.

   NOTE: this seems the only reasonnable common possibility and of
   course in this case the not-global address is not ambiguous.

3.4.  Explicit peer address update payload

   A new payload has to be defined for an explicit peer address update
   mechanism.  We propose to copy it from the delete payload, see
   Appendix B.

   The new peer address update payload has strong sequencing
   requirements.  IKEv2 messages have a protected sequence number so the
   only sequencing issues are the window of processing and pending



Dupont                    Expires May 22, 2006                  [Page 7]

Internet-Draft        Address Management for IKEv2         November 2005


   exchanges.  Any messages with a peer address update payload MUST be
   processed in order.

   When the receiver of an additin or update request has to check the
   validity of a new peer address, it MAY use a return routability check
   sending an informational request carrying a RR_COOKIE notification at
   the new address and waiting for an answer.  As informational
   exchanges are protected no more is needed.

   Example of a return routability check:

      I ----- address update request -----> R
      I <-- informational RR [Ni] request - R
      I --- informational RR [Ni] reply --> R
      now the responder knows the initiator should be where it claimed
      to be.
      I <------ address update reply ------ R

   When a peer address update deletes the current primary address,
   pending (i.e., to be retransmitted) requests MUST be sent to the new
   address(es) even it is (they are) not yet checked.

   NOTE: look at the open issue about the detection of the movement
   behind a NAT.

   As for the delete payload, the peer address update payload specifies
   the SPIs of the IPsec and IKE SAs it applies to.  But a simple way to
   specify all SAs (i.e., the IKE SA and all the tunnel mode IPsec SAs
   it negotiated) is needed so is provided.

   An updated peer address may be in some corresponding SPD entries:
   when an IPsec SA is modified, by default the SPD entry which matches
   the traffic selector SHOULD be accordingly modified (cf. the next
   version of the IPsec architecture [3]).  This behavior MAY be
   disabled.

3.5.  Open issues

   Notification/payload/exchange: the current choice is a notification
   for peer addresses (copied on NAT detection notifications) and a
   payload for peer address update (copied on SA delete payload).

   Interaction with NAT-T: the current choice is to avoid the case where
   one peer is behind a NAT then uses NAT-T and the other peer uses
   MOBIKE: in this situation NAT-T usage by both peers MUST be enforced.

   Path failure detection: the proposal does not provide any dedicated
   mechanism, the generic mobility or multi-homing control SHOULD be



Dupont                    Expires May 22, 2006                  [Page 8]

Internet-Draft        Address Management for IKEv2         November 2005


   used instead, including for simultaneous changes.

   When to perform a return routability check?: this is a policy issue,
   some answers follow.

   Can a peer address set be empty?: still open.  Mechanisms permit
   this...

   New error notification for address problems: likely to be necessary.

   Dead lock with too small message window?: message windows greater
   than one are RECOMMENDED and the last message of windows SHOULD be
   reserved to MOBIKE.

   Peer address addition request from an unknown address: (here unknown
   means not in the peer address set even after the processing of the
   message) this is the only circumstance where a return routability
   check is clearly REQUIRED:
   -  if it succeeds for the peer address the message MUST be accepted
   -  if it fails for the peer address but succeeds for the unknown
      source address the peer has moved behind a NAT.

   Last point: how to update the SPD entries?  One possibility is to
   change the PAD ([3] section 4.4.3 defining the Peer Authorization
   Database) too.


4.  Security Considerations

   Great care was used to avoid to introduce new security threats.

   The NAT traversal feature comes with a security flaw (the transient
   pseudo-NAT attack [10]) which can not be easily avoid.  IMHO the NAT
   traversal feature should be enabled only when the presence of NATs is
   likely/possible.

   When the NAT traversal feature is disabled, the address of the other
   peer can not be changed en-route by an attacker but the proofs the
   peer is really at its address are:
   -  the trust in the peer
   -  the source address is topologically plausible
   -  the proof that the peer can receive messages sent to its address.

   The second (a.k.a. the return routability check) works only with at
   least two ot three not-trivial messages, i.e., for the initial
   exchange (with the address stability requirement) and for explicit
   checks.  IMHO these checks SHOULD be required for a new alternate
   peer address as soon as there is no proof of the address validity,



Dupont                    Expires May 22, 2006                  [Page 9]

Internet-Draft        Address Management for IKEv2         November 2005


   for instance when:
   -  the message does not come from this address (ingress filtering
      [14] can drop a message with a fake source address),
   -  and there is no authorization for this address.


5.  Acknowledgments

   The rare people in the Mobility world with IPsec interests, or in the
   IPsec world with Mobility interest, should receive all thanks because
   without them we (me and all the future co-authors) have given up for
   a long time.

   Tero Kivinen helped to improve the NAT traversal part of this
   proposal.  Tero and Jari Arkko proposed another form of peer address
   update based on the IKE SA addresses.  Pasi Eronen suggested the
   NAT_PREVENTION notification.


6.  References

6.1.  Normative References

   [1]  Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
        draft-ietf-ipsec-ikev2-17.txt (work in progress),
        September 2004.

   [2]  Dupont, F., "IPsec transport mode in Mobike environments",
        draft-dupont-mobike-transport-03.txt (work in progress),
        October 2005.

   [3]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", draft-ietf-ipsec-rfc2401bis-06.txt (work in
        progress), March 2005.

6.2.  Informative References

   [4]   IKEv2 Mobility and Multihoming (mobike), "Charter", 2004,
         <http://www.ietf.org/html.charters/mobike-charter.html>.

   [5]   Vilhuber, J., "IP header compression in IPsec ESP",
         draft-vilhuber-hcoesp-01.txt (work in progress), July 2004.

   [6]   Korver, B., "The Internet IP Security PKI Profile of IKEv1/
         ISAKMP, IKEv2, and PKIX",
         draft-ietf-pki4ipsec-ikecert-profile-07.txt (work in progress),
         November 2005.




Dupont                    Expires May 22, 2006                 [Page 10]

Internet-Draft        Address Management for IKEv2         November 2005


   [7]   Hoffman, P., "Adding revised identities to IKEv2",
         November 2002, <Message-ID: <p05200f06b9edf48ac57b@
         [165.227.249.18]>>.

   [8]   Kaat, M., "Overview of 1999 IAB Network Layer Workshop",
         RFC 2956, October 2000.

   [9]   Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol",
         draft-ietf-mobike-design-04.txt (work in progress),
         October 2005.

   [10]  Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks or
         how NATs are even more evil than you believed",
         draft-dupont-transient-pseudonat-04.txt (work in progress),
         June 2004.

   [11]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [12]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
         Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
         Agents", RFC 3776, June 2004.

   [13]  Dupont, F. and W. Haddad, "How to make IPsec more mobile IPv6
         friendly", draft-dupont-ipsec-mipv6-05.txt (work in progress),
         February 2004.

   [14]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", RFC 2827, BCP 38, May 2000.

   [15]  McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management
         API, Version 2", RFC 2367, July 1998.


Appendix A.  Peer Address Notification Format

   The following diagram illustrates the content of the Peer Address
   Notification:












Dupont                    Expires May 22, 2006                 [Page 11]

Internet-Draft        Address Management for IKEv2         November 2005


                            1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Next Payload  !C!  RESERVED   !         Payload Length        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !  Protocol-ID  !   SPI Size    !      Notify Message Type      !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !        Address Family         !          Operation            !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                            Address                            ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1

   The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 and
   no SPI).  The Address Family is from IANA Address Family Numbers
   (IPv4 is 1 and IPv6 2).  The proposed names are PEER_ADDRESS_SOURCE
   and PEER_ADDRESS_DESTINATION, with 248XX.  Operation codes are:
   -  MARK (1): the peer address is marked for further operation, for
      instance an peer address update: the marked address will become
      the new primary peer address.
   -  ADD (2): add a new alternate peer address to the set.
   -  DELETE (3): delete an alternate peer address from the set.


Appendix B.  Peer Address Update Payload Format

   The next figure shows the format of the Peer Address Update Payload.
   It is possible to send multiple SPIs in a Peer Address Update
   payload, however, each SPI MUST be for the same protocol.  Mixing of
   Protocol Identifiers MUST NOT be performed in a the Peer Address
   Update payload.  It is permitted, however, to include multiple Peer
   Address Update payloads in a single INFORMATIONAL Exchange where each
   Peer Address Update payload lists SPIs for a different protocol.

   Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but no
   SPI.  Update of a CHILD_SA, such as ESP or AH, will contain the
   Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the
   SPI the sending endpoint would expect in inbound ESP or AH packets.

   The following diagram illustrates the content of the Peer Address
   Update Notification:








Dupont                    Expires May 22, 2006                 [Page 12]

Internet-Draft        Address Management for IKEv2         November 2005


                            1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Next Payload  !C!  RESERVED   !         Payload Length        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !A|O|Protocol-ID!   SPI Size    !          # of SPIs            !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                                                               !
       ~               Security Parameter Index(es) (SPI)              ~
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2


   -  A[ll] (1 bit) - MUST be set to one when all SAs (the IKE SA and
      all tunnel mode outgoing IPsec SAs negotiated by it) are updated.
      In this case the update is for the IKE-SA (Protocol-ID 0, SPI size
      0, no SPI and number of SPIs 0).  MUST be set to zero when an
      individual SA is updated.

   -  O[nly] (1 bit) - MUST be set to one when the corresponding SPD
      entry when it exists MUST NOT be modified.  MUST be set to zero
      for the default behavior: for all SPD entries matching traffic
      selectors of updated IPsec SAs the peer address(es) MUST be
      updated.

   -  Protocol_Id (6 bits) - MUST be zero for an IKE_SA, 1 for ESP, or 2
      for AH.

   -  SPI Size (1 octet) - Length in octets of the SPI as defined by the
      Protocol-Id.  Zero for IKE (the SPI is got from the message
      header) or four for AH or ESP.

   -  # of SPIs (2 octets) - The number of SPIs contained in the Peer
      Address Update Notification.  The size of each SPI is defined by
      the SPI Size field.

   -  Security Parameter Index(es) (variable length) - Identifies the
      specific security association(s) to delete.  The lengths of these
      fields are determined by the SPI Size and the number of SPIs
      fields.

   The C[ritical] bit MUST be set to one even a peer which does not
   support Peer Address Update Payloads does not support Peer Address
   Notifications too.




Dupont                    Expires May 22, 2006                 [Page 13]

Internet-Draft        Address Management for IKEv2         November 2005


   ESP and AH SAs always exist in pairs, with one SA in each direction.
   When an SA is updated for a peer address, both members of the pair
   MUST be updated.  When SAs are nested, as when data (and IP headers
   if in tunnel mode) are encapsulated first with IPcomp, then with ESP,
   and finally with AH between the same pair of endpoints, all of the
   SAs MUST be updated together.  Each endpoint MUST update the SAs it
   receives on and allow the other endpoint to update the other SA in
   each pair.

   To update a peer address of an SA, an Informational Exchange with one
   or more peer address update payloads is sent listing the SPIs (as
   they would be placed in the headers of inbound packets) of the SAs to
   be updated, and with a peer address notification setting the primary
   peer address.  The recipient MUST update the designated SAs.
   Normally, the reply in the Informational Exchange will contain peer
   address update payloads for the paired SAs going in the other
   direction.  Note there is no special case for update collision.

   The proposed name is the Update (U) payload.


Appendix C.  NAT Prevention Notification Format

   The NAT_PREVENTION notification purpose is to protect the peer
   addresses in the IKE_SA_INIT exchange without misleading the
   responder, i.e., NAT_DETECTION_SOURCE_IP and
   NAT_DETECTION_DESTINATION_IP do the same thing but suggest the
   responder is ready to accept NAT traversal.

   The NAT_PREVENTION notification SHOULD be used when NAT traversal is
   not wanted and the authentication does not validate the peer address:
   the default policy (cf. [6] section 3.1.1 about address ID payloads)
   is to validate peer addresses but only when the ID payload is an
   address and this validation may be disabled.

                            1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Next Payload  !C!  RESERVED   !         Payload Length        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !  Protocol-ID  !   SPI Size    !      Notify Message Type      !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~               SHA-1 Hash of the Pseudo-Header                 ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3




Dupont                    Expires May 22, 2006                 [Page 14]

Internet-Draft        Address Management for IKEv2         November 2005


   The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 and
   no SPI).  The content is the SHA-1 hash of the transport pseudo-
   header.

   NOTE: there is an IPR issue over the NAT detection notifications.


Appendix D.  Return Routability Cookie Notification Format

   The RR_COOKIE notification layout is:

                            1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Next Payload  !C!  RESERVED   !         Payload Length        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !  Protocol-ID  !   SPI Size    !      Notify Message Type      !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                             Cookie                            ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4

   The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 and
   no SPI).  The data associated with the notification (i.e., the cookie
   itself) MUST be between 16 and 64 octets in length (inclusive).

   This cookie SHOULD be included in return routability probes in order
   to make them unpredictable.  A reply to a request carrying a
   RR_COOKIE notification MUST contain a copy of it.


Appendix E.  PF_KEY version 2 SADB_X_ADDUPD

   This annex describes an extension to PF_KEYv2 [15] which provides a
   way to ask a peer address update of an IPsec SA and all its siblings
   (i.e., an update with the All flag set to one).

   The format of the message is:
      <base, SA(*), address(SD), new_address(SD)>
   and is sent the registered socket listeners by or via the kernel.  No
   answer is needed because if it fails it will be done again.

   New values are needed for SADB_X_ADDUPD and for
   SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST which
   should have the same layout than SADB_EXT_ADDRESS_*, i.e.,
   sadb_address structure.



Dupont                    Expires May 22, 2006                 [Page 15]

Internet-Draft        Address Management for IKEv2         November 2005


   NOTE: IKE itself needs a PF_KEYv2 extension for individual updating
   of an IPsec SA.

















































Dupont                    Expires May 22, 2006                 [Page 16]

Internet-Draft        Address Management for IKEv2         November 2005


Author's Address

   Francis Dupont
   Point6
   c/o GET/ENST Bretagne
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   France

   Fax:   +33 2 99 12 70 30
   Email: Francis.Dupont@enst-bretagne.fr







































Dupont                    Expires May 22, 2006                 [Page 17]

Internet-Draft        Address Management for IKEv2         November 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Dupont                    Expires May 22, 2006                 [Page 18]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/