doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5269.txt b/doc/rfc/rfc5269.txt
new file mode 100644
index 0000000..7c03046
--- /dev/null
+++ b/doc/rfc/rfc5269.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                           J. Kempf
+Request for Comments: 5269                               DoCoMo Labs USA
+Category: Standards Track                                      R. Koodli
+                                                        Starent Networks
+                                                               June 2008
+
+
+ Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using
+                   SEcure Neighbor Discovery (SEND)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   Fast Mobile IPv6 requires that a Fast Binding Update is secured using
+   a security association shared between an Access Router and a Mobile
+   Node in order to avoid certain attacks.  In this document, a method
+   for provisioning a shared key from the Access Router to the Mobile
+   Node is defined to protect this signaling.  The Mobile Node generates
+   a public/private key pair using the same public key algorithm as for
+   SEND (RFC 3971).  The Mobile Node sends the public key to the Access
+   Router.  The Access Router encrypts a shared handover key using the
+   public key and sends it back to the Mobile Node.  The Mobile Node
+   decrypts the shared handover key using the matching private key, and
+   the handover key is then available for generating an authenticator on
+   a Fast Binding Update.  The Mobile Node and Access Router use the
+   Router Solicitation for Proxy Advertisement and Proxy Router
+   Advertisement from Fast Mobile IPv6 for the key exchange.  The key
+   exchange messages are required to have SEND security; that is, the
+   source address is a Cryptographically Generated Address (CGA) and the
+   messages are signed using the CGA private key of the sending node.
+   This allows the Access Router, prior to providing the shared handover
+   key, to verify the authorization of the Mobile Node to claim the
+   address so that the previous care-of CGA in the Fast Binding Update
+   can act as the name of the key.
+
+
+
+
+
+
+
+
+
+
+Kempf & Koodli              Standards Track                     [Page 1]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................3
+   2. Overview of the Protocol ........................................3
+      2.1. Brief Review of SEND .......................................3
+      2.2. Protocol Overview ..........................................4
+   3. Handover Key Provisioning and Use ...............................4
+      3.1. Sending Router Solicitations for Proxy Advertisement .......4
+      3.2. Receiving Router Solicitations for Proxy
+           Advertisement and Sending Proxy Router Advertisements ......5
+      3.3. Receiving Proxy Router Advertisements ......................6
+      3.4. Sending FBUs ...............................................7
+      3.5. Receiving FBUs .............................................7
+      3.6. Key Generation and Lifetime ................................7
+      3.7. Protocol Constants .........................................8
+   4. Message Formats .................................................8
+      4.1. Handover Key Request Option ................................8
+      4.2. Handover Key Reply Option .................................10
+   5. Security Considerations ........................................11
+   6. IANA Considerations ............................................11
+   7. References .....................................................12
+      7.1. Normative References ......................................12
+      7.2. Informative References ....................................12
+
+1.  Introduction
+
+   In Fast Mobile IPv6 (FMIPv6) [FMIP], a Fast Binding Update (FBU) is
+   sent from a Mobile Node (MN), undergoing IP handover, to the previous
+   Access Router (AR).  The FBU causes a routing change so traffic sent
+   to the MN's previous Care-of Address on the previous AR's link is
+   tunneled to the new Care-of Address on the new AR's link.  Only an MN
+   authorized to claim the address should be able to change the routing
+   for the previous Care-of Address.  If such authorization is not
+   established, an attacker can redirect a victim MN's traffic at will.
+
+   In this document, a lightweight mechanism is defined by which a
+   shared handover key for securing FMIP can be provisioned on the MN by
+   the AR.  The mechanism utilizes SEND [SEND] and an additional
+   public/private key pair, generated on the MN using the same public
+   key algorithm as SEND, to encrypt/decrypt a shared handover key sent
+   from the AR to the MN.  The key provisioning occurs at some arbitrary
+   time prior to handover, thereby relieving any performance overhead on
+   the handover process.  The message exchange between the MN and AR to
+   provision the handover key is required to be protected by SEND; that
+   is, the source address for the key provisioning messages must be a
+   CGA and the messages must be signed with the CGA private key.  This
+   allows the AR to establish the MN's authorization to operate on the
+
+
+
+Kempf & Koodli              Standards Track                     [Page 2]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+   CGA.  The AR uses the CGA to name the handover key.  The SEND key
+   pair is, however, independent from the handover encryption/decryption
+   key pair and from the actual handover key.  Once the shared handover
+   key has been established, when the MN undergoes IP handover, the MN
+   generates an authorization Message Authentication Code (MAC) on the
+   FBU.  The previous care-of CGA included in the FBU is used by the AR
+   to find the right handover key for checking the authorization.
+
+   Handover keys are an instantiation of the purpose built key
+   architectural principle [PBK].
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   In addition, the following terminology is used:
+
+   CGA public key
+
+          Public key used to generate the CGA according to RFC 3972
+          [CGA].
+
+   CGA private key
+
+          Private key corresponding to the CGA public key.
+
+   Handover key encryption public key
+
+          Public key generated by the MN and sent to the current AR to
+          encrypt the shared handover key.
+
+   Handover key encryption private key
+
+          Private key corresponding to handover key encryption public
+          key, held by the MN.
+
+2.  Overview of the Protocol
+
+2.1.  Brief Review of SEND
+
+   SEND protects against a variety of threats to local link address
+   resolution (also known as Neighbor Discovery) and last hop router
+   (AR) discovery in IPv6 [RFC3756].  These threats are not exclusive to
+   wireless networks, but they generally are easier to mount on certain
+   wireless networks because the link between the access point and MN
+   can't be physically secured.
+
+
+
+Kempf & Koodli              Standards Track                     [Page 3]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+   SEND utilizes CGAs in order to secure Neighbor Discovery signaling
+   [CGA].  Briefly, a CGA is formed by hashing together the IPv6 subnet
+   prefix for a node's subnet, a random nonce, and an RSA public key,
+   called the CGA public key.  The CGA private key is used to sign a
+   Neighbor Advertisement (NA) message sent to resolve the link-layer
+   address to the IPv6 address.  The combination of the CGA and the
+   signature on the NA proves to a receiving node the sender's
+   authorization to claim the address.  The node may opportunistically
+   generate one or several keys specifically for SEND, or it may use a
+   certified key that it distributes more widely.
+
+2.2.  Protocol Overview
+
+   The protocol utilizes the SEND secured Router Solicitation for Proxy
+   Advertisement (RtSolPr)/Proxy Router Advertisement (PrRtAdv) [FMIP]
+   exchange between the MN and the AR to transport an encrypted, shared
+   handover key from the AR to the MN.  First, the MN generates the
+   necessary key pair and associated CGA addresses so that the MN can
+   employ SEND.  Then, the MN generates a public/private key pair for
+   encrypting/decrypting the shared handover key, using the same public
+   key algorithm as was used for SEND.  The MN then sends an RtSolPr
+   message with a Handover Key Request Option containing the handover
+   key encryption public key.  The source address of the RtSolPr message
+   is the MN's care-of CGA on the AR's link, the RtSolPr message is
+   signed with the MN's CGA key, and contains the CGA Parameters option,
+   in accordance with RFC 3971 [SEND].  The AR verifies the message
+   using SEND, then utilizes the handover key encryption public key to
+   encrypt a shared handover key, which is included with the PrRtAdv in
+   the Handover Key Reply Option.  The MN decrypts the shared handover
+   key and uses it to establish an authorization MAC when it sends an
+   FBU to the previous AR.
+
+3.  Handover Key Provisioning and Use
+
+3.1.  Sending Router Solicitations for Proxy Advertisement
+
+   At some time prior to handover, the MN MUST generate a handover key
+   encryption public/private key pair, using exactly the same public key
+   algorithm with exactly the same parameters (key size, etc.) as for
+   SEND [SEND].  The MN can reuse the key pair on different access
+   routers but MUST NOT use the key pair for any other encryption or for
+   signature operation.  In order to prevent cryptanalysis, the key pair
+   SHOULD be discarded after either a duration of HKEPK-LIFETIME or
+   HKEPK-HANDOVERS number of handovers, whichever occurs first.  See
+   Section 3.7 for definitions of protocol constants.
+
+
+
+
+
+
+Kempf & Koodli              Standards Track                     [Page 4]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+   The MN MUST send a Router Solicitation for Proxy Advertisement
+   (RtSolPr) containing a Handover Key Request Option with the handover
+   encryption public key.  A CGA for the MN MUST be the source address
+   on the packet, and the MN MUST include the SEND CGA Option and SEND
+   Signature Option with the packet, as specified in [SEND].  The SEND
+   signature covers all fields in the RtSolPr, including the 128-bit
+   source and destination addresses and ICMP checksum as described in
+   RFC 3971, except for the Signature Option itself.  The MN also sets
+   the handover authentication Algorithm Type (AT) extension field in
+   the Handover Key Request Option to the MN's preferred FBU
+   authentication algorithm.  The SEND Nonce MUST also be included for
+   anti-replay protection.
+
+3.2.  Receiving Router Solicitations for Proxy Advertisement and Sending
+      Proxy Router Advertisements
+
+   When an FMIPv6 capable AR with SEND receives an RtSolPr from an MN
+   protected with SEND and including a Handover Key Request Option, the
+   AR MUST first validate the RtSolPr using SEND as described in RFC
+   3971.  If the RtSolPr can not be validated, the AR MUST NOT include a
+   Handover Key Reply Option in the reply.  The AR also MUST NOT change
+   any existing key record for the address, since the message may be an
+   attempt by an attacker to disrupt communications for a legitimate MN.
+   The AR SHOULD respond to the RtSolPr but MUST NOT perform handover
+   key provisioning.
+
+   If the RtSolPr can be validated, the AR MUST then determine whether
+   the CGA is already associated with a shared handover key.  If the CGA
+   is associated with an existing handover key, the AR MUST return the
+   existing handover key to the MN.  If the CGA does not have a shared
+   handover key, the AR MUST construct a shared handover key as
+   described in Section 3.6.  The AR MUST encrypt the handover key with
+   the handover key encryption public key included in the Handover Key
+   Request Option.  The AR MUST insert the encrypted handover key into a
+   Handover Key Reply Option and MUST attach the Handover Key Reply
+   Option to the PrRtAdv.  The lifetime of the key, HK-LIFETIME, MUST
+   also be included in the Handover Key Reply Option.  The AR SHOULD set
+   the AT field of the Handover Key Option to the MN's preferred
+   algorithm type indicated in the AT field of the Handover Key Request
+   Option, if it is supported; otherwise, the AR MUST select an
+   authentication algorithm that is of equivalent strength or stronger,
+   and set the field to that.  The AR MUST also include the SEND nonce
+   from the RtSolPr for anti-replay protection.  The AR MUST have a
+   certificate suitable for a SEND-capable router, support SEND
+   certificate discovery, and include a SEND CGA Option and a SEND
+   Signature Option in the PrRtAdv messages it sends.  Similarly, the
+   mobile nodes MUST be configured with one or more SEND trust anchors
+   so that they can verify these messages.  The SEND signature covers
+
+
+
+Kempf & Koodli              Standards Track                     [Page 5]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+   all fields in the PrRtAdv, including the 128-bit source and
+   destination addresses and ICMP checksum as described in RFC 3971,
+   except for the Signature Option itself.  The PrRtAdv is then unicast
+   back to the MN at the MN's care-of CGA that was the source address on
+   the RtSolPr.  The handover key MUST be stored by the AR for future
+   use, indexed by the CGA, and the authentication algorithm type (i.e.,
+   the resolution of the AT field processing) and HK-LIFETIME MUST be
+   recorded with the key.
+
+3.3.  Receiving Proxy Router Advertisements
+
+   Upon receipt of one or more PrRtAdvs secured with SEND and having the
+   Handover Key Reply Option, the MN MUST first validate the PrRtAdvs as
+   described in RFC 3971.  Normally, the MN will have obtained the
+   router's certification path to validate an RA prior to sending the
+   PrRtSol and the MN MUST check to ensure that the key used to sign the
+   PrRtAdv is the router's certified public key.  If the MN does not
+   have the router's certification path cached, it MUST use the SEND
+   CPS/CPA messages to obtain the certification path to validate the
+   key.  If a certified key from the router was not used to sign the
+   message, the message MUST be dropped.
+
+   From the messages that validate, the MN SHOULD choose one with an AT
+   flag in the Handover Key Reply Option indicating an authentication
+   algorithm that the MN supports.  From that message, the MN MUST
+   determine which handover key encryption public key to use in the
+   event the MN has more than one.  The MN finds the right public key to
+   use by matching the SEND nonce from the RtSolPr.  If no such match
+   occurs, the MN MUST drop the PrRtAdv.  The MN MUST use the matching
+   private key to decrypt the handover key using its handover key
+   encryption private key, and store the handover key for later use,
+   named with the AR's CGA, along with the algorithm type and
+   HK-LIFETIME.  The MN MUST use the returned algorithm type indicated
+   in the PrRtAdv.  The MN MUST index the handover keys with the AR's
+   IPv6 address, to which the MN later sends the FBU, and the MN's CGA
+   to which the handover key applies.  This allows the MN to select the
+   proper key when communicating with a previous AR.  Prior to
+   HK-LIFETIME expiring, the MN MUST request a new key from the AR if
+   FMIPv6 service is still required from the router.
+
+   If more than one router responds to the RtSolPr, the MN MAY keep
+   track of all such keys.  If none of the PrRtAdvs contains an
+   algorithm type indicator corresponding to an algorithm the MN
+   supports, the MN MAY re-send the RtSolPr requesting a different
+   algorithm, but to prevent bidding down attacks from compromised
+   routers, the MN SHOULD NOT request an algorithm that is weaker than
+   its original request.
+
+
+
+
+Kempf & Koodli              Standards Track                     [Page 6]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+3.4.  Sending FBUs
+
+   When the MN needs to signal the Previous AR (PAR) using an FMIPv6
+   FBU, the MN MUST utilize the handover key and the corresponding
+   authentication algorithm to generate an authenticator for the
+   message.  The MN MUST select the appropriate key for the PAR using
+   the PAR's CGA and the MN's previous care-of CGA on the PAR's link.
+   As defined by the FMIPv6 [FMIP], the MN MUST generate the
+   authentication MAC using the handover key and the appropriate
+   algorithm and MUST include the MAC in the FBU message.  As specified
+   by FMIPv6, the MN MUST include the old care-of CGA in a Home Address
+   Option.  The FMIPv6 document provides more detail about the
+   construction of the authenticator on the FBU.
+
+3.5.  Receiving FBUs
+
+   When the PAR receives an FBU message containing an authenticator, the
+   PAR MUST find the corresponding handover key using the MN's care-of
+   CGA in the Home Address Option as the index.  If a handover key is
+   found, the PAR MUST utilize the handover key and the appropriate
+   algorithm to verify the authenticator.  If the handover key is not
+   found, the PAR MUST NOT change forwarding for the care-of CGA.  The
+   FMIPv6 document [FMIP] provides more detail on how the AR processes
+   an FBU containing an authenticator.
+
+3.6.  Key Generation and Lifetime
+
+   The AR MUST randomly generate a key having sufficient strength to
+   match the authentication algorithm.  Some authentication algorithms
+   specify a required key size.  The AR MUST generate a unique key for
+   each CGA public key, and SHOULD take care that the key generation is
+   uncorrelated between handover keys, and between handover keys and CGA
+   keys.  The actual algorithm used to generate the key is not important
+   for interoperability since only the AR generates the key; the MN
+   simply uses it.
+
+   A PAR SHOULD NOT discard the handover key immediately after use if it
+   is still valid.  It is possible that the MN may undergo rapid
+   movement to another AR prior to the completion of Mobile IPv6 binding
+   update on the PAR, and the MN MAY as a consequence initialize
+   another, subsequent handover optimization to move traffic from the
+   PAR to another new AR.  The default time for keeping the key valid
+   corresponds to the default time during which forwarding from the PAR
+   to the new AR is performed for FMIP.  The FMIPv6 document [FMIP]
+   provides more detail about the FMIP forwarding time default.
+
+   If the MN returns to a PAR prior to the expiration of the handover
+   key, the PAR MAY send and the MN MAY receive the same handover key as
+
+
+
+Kempf & Koodli              Standards Track                     [Page 7]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+   was previously returned, if the MN generates the same CGA for its
+   Care-of Address.  However, the MN MUST NOT assume that it can
+   continue to use the old key without actually receiving the handover
+   key again from the PAR.  The MN SHOULD discard the handover key after
+   MIPv6 binding update is complete on the new AR.  The PAR MUST discard
+   the key after FMIPv6 forwarding for the previous Care-of Address
+   times out or when HK-LIFETIME expires.
+
+3.7.  Protocol Constants
+
+   The following are protocol constants with suggested defaults:
+
+   HKEPK-LIFETIME:   The maximum lifetime for the handover key
+                     encryption public key.  Default is 12 hours.
+
+   HKEPK-HANDOVERS:  The maximum number of handovers for which the
+                     handover key encryption public key should be
+                     reused.  Default is 10.
+
+   HK-LIFETIME:      The maximum lifetime for the handover key.  Default
+                     is 12 hours (43200 seconds).
+
+4.  Message Formats
+
+4.1.  Handover Key Request Option
+
+   The Handover Key Request Option is a standard IPv6 Neighbor Discovery
+   [RFC4861] option in TLV format.  The Handover Key Request Option is
+   included in the RtSolPr message along with the SEND CGA Option, RSA
+   Signature Option, and Nonce Option.
+
+    0                   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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  Pad Length   |  AT   |Resrvd.|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   .                                                               .
+   .              Handover Key Encryption Public Key               .
+   .                                                               .
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   .                                                               .
+   .                           Padding                             .
+   .                                                               .
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Kempf & Koodli              Standards Track                     [Page 8]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+
+   Fields:
+
+      Type:          27
+
+      Length:        The length of the option in units of 8 octets,
+                     including the Type and Length fields.  The value 0
+                     is invalid.  The receiver MUST discard a message
+                     that contains this value.
+
+      Pad Length:    The number of padding octets beyond the end of the
+                     Handover Key Encryption Public Key field but within
+                     the length specified by the Length field.  Padding
+                     octets MUST be set to zero by senders and ignored
+                     by receivers.
+
+      AT:            A 4-bit algorithm type field describing the
+                     algorithm used by FMIPv6 to calculate the
+                     authenticator.  See [FMIP] for details.
+
+      Resrvd.:       A 4-bit field reserved for future use.  The value
+                     MUST be initialized to zero by the sender and MUST
+                     be ignored by the receiver.
+
+      Handover Key Encryption Public Key:
+                     The handover key encryption public key.  The key
+                     MUST be formatted according to the same
+                     specification as the CGA key in the CGA Parameters
+                     Option [CGA] of the message, and MUST have the same
+                     parameters as the CGA key.
+
+      Padding:       A variable-length field making the option length a
+                     multiple of 8, containing as many octets as
+                     specified in the Pad Length field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf & Koodli              Standards Track                     [Page 9]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+4.2.  Handover Key Reply Option
+
+   The Handover Key Reply Option is a standard IPv6 Neighbor Discovery
+   [RFC4861] option in TLV format.  The Handover Key Reply Option is
+   included in the PrRtAdv message along with the SEND CGA Option, RSA
+   Signature Option, and Nonce Option.
+
+    0                   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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  Pad Length   |  AT   |Resrvd.|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Key Lifetime        |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                                                               |
+   .                                                               .
+   .                    Encrypted Handover Key                     .
+   .                                                               .
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   .                                                               .
+   .                           Padding                             .
+   .                                                               .
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Fields:
+
+      Type:          28
+
+      Length:        The length of the option in units of 8 octets,
+                     including the Type and Length fields.  The value 0
+                     is invalid.  The receiver MUST discard a message
+                     that contains this value.
+
+      Pad Length:    The number of padding octets beyond the end of the
+                     Encrypted Handover Key field but within the length
+                     specified by the Length field.  Padding octets MUST
+                     be set to zero by senders and ignored by receivers.
+
+      AT:            A 4-bit algorithm type field describing the
+                     algorithm used by FMIPv6 to calculate the
+                     authenticator.  See [FMIP] for details.
+
+
+
+
+
+
+Kempf & Koodli              Standards Track                    [Page 10]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+      Resrvd.:       A 4-bit field reserved for future use.  The value
+                     MUST be initialized to zero by the sender and MUST
+                     be ignored by the receiver.
+
+      Key Lifetime:  Lifetime of the handover key, HK-LIFETIME, in
+                     seconds.
+
+      Encrypted Handover Key:
+                     The shared handover key, encrypted with the MN's
+                     handover key encryption public key, using the
+                     RSAES-PKCS1-v1_5 format [RFC3447].
+
+      Padding:       A variable-length field making the option length a
+                     multiple of 8, containing as many octets as
+                     specified in the Pad Length field.
+
+5.  Security Considerations
+
+   This document describes a shared key provisioning protocol for the
+   FMIPv6 handover optimization protocol.  The key provisioning protocol
+   utilizes a public key generated with the same public key algorithm as
+   SEND to bootstrap a shared key for authorizing changes due to
+   handover associated with the MN's former address on the PAR.  General
+   security considerations involving CGAs apply to the protocol
+   described in this document, see [CGA] for a discussion of security
+   considerations around CGAs.  This protocol is subject to the same
+   risks from replay attacks and denial-of-service (DoS) attacks using
+   the RtSolPr as the SEND protocol [SEND] for RS.  The measures
+   recommended in RFC 3971 for mitigating replay attacks and DoS attacks
+   apply here as well.  An additional consideration involves when to
+   generate the handover key on the AR.  To avoid state depletion
+   attacks, the handover key SHOULD NOT be generated prior to SEND
+   processing that verifies the originator of RtSolPr.  State depletion
+   attacks can be addressed by techniques, such as rate limiting
+   RtSolPr, restricting the amount of state reserved for unresolved
+   solicitations, and clever cache management.  These techniques are the
+   same as used in implementing Neighbor Discovery.
+
+   For other FMIPv6 security considerations, please see the FMIPv6
+   document [FMIP].
+
+6.  IANA Considerations
+
+   IANA has assigned IPv6 Neighbor Discovery option type codes for the
+   two new IPv6 Neighbor Discovery options, the Handover Key Request
+   Option (27) and Handover Key Reply Option (28), defined in this
+   document.
+
+
+
+
+Kempf & Koodli              Standards Track                    [Page 11]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+7.  References
+
+7.1.  Normative References
+
+   [FMIP]    Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268,
+             June 2008.
+
+   [SEND]    Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+             "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+   [CGA]     Aura, T., "Cryptographically Generated Addresses (CGA)",
+             RFC 3972, March 2005.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+             "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+             September 2007.
+
+   [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+             Standards (PKCS) #1: RSA Cryptography Specifications
+             Version 2.1", RFC 3447, February 2003.
+
+7.2.  Informative References
+
+   [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
+             Neighbor Discovery (ND) Trust Models and Threats", RFC
+             3756, May 2004.
+
+   [PBK]     Bradner, S., Mankin, A., and Schiller, J., "A Framework for
+             Purpose-Built Keys (PBK)", Work in Progress, June 2003.
+             Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf & Koodli              Standards Track                    [Page 12]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+Authors' Addresses
+
+   James Kempf
+   DoCoMo Labs USA
+   3240 Hillview Avenue
+   Palo Alto, CA 94303
+   USA
+
+   Phone: +1 650 496 4711
+   EMail: kempf@docomolabs-usa.com
+
+   Rajeev Koodli
+   Starent Networks
+   30 International Place
+   Tewksbury, MA  01876
+   USA
+
+   Phone: +1 408 735 7679
+   EMail: rkoodli@starentnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf & Koodli              Standards Track                    [Page 13]
+
+RFC 5269                     FMIP Security                     June 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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.
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf & Koodli              Standards Track                    [Page 14]
+