[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08                                    
Internet Engineering Task Force                         Francis Dupont
INTERNET DRAFT                                           ENST Bretagne
Expires in August 2003                                   February 2003

                 Address Management for IKE version 2


Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   This document is an Internet-Draft.  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

   The list of Internet-Draft Shadow Directories can be accessed at

   Distribution of this memo is unlimited.


   The current IKEv2 proposal [1] lacks an address management
   feature. As it includes a NAT traversal capability, this document
   extends it to a complete address management with support for NAT
   traversal, multi-homing and mobility.

1. Introduction

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

draft-dupont-ikev2-addrmgmt-01.txt                            [Page 1]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

   The current IKEv2 draft [1] often makes the 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 fixed.

   NAT traversal, multi-homing and mobility should take benefit from
   this flexibility but the current IKEv2 draft [1] takes only account
   of NAT traversal in a flawed way [5]. This document describes the
   goals of an address management for IKEv2, including the
   requirements for NAT traversal, multi-homing and mobility support,
   and finishes by a concrete proposal.

   In this document, open questions are introduced by the word NOTE.

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 General goals

2.1.1 Simplicity, Performance and Security

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

    The performance is an important criterion. For instance, rekeying
    can update the peer addresses of an IKE SA or of 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 [5]). Such problems introduced by the peer address
    flexibility must be described in this document and at least be
    mitigated by options in configurations. For instance, the NAT
    traversal feature should never be enabled when one knows that
    there can not be a NAT as in today IPv6.

2.1.4 Extensions of the IKEv2 draft

    The first things to fix in the current IKEv2 draft [1] are the
    notifications for NAT traversal (NAT-DETECTION-*-IP):

     - They use a hash of the SPIs, address and port, following
       a specification for IKEv1. This makes no sense for IKEv2
       when the peer does not want to keep its address secret.

     - There is no specified way to request the inclusion of
       these notifications in messages.

draft-dupont-ikev2-addrmgmt-01.txt                            [Page 2]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

     - There can be multiple source notifications. IMHO this is a good
       idea but the rationale (the sender does not know what address
       it uses) is weak. The API to get the address used for UDP
       packets to a destination is very standard.

    NOTE: is it really needed to do NAT detection in the first
    exchange? In fact, the question is whether the responder can
    detect NATs from the third message.

    The second missing thing in the current IKEv2 draft [1] is about
    some misusage of the peer addresses:

     - At the reception of a message, the lookup of the corresponding
       IKE SA MUST be done using only the SPIs, never using the peer

     - An INITIAL-CONTACT notification deletes old IKE SAs associated
       to the peer Identity, not to the peer address. Current wording
       is a bit misleading.

     - The revised identity proposal [3] should be integrated in the
       IKEv2 specifications. According to IAB recommendations [4],
       addresses should not be used as or associated to identities.

    Note that the last point stresses the issue of the lack of
    protection of peer addresses.

    The last thing to fix in the current IKEv2 draft [1] is the
    support of the proxy case: the setup of transport mode IPsec SAs
    on the behalf of another party.

2.2 NAT traversal requirements

    The NAT traversal feature is the support of en-route peer address

     - NATs must be detected, including their position, i.e., the
       receiver of an IKE message should be able to detect any peer
       address alteration.

     - The peer addresses are included in the pseudo IP header of
       transport checksums when a transport mode IPsec SA is used. The
       peers must know the original peer address of their correspondent.

     - When there are several VPN clients behind a NAT, the ability to
       request a three way handshake (a.k.a. a return routability
       check) is needed [6].

     - As NATs can be used to hide a peer address, a way to keep a
       peer address secret should be specified.

     - Peers have no control on NATs between them: explicit mechanisms
       for peer address update have no advantage.

draft-dupont-ikev2-addrmgmt-01.txt                            [Page 3]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

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 subset can be loosely associated with
    some destinations (i.e., some subset of the other peer address

    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 ([7] and for the special case of
    Home Agents [8]), the interaction of Mobility and IPsec was
    analyzed in another document [9]. This document assumes an IPv6
    context as Mobile IPv6 is the most powerful mobility proposal
    available today.

    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 must 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.

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

     - 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 special
       proxy case.

draft-dupont-ikev2-addrmgmt-01.txt                            [Page 4]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

     - 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 [7] and [8]).

     - 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.

    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 mainly an
    extension of the NAT traversal notifications with a new peer
    address update notification. But there are some points that have
    to be kept as they are in the current IKEv2 draft [1].

3.1 Kept points from draft 04

    A peer address change has to be supported but not at any time:
    the peer addresses MUST NOT change during an exchange, i.e.,
    they are allowed to change only between two exchanges.

    This address stability requirement applies in fact only to the
    Initial exchange as it is the only exchange with more than two
    messages specified today.

    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

draft-dupont-ikev2-addrmgmt-01.txt                            [Page 5]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

    For tunnel mode IPsec SAs, the endpoint addresses are the 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 Small points

    In the proxy case, the initiator is acting as a client negotiator
    on the behalf of another party. The address of this other party is
    sent in the initiator traffic selector and will become the address
    of this end of the transport mode IPsec SA pair. A proper
    authorization in the local policy of the responder is
    REQUIRED. Note that the IPsec SAs built in such cases are not
    managed in the proposal of these document, and that the proxy case
    is limited to the transport mode.

    The INITIAL-CONTACT notification uses only identities. All the
    references to peer addresses must be removed from or fixed in the
    current wording.

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

3.3 Peer address notifications

    The peer address notifications replace the current
    notifications. They includes the peer source or destination
    address and the source or destination port. They SHOULD be used
    only in protected messages (i.e., not in the first exchange)
    and SHOULD be ignored when they are not protected, i.e., outside
    an encrypted payload.

    NOTE: in fact we have the choice between to replace NAT detection
    notifications or to specify new notifications. Here we assume
    the second was chosen.

    The peer address notifications support IPv4, IPv6 and a hashed
    format of peer addresses when a peer wants to keep its address
    secret and to perform NAT detection.

    For NAT traversal, they are used to detect NATs and their
    position, and they provide the original peer addresses for
    transport mode. For multi-homing and mobility, they provide a
    cryptographically proof of no alteration en-route of the peer
    addresses and, when multiple peer address notifications for the
    same peer are included, they encode its whole peer address set.
    To allow the reduction of the peer address set to one address,
    an address MAY be repeated.

draft-dupont-ikev2-addrmgmt-01.txt                            [Page 6]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

    A new notification has to be defined for the peer address
    notification request by the responder. Typically a responder
    asking for either NAT traversal or a peer address protection (i.e.,
    the opposite) will put this notification in the second message of
    the initial exchange. All following messages MUST include the
    requested peer address notifications.

    NOTE: is a way to request source or destination protection needed?

    For the initiator a simple way to request peer address
    notifications is to include then in requests: when peer address
    notifications are required, peer address notifications MUST be
    included in the encrypted payload of requests. When a peer address
    notification is included in a request, peer address notifications
    are required, all following messages MUST include the peer address
    protection notification(s), beginning by the reply message.

    NOTE: a simpler proposal is to make peer address notifications
    mandatory for any message at the exception of the first exchange.

    If multiple peer address notifications for the same peer are
    included in a message, the first one SHOULD for the source and
    MUST for the destination be the used peer address. The extra
    addresses describe the other possible peer addresses, i.e., there
    is at least one peer address notification per address in the peer
    address set.

    In order to associate some possible peer source addresses to
    possible peer destination addresses, the source and destination
    peer addresses notifications MAY be mixed (i.e., not in the common
    order source(s) first, destination(s) after). For instance S1, S2,
    D1, S3, D2, D3 is a hint: S1 or S2 should be used in conjunction
    with D1, S3 with D2 or D3.

    In case of a mismatch of a peer address with the corresponding
    peer address notifications, a NAT is detected:
     - if the peer address notifications are not protected, they are
       ignored. (this can happen only in the first exchange)
     - in the Initial exchange:
       * if NAT traversal is enabled, both peers MUST switch to
         port 4500 for following exchanges and new IPsec SAs.
       * if NAT traversal is disabled, the receiving peer MUST
         ignore the compromised message and send an error notification
         to its peer.
     - after the Initial exchange and when NAT traversal is disabled,
       this kind of messages can be dangling updates or attacks.
       If the possibly compromised message is a new request, its content
       MUST be ignored and an error notification sent, but the message
       counter MUST be incremented in order to accept the next request.
       If it is a retransmitted request, the cached reply MUST be sent.
       If it is a reply, the corresponding request MUST be retransmitted.

draft-dupont-ikev2-addrmgmt-01.txt                            [Page 7]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

    NOTE: the error notification is fatal only in the Initial
    exchange. Perhaps the wording should be better, i.e., error
    implies fatal in [1]?

    NOTE: if the peer has moved between two retransmissions of a
    request, it can interleave an explicit address update of at
    least the IKE SA.

3.4 Implicit address update

    For address update, there is a choice between implicit and
    explicit mechanisms for IPsec SAs and IKE SAs.

    We claim that the implicit mechanism for IPsec SAs is far too
    unsecure for controlled contexts: this mechanism is very (too?)
    simple. When a packet is received from another address, the peer
    addresses of all SAs are updated. This opens the door to easy
    denial of service attacks and assumes extra-processing by the
    receiver device.

    So the implicit mechanism is restricted to the case where a NAT
    was detected, i.e., when IPsec runs over the port 4500. In this
    case, the update is performed on all SAs (the IKE SA and all
    non-proxy IPsec SAs built with it). This update function SHOULD
    be accessible from the outside, see Annex D.

    For the implicit mechanism for IKE SAs the things are even
    simpler. The implicit mechanism is mainly activated by keepalive
    exchanges: to switch from the implicit mechanism to the explicit
    one, only an update notification has to be included. The real
    difference is in the explicit case an observed peer address change
    is only a trigger.

    NOTE: should we specify a mechanism to advertise the other peer?

3.5 Explicit address update

    The explicit mechanism MUST be used when NAT traversal is disabled
    and only it this case. A new notification has to be defined.
    We propose to copy it from the delete payload, see Annex C.

    The new peer address notification has strong sequencing
    requirements. It MUST be processed in order and when a pending
    exchange with a peer address update has to be overrided by a more
    recent one, the peer address update notification MUST be
    canceled by retransmission from the new peer address.

    NOTE: IKEv2 messages have a protected sequence number so the
    only sequencing issues are the window of processing and pending

draft-dupont-ikev2-addrmgmt-01.txt                            [Page 8]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

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

    Example of a return routability check:

     I --- address update request --> R
     I <-- informational RR request - R
     I --- informational RR reply --> R
       now the responder knows the initiator should be where it said.
     I <--- address update reply ---- R

    As for the delete notification, the peer address update
    notification 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 non-proxy IPsec SAs it negotiated) is needed.

4. Security Considerations

   Great care was used to avoid to introduce security threats.

   The NAT traversal feature comes with a security flaw (the transient
   pseudo-NAT attack [5]) 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 other peer address
   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 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 three messages, i.e., for the initial exchange (with the
   address stability requirement) and for the explicit optional
   checks. IMHO these checks SHOULD be required by default.

5. Acknowledgments

   The need for an address management for IKEv2 was explained at the
   ipsec session of the Yokohama IETF meeting. It seems most people
   agree but do not propose concrete solutions.

   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

draft-dupont-ikev2-addrmgmt-01.txt                            [Page 9]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

6. Changes from previous version

   Secret peer addresses are supported.

   The implicit mechanism comes back but is restricted to NAT traversal.

   Annexes are added for a more accurate proposal.

7. Normative References


8. Informative References

   [1] C. Kaufman, ed., "Proposal for the IKEv2 Protocol",
   draft-ietf-ipsec-ikev2-05.txt, February 2003.

   [2] B. Korver, E. Rescorla, "The Internet IP Security PKI
   Profile of ISAKMP and PKIX",
   draft-ietf-ipsec-pki-profile-01.txt, October 2002.

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

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

   [5] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks
   or how NATs are even more evil than you believed",
   draft-dupont-transient-pseudonat-01.txt, December 2002.

   [6] Jayant Shukla, "RE: peer address protection and NAT Traversal",
   Message-ID: <000201c2bb27$e7021ff0$5803a8c0@trlhpc1>,
   January 2003.

   [7] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6",
   draft-ietf-mobileip-ipv6-20.txt, January 2003.

   [8] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect
   Mobile IPv6 Signaling between Mobile Nodes and Home Agents",
   draft-ietf-mobileip-mipv6-ha-ipsec-03.txt, February 2003.

   [9] F. Dupont, "How to make IPsec more mobile IPv6 friendly",
   draft-dupont-ipsec-mipv6-02.txt, January 2003.

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

draft-dupont-ikev2-addrmgmt-01.txt                           [Page 10]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

9. Author's Address

   Francis Dupont
   ENST Bretagne
   Campus de Rennes
   2, rue de la Chataigneraie
   BP 78
   35512 Cesson-Sevigne Cedex
   Fax: +33 2 99 12 70 30
   EMail: Francis.Dupont@enst-bretagne.fr

Annex A. Proxy Case Usage Scenario.

      !           !
      !Negotiator !
      !Endpoint   !<.....\      IKE
      !           !       \............................\
      +-+-+-+-+-+-+                                    !
      +-+-+-+-+-+                                  +-+-+-+-+-+
      !         !                                  !         !
      !Protected!        IPsec Transport           !Protected!
      !Endpoint !<-------------------------------->!Endpoint !
      !         !                                  !         !
      +-+-+-+-+-+                                  +-+-+-+-+-+

   In this scenario, both protected endpoints of the IP connection
   implement IPsec both the first one does not support IKE. The
   negotiator endpoint needs only to implement IKE. Address
   management is not supported for the IPsec SAs between the two
   protected endpoints because the negotiator endpoint has no
   control over the address of the protected endpoint it establishes
   on the behalf of. For instance, NAT traversal is not supported.

Annex B. Peer Address Notification Format.

   The following diagram illustrates the content of the Peer Address

                         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         !             Port              !
    ~                            Address                            ~

draft-dupont-ikev2-addrmgmt-01.txt                           [Page 11]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

   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) with a special meaning for the family 0:
   when the address family is 0, the real address is hashed using
   the negotiated digest algorithm for the IKE SA.

   NOTE: is this hash = prf(SK_a, <address>)?

   The proposed names are PEER-ADDRESS-SOURCE and

   NOTE: we can reused 24582 and 24583 for the notify message types
   or get new values.

Annex C. Peer Address Update Notification Format.

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

                         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      !
    !                                                               !
    ~             First Security Parameter Index (SPI)              ~
    !                                                               !
    !       RESERVED              !A!          # of SPIs            !
    !                                                               !
    ~            Other Security Parameter Indexes (SPIs)            ~
    !                                                               !

   o  Protocol-Id (1 octet) - Must be zero for an IKE-SA, 50 for
      ESP, or 51 for AH.

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

   o  All (1 bit) - MUST be set to one when all SAs (the IKE SA and
      all non-proxy 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  # 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.

draft-dupont-ikev2-addrmgmt-01.txt                           [Page 12]

INTERNET-DRAFT        Address Management for IKEv2            Feb 2003

   o  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 # of SPIs fields.

   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 sends 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 notifications is sent
   listing the SPIs (as they would be placed in the headers of outbound
   packets) of the SAs to be updated. The recipient MUST update the
   designated SAs. Normally, the reply in the Informational Exchange
   will contain peer address update notifications for the paired SAs
   going in the other direction. Note there is no special case for
   update collision.

   The proposed name is PEER-ADDRESS-UPDATE.

   NOTE: a payload should be better.

Annex D. PF_KEY version 2 SADB_X_ADDUPD

   This annex describes an extension to PF_KEYv2 [10] 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
   which should have the same layout than SADB_EXT_ADDRESS_*,
   i.e., sadb_address structure.

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

draft-dupont-ikev2-addrmgmt-01.txt                           [Page 13]