Skip to main content

Mobile IPv6 Bootstrapping in Split Scenario
draft-ietf-mip6-bootstrapping-split-07

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5026.
Authors James Kempf , Gerardo Giaretta , Vijay Devarapalli
Last updated 2015-10-14 (Latest revision 2007-07-25)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5026 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Jari Arkko
Send notices to (None)
draft-ietf-mip6-bootstrapping-split-07
>

                                AAA request
                                (FQDN, HoA)
                              <-------------->

                                               DNS update
                                              <----------->
                                AAA answer
                                (FQDN, HoA)
                              <-------------->
         BA (DNS update option)
       <-----------------------

   Notice that, even in this last case, the Home Agent is always
   required to perform a DNS update for the reverse entry, since this is
   always performed in the DNS server of the MSP.  This is not depicted
   in the figure above.

8.  Option and Attribute Format

8.1.  DNS Update mobility 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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  Option Type  | Option Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Status      |R|  Reserved   |     MN identity (FQDN) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 17]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

   Option Type

      DNS-UPDATE-TYPE to be defined by IANA

   Option Length

      8-bit unsigned integer indicating the length of the option
      excluding the type and length fields

   Status

      8-bit unsigned integer indicating the result of the dynamic DNS
      update procedure.  This field MUST be set to 0 and ignored by the
      receiver when the DNS Update mobility option is included in a
      Binding Update message.  When the DNS Update mobility option is
      included in the Binding Acknowledgement message, values of the
      Status field less than 128 indicate that the dynamic DNS update
      was performed successfully by the Home Agent.  Values greater than
      or equal to 128 indicate that the dynamic DNS update was not
      completed by the HA.  The following Status values are currently
      defined:

         0 DNS update performed

         128 Reason unspecified

         129 Administratively prohibited

         130 DNS Update Failed

   R flag

      If set the Mobile Node is requesting the HA to remove the DNS
      entry identified by the FQDN specified in this option and the HoA
      of the Mobile Node.  If not set, the Mobile Node is requesting the
      HA to create or update a DNS entry with its HoA and the FQDN
      specified in the option

   Reserved

      MUST be set to 0

   MN identity

      The identity of the Mobile Node in FQDN format to be used by the
      Home Agent to send a Dynamic DNS update.  It is a variable length
      field

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 18]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

8.2.  MIP6_HOME_PREFIX attribute

   The MIP6_HOME_PREFIX attribute is carried in IKEv2 Configuration
   Payload messages.  This attribute is used to convey the home prefix
   from which the Mobile Node auto-configures its home address.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|      Attribute Type         |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Prefix Lifetime                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                         Home Prefix                           |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Prefix Length |
    +-+-+-+-+-+-+-+-+

   Reserved (1 bit)

      This bit MUST be set to zero and MUST be ignored on receipt

   Attribute Type (15 bits)

      A unique identifier for the MIP6_HOME_PREFIX attribute.  To be
      assigned by IANA

   Length (2 octets)

      Length in octets of Value field (Home Prefix, Prefix Lifetime and
      Prefix Length).  This can be 0 or 21

   Prefix Lifetime (4 octets)

      The lifetime of the Home Prefix

   Home Prefix (16 octets)

      The prefix of the home link through which the Mobile Node may
      auto-configure its Home Address

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 19]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

   Prefix Length (1 octet)

      The length in bits of the home prefix specified in the field Home
      Prefix

   When the MIP6_HOME_PREFIX attribute is included by the Mobile Node in
   the CFG_REQUEST payload, the value of the Length field is 0.  When
   the MIP6_HOME_PREFIX attribute is included in the CFG_REPLY payload
   by the Home Agent, the value of the Length field is 21 and the
   attribute contains also the home prefix information.

9.  Security Considerations

9.1.  HA Address Discovery

   Use of DNS for address discovery carries certain security risks.  DNS
   transactions in the Internet are typically done without any
   authentication of the DNS server by the client or of the client by
   the server.  There are two risks involved:

   1.  A legitimate client obtains a bogus Home Agent address from a
       bogus DNS server.  This is sometimes called a "pharming" attack,

   2.  An attacking client obtains a legitimate Home Agent address from
       a legitimate server.

   The risk in Case 1 is mitigated because the Mobile Node is required
   to conduct an IKE transaction with the Home Agent prior to performing
   a Binding Update to establish Mobile IPv6 service.  According to the
   IKEv2 specification [5], the responder must present the initiator
   with a valid certificate containing the responder's public key, and
   the responder to initiator IKE_AUTH message must be protected with an
   authenticator calculated using the public key in the certificate.
   Thus, an attacker would have to set up both a bogus DNS server and a
   bogus Home Agent, and provision the Home Agent with a certificate
   that a victim Mobile Node could verify.  If the Mobile Node can
   detect that the certificate is not trustworthy, the attack will be
   foiled when the Mobile Node attempts to set up the IKE SA.

   The risk in Case 2 is limited for a single Mobile Node to Home Agent
   transaction if the attacker does not possess proper credentials to
   authenticate with the Home Agent.  The IKE SA establishment will fail
   when the attacking Mobile Node attempts to authenticate itself with
   the Home Agent.  Regardless of whether the Home Agent utilizes EAP or
   host-side certificates to authenticate the Mobile Node, the
   authentication will fail unless the Mobile Node has valid
   credentials.

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 20]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

   Another risk exists in Case 2 because the attacker may be attempting
   to propagate a DoS attack on the Home Agent.  In that case, the
   attacker obtains the Home Agent address from the DNS, then propagates
   the address to a network of attacking hosts that bombard the Home
   Agent with traffic.  This attack is not unique to the bootstrapping
   solution, however, it is actually a risk that any Mobile IPv6 Home
   Agent installation faces.  In fact, the risk is faced by any service
   in the Internet that distributes a unicast globally routable address
   to clients.  Since Mobile IPv6 requires that the Mobile Node
   communicate through a globally routable unicast address of a Home
   Agent, it is possible that the Home Agent address could be propagated
   to an attacker by various means (theft of the Mobile Node, malware
   installed on the Mobile Node, evil intent of the Mobile Node owner
   him/herself, etc.) even if the home address is manually configured on
   the Mobile Node.  Consequently, every Mobile IPv6 Home Agent
   installation will likely be required to mount anti-DoS measures.
   Such measures include overprovisioning of links to and from Home
   Agents and of Home Agent processing capacity, vigilant monitoring of
   traffic on the Home Agent networks to detect when traffic volume
   increases abnormally indicating a possible DoS attack, and hot spares
   that can quickly be switched on in the event an attack is mounted on
   an operating collection of Home Agents.  DoS attacks of moderate
   intensity should be foiled during the IKEv2 transaction.  IKEv2
   implementations are expected to generate their cookies without any
   saved state, and to time out cookie generation parameters frequently,
   with the timeout value increasing if a DoS attack is suspected.  This
   should prevent state depletion attacks, and should assure continued
   service to legitimate clients until the practical limits on the
   network bandwidth and processing capacity of the Home Agent network
   are reached.

   Explicit security measures between the DNS server and host, such
   DNSSEC [19] or TSIG/TKEY [20] [21] can mitigate the risk of 1) and
   2), but these security measures are not widely deployed on end nodes.
   These security measures are not sufficient to protect the Home Agent
   address against DoS attack, however, because a node having a
   legitimate security association with the DNS server could
   nevertheless intentionally or inadvertently cause the Home Agent
   address to become the target of DoS.

   Finally notice that assignment of an home agent from the serving
   network access provider's (local home agent) or a home agent from a
   nearby network (nearby home agent) may set up the potential to
   compromise a mobile node's location privacy.  A home address anchored
   at such home agent contains some information about the topological
   location of the mobile node.  Consequently, a mobile node requiring
   location privacy should not disclose this home address to nodes that
   are not authorized to learn the mobile node's location, e.g., by

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 21]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

   updating DNS with the new home address.

   Security considerations for discovering HA using DHCP are covered in
   [22].

9.2.  Home Address Assignment through IKEv2

   Mobile IPv6 bootstrapping assigns the home address through the IKEv2
   transaction.  The Mobile Node can either choose to request an
   address, similar to DHCP, or the Mobile Node can request a prefix on
   the home link then auto-configure an address.

   RFC 3775 [1] requires that a Home Agent check authorization of a home
   address received during a Binding Update.  Therefore, the home agent
   MUST authorize each home address allocation and use.  This
   authorization is based on linking the mobile node identity used in
   the IKEv2 authentication process and the home address.  Home agents
   MUST implement at least the following two modes of authorization:

   o  Configured home address(es) for each mobile node.  In this mode,
      the home agent or infrastructure nodes behind it know what
      addresses a specific mobile node is authorized to use.  The mobile
      node is allowed to request these addresses, or if the mobile node
      requests any home address, these addresses are returned to it.

   o  First-come-first-served (FCFS).  In this mode, the home agent
      maintains a pool of "used" addresses, and allows mobile nodes to
      request any address, as long as it is not used by another mobile
      node.

   Addresses MUST be marked as used for at least as long as the binding
   exists, and are associated with the identity of the mobile node that
   made the allocation.

   In addition, the home agent MUST ensure that the requested address is
   not the authorized address of any other mobile node, if both FCFS and
   configured modes use the same address space.

9.3.  SA Establishment Using EAP Through IKEv2

   Security considerations for authentication of the IKE transaction
   using EAP are covered in [3] .

9.4.  Back End Security Between the HA and AAA Server

   Some deployments of Mobile IPv6 bootstrapping may use an AAA server
   to handle authorization for mobility service.  This process has its
   own security requirements, but the back end protocol for Home Agent

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 22]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

   to AAA server interface is not covered in this draft.  Please see
   [16] for a discussion of this interface.

9.5.  Dynamic DNS Update

   If a Home Agent performs dynamic DNS update on behalf of the Mobile
   Node directly with the DNS server, the Home Agent MUST have a
   security association of some type with the DNS server.  The security
   association MAY be established either using DNSSEC [19] or TSIG/TKEY
   [20][21].  A security association is REQUIRED even if the DNS server
   is in the same administrative domain as the Home Agent.  The security
   association SHOULD be separate from the security associations used
   for other purposes, such as AAA.

   In the case where the Mobility Service Provider is different from the
   Mobility Service Authorizer, the network administrators may want to
   limit the number of cross-administrative domain security
   associations.  If the Mobile Node's FQDN is in the Mobility Service
   Authorizer's domain, since a security association for AAA signaling
   involved in mobility service authorization is required in any case,
   the Home Agent can send the Mobile Node's FQDN to the AAA server
   under the HA-AAA server security association, and the AAA server can
   perform the update.  In that case, a security association is required
   between the AAA server and DNS server for the dynamic DNS update.
   See [16] for a deeper discussion of the Home Agent to AAA server
   interface.

   Regardless of whether the AAA server or Home Agent performs DNS
   update, the authorization of the Mobile Node to update a FQDN MUST be
   checked prior to the performance of the update.  It is an
   implementation issue as to how authorization is determined.  However,
   in order to allow this authorization step, the Mobile Node MUST use a
   FQDN as the IDi in IKE_AUTH step of the IKEv2 exchange.  The FQDN
   MUST be the same as the FQDN that will be provided by the Mobile Node
   in the DNS Update Option.

   In case EAP over IKEv2 is used to set-up the IPsec SA, the Home Agent
   gets authorization information about the Mobile Node's FQDN via the
   AAA back end communication performed during IKEv2 exchange.  The
   outcome of this step will give the Home Agent the necessary
   information to authorize the DNS update request of the Mobile Node.
   See [16] for details about the communication between the AAA server
   and the Home Agent needed to perform the authorization.

   In case certificates are used in IKEv2, the authorization information
   about the FQDN for DNS update MUST be present in the certificate
   provided by the Mobile Node.  Since the IKEv2 specification does not
   include a required certificate type, it is not possible to specify

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 23]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

   precisely how the Mobile Node's FQDN should appear in the
   certificate.  However, as an example, if the certificate type is
   "X.509 Certificate - Signature" (one of the recommended types) then
   the FQDN may appear in the subjectAltName attribute extension [23].

10.  IANA Considerations

   This document defines a new Mobility Option and a new IKEv2
   Configuration Attribute Type.

   The following values should be assigned:

   o  from "Mobility Option" namespace ([1]): DNS-UPDATE-TYPE
      (Section 8.1)

   o  from "IKEv2 Configuration Payload Attribute Types" namespace
      ([5]): MIP6_HOME_PREFIX attribute (Section 8.2)

   o  from "IKEv2 Notify Payload Error Types" namespace ([5]):
      USE_ASSIGNED_HoA error type (Section 5.3.2)

11.  Contributors

   This contribution is a joint effort of the bootstrapping solution
   design team of the MIP6 WG.  The contributors include Basavaraj
   Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, Gopal
   Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal
   Chowdury, Julien Bournelle.

   The design team members can be reached at:

      Gerardo Giaretta gerardog@qualcomm.com

      Basavaraj Patil basavaraj.patil@nokia.com

      Alpesh Patel alpesh@cisco.com

      Jari Arkko jari.arkko@kolumbus.fi

      James Kempf kempf@docomolabs-usa.com

      Yoshihiro Ohba yohba@tari.toshiba.com

      Gopal Dommety gdommety@cisco.com

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 24]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

      Alper Yegin alper.yegin@samsung.com

      Vijay Devarapalli vijay.devarapalli@azairenet.com

      Kuntal Chowdury kchowdury@starentnetworks.com

      Junghoon Jee jhjee@etri.re.kr

      Julien Bournelle julien.bournelle@gmail.com

12.  Acknowledgements

   The authors would like to thank Rafa Lopez, Francis Dupont, Jari
   Arkko, Kilian Weniger, Vidya Narayanan, Ryuji Wakikawa, Michael Ye
   for their valuable comments.

13.  References

13.1.  Normative References

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

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
         IKEv2 and the Revised IPsec Architecture", RFC 4877,
         April 2007.

   [4]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [5]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
         RFC 4306, December 2005.

   [6]   Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
         April 1997.

13.2.  Informative References

   [7]   Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
         Mobile IPv6 (MIPv6)", RFC 4640, September 2006.

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 25]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

   [8]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

   [9]   Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet
         X.509 Public Key Infrastructure Certificate Management Protocol
         (CMP)", RFC 4210, September 2005.

   [10]  Korver, B., "The Internet IP Security PKI Profile of IKEv1/
         ISAKMP, IKEv2, and PKIX",
         draft-ietf-pki4ipsec-ikecert-profile-12 (work in progress),
         February 2007.

   [11]  Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
         draft-ietf-ipv6-2461bis-11 (work in progress), March 2007.

   [12]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         RFC 3972, March 2005.

   [13]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [14]  Droms, R., "DNS Configuration options for Dynamic Host
         Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
         December 2003.

   [15]  Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
         Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-04 (work in
         progress), June 2007.

   [16]  Giaretta, G., "AAA Goals for Mobile IPv6",
         draft-ietf-mip6-aaa-ha-goals-03 (work in progress),
         September 2006.

   [17]  Chowdhury, K., "RADIUS Mobile IPv6 Support",
         draft-ietf-mip6-radius-02 (work in progress), March 2007.

   [18]  Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support",
         draft-ietf-dime-mip6-split-02 (work in progress), May 2007.

   [19]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "DNS Security Introduction and Requirements", RFC 4033,
         March 2005.

   [20]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
         "Secret Key Transaction Authentication for DNS (TSIG)",
         RFC 2845, May 2000.

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 26]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

   [21]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
         RFC 2930, September 2000.

   [22]  Jang, H., "DHCP Option for Home Information Discovery in
         MIPv6", draft-ietf-mip6-hiopt-05 (work in progress), June 2007.

   [23]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

Authors' Addresses

   Gerardo Giaretta
   Qualcomm

   Email: gerardog@qualcomm.com

   James Kempf
   DoCoMo Labs USA
   181 Metro Drive
   San Jose, CA  95110
   USA

   Email: kempf@docomolabs-usa.com

   Vijay Devarapalli
   Azaire Networks
   3121 Jay Street
   Santa Clara, CA  95054
   USA

   Email: vijay.devarapalli@azairenet.com

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 27]
Internet-Draft    MIP6 Bootstrapping in split scenario         July 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Giaretta, Ed., et al.   Expires January 23, 2008               [Page 28]