<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> 
<!ENTITY RFC4282 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml'> 
<!ENTITY RFC4283 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4283.xml'> 
<!ENTITY RFC4346 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml'> 
<!ENTITY RFC5077 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml'> 
<!ENTITY RFC3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'> 
<!ENTITY RFC3776 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3776.xml'> 
<!ENTITY RFC4877 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml'> 
<!ENTITY RFC2818 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml'> 
<!ENTITY RFC3602 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3602.xml'> 
<!ENTITY RFC2410 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2410.xml'> 
<!ENTITY RFC2451 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2451.xml'> 
<!ENTITY RFC2404 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2404.xml'> 
<!ENTITY RFC3566 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3566.xml'> 
<!ENTITY RFC4285 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4285.xml'> 
<!ENTITY RFC4306 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'> 
<!ENTITY RFC4301 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'> 
<!ENTITY RFC4303 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml'> 
<!ENTITY RFC5246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'> 
<!ENTITY RFC3948 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3948.xml'> 
<!ENTITY RFC3344 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3344.xml'> 
<!ENTITY RFC5555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml'> 
<!ENTITY RFC5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'> 
<!ENTITY RFC3268 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3268.xml'> 
<!ENTITY RFC4648 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml'> 
<!ENTITY RFC4279 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml'> 
<!ENTITY RFC2617 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml'> 
<!ENTITY RFC4086 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml'> 
<!ENTITY RFC2616 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'> 
<!ENTITY RFC3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'> 
<!ENTITY RFC5433 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5433.xml'> 
<!ENTITY RFC5056 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'> 
<!ENTITY I-D.altman-tls-channel-bindings PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.altman-tls-channel-bindings.xml'> 

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc ipr="trust200902" category="exp" docName="draft-patil-mext-mip6issueswithipsec-04.txt"  >
   <front>
      <title abbrev="IPsec issues with Mobile IPv6">Problems with the use of IPsec as the security protocol for Mobile IPv6</title>
      <author initials="B" surname="Patil" fullname="Basavaraj Patil">
         <organization>Nokia</organization>
         <address>
        <postal>
          <street>6021 Connection Drive</street>
          <city>Irving,</city>
          <code>TX  75039</code>
          <country>USA</country>
        </postal>
        <email>basavaraj.patil@nokia.com</email>
      </address>
      </author>
      <author initials="C" surname="Perkins" fullname="Charles Perkins">
	<organization>Tellabs</organization>
	<address>
	  <postal>
	    <street>3590 N. 1st Street, Suite 300</street>
	    <city>San Jose,</city>
	    <code>CA 95134</code>
          <country>USA</country>
        </postal>
          <email>charles.perkins@tellabs.com</email>
	</address>
      </author>
      <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
         <organization>Nokia Siemens Networks</organization>
         <address>
            <postal>
               <street>Linnoitustie 6</street>
               <city>Espoo</city>
               <code>02600</code>
               <country>Finland</country>
            </postal>
            <phone>+358 (50) 4871445</phone>
            <email>Hannes.Tschofenig@gmx.net</email>
            <uri>http://www.tschofenig.priv.at</uri>
         </address>
      </author>

      <author initials="D." surname="Premec" fullname="Domagoj Premec">
         <organization>Unaffiliated</organization>
         <address>
            <postal>
               <street>Heinzelova 70a</street>
               <city>Zagreb</city>
               <code>10000</code>
               <country>Croatia</country>
            </postal>
            <email>domagoj.premec@gmail.com</email>
         </address>
      </author>


      <date year="2011"/>
      <area>Internet</area>
      <workgroup>Mobility Extensions (MEXT)</workgroup>
      <keyword>Internet-Draft</keyword>
      <keyword>Mobile IPv6</keyword>
      <keyword>Security</keyword>
      <abstract>
         <t>Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the
   signaling messages and user plane traffic between the mobile node and
   home agent.  An IPsec SA between the mobile node and the home agent
   provides security for the mobility signaling.  Use of IPsec for
   securing the data traffic between the mobile node and home agent is
   optional.  This document analyses the implications of the design
   decision to mandate IPsec as the default security protocol for Mobile
   IPv6 and consequently Dual-stack Mobile IPv6 and recommends
   revisiting this decision in view of the experience gained from
   implementation and adoption in other standards bodies. </t>
      </abstract>
   </front>

   <middle>
      <!-- ================================================================== -->

      <section anchor="introduction" title="Introduction">
         <t>Mobile IPv6 as specified in  <xref target="RFC3775"/>
   requires an IPsec 
   security association between the mobile node (MN) and home agent
   (HA).  The IPsec SA protects the mobility signaling messages between
   the MN and HA.  The user data may be optionally protected by the
   IPsec SA but is not required.  The use of IPsec by most hosts today
   is primarily as a solution for enterprise connectivity through VPN
   applications.  IPsec has not evolved into a generic security
   protocol. </t>
         <t>The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified
   in RFCs 3776 <xref target="RFC3776"/> and
   4877 <xref target="RFC4877"/>.  The Mobile IP and MIP6 
   working groups in the IETF chose to mandate IPsec as the default
   security protocol for Mobile IPv6 based on various criteria and
   lengthy discussions that occured between the years 2000 and 2004.
   Implementation experience with Mobile IPv6 and the security variants
   with which it has been specified in some SDOs indicates a need to
   revisit the design choice for MIP6 signaling security.  The analysis
   and recommendation to revisit the security protocol architecture for
   MIP6 should not be interpreted as a recommendation for Authentication
   Protocol for Mobile IPv6 <xref target="RFC4285"/>.  The objective is
   to highlight 
   the misfit of IPsec and IKEv2 as the security protocol for MIP6 and
   hence the need for considering alternatives.  A simpler security
   architecture for securing the signaling and traffic between the MN
   and HA can co-exist with the IPsec based solution as well.
         </t>
	 <t>The objective of Mobile IPv6 <xref target="RFC3775"/> is
   to enable IP mobility for 
   IPv6 hosts. The security aspect of the protocol is a critical
   component for consideration in terms of deployment and operation on
   large scales. If complexity of implementation were a consideration
   then the current specification dealing with Mobile IPv6, i.e
   RFC3775 <xref target="RFC3775"/> and RFC5555
   <xref target="RFC5555"/> would win high accolades. An implementer
   spends 
   20% of his time on implementing the Mobile IPv6 protocol and 80% of
   the time integrating it with IPsec and IKEv2. And even after that
   interoperability of the client with home agents is not
   guaranteed. The IPsec/IKEv2 security architecture may work in
   implementations wherein the OS, the IPsec/IKEv2 stack and mobile
   ipv6 client software are all implemented by a single entity. It
   just does not work on open systems. 
	 </t>
      </section>
      <!-- introduction -->

      <!-- ================================================================== -->

      <section anchor="terms" title="Terminology and Abbreviations">
         <t>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 <xref target="RFC2119"/>. </t>
         <t>This document refers to [RFC3775][RFC4877] for terminology.
         </t>
      </section>
      <!-- terminology -->

      <!-- ================================================================== -->

      <section title="Background">
         <t>IP mobility support in IPv6 was considered to be an integral feature
   of the IPv6 stack based on the experience gained from developing
   mobility support for IPv4.  The design of Mobile IPv6 was worked on
   by the Mobile IP WG in the late 90s and by the MIP6 WG until its
   publication as <xref target="RFC3775"/> in 2004.
         </t>
	 <t>IPsec [RFC4301] was also intended to be a default component of the
   IPv6 stack and was the preferred protocol choice for use by any other
   IPv6 protocol that needed security.  Rather than design security
   into every protocol feature, the intent was to reuse a well-defined
   security protocol to meet the security needs.  Hence Mobile IPv6 has
   been designed with a security architecture that relies on reusing
   IPsec.
	 </t>
	 <t>The Mobile IPv6 specification <xref target="RFC3775"/> was
   published along with the 
   companion specification "Using IPsec to Protect Mobile IPv6 Signaling
   Between Mobile Nodes and Home Agents", <xref target="RFC3776"/>.
   The establishment 
   of the IPsec SA between the MN and HA as per RFC 3776 is based on the
   use of IKE.  The use of IKE in the context of Mobile IPv6 for IPsec
   SA establishment did not gain traction because of factors such as
   complexity of IKE and the IETF transitioning to IKEv2.  The MIP6 WG
   completed the specification, Mobile IPv6 Operation with IKEv2 and the
   Revised IPsec Architecture <xref target="RFC4877"/> in April 2007.
   This <xref target="RFC4877"/> 
   is considered as the default security protocol solution for MIP6 and
	   updates <xref target ="RFC3776"/>.
	 </t>
      </section>


      <!-- ================================================================== -->

      <section title="Problem statement">
        <section title="Problem Statement">
	  <t>Mobile IPv6 is encumbered by its reliance on IPsec
   <xref target="RFC4301"/> from an 
   implementation and deployment perspective.  As a protocol solution
   for host based mobility, MIP6 can be simpler without the IPsec
   baggage.  The issues with IPsec are even more exacerbated in the case
   of dual-stack MIP6 <xref target="RFC5555"/>.	    
	  </t>
	  <t>IPsec SAs between the MN and HA are established either manually or
   via the use of IKEv2 <xref target="RFC4306"/>.  Manual SA
   configuration is not a 
   scalable solution and hence MIP6 hosts and Home agents rely on IKEv2
   for establishing dynamically IPsec SAs.  As a result MIP6 depends on
   the existence of IPsec and IKEv2 for successful operation.
	  </t>
	  <t>IPsec is unable to provide security protection for MIP6 in a
   transparent way, and numerous interactions between the host's
   security subsystems and the MIP6 application are needed in the course
   of the regular operation of the MIP6 application.  Besides requiring
   an extensive communications channel between the security subsystems
   and the MIP6 application, those interactions often also require
   modification of the MNs security subsystems code.  The situation
   today is such that the communications channel between the IPsec
   subsystems and the MIP6 application is non existent and this is
   generally true for most of the commercially available platforms.
   Even if such a channel were to be available, there does not exist a
   standardized protocol over that channel which would enable the MIP6
   application to communicate with the security modules in a non-
   implementation specific way.
	  </t>
	  <t>Considering a third party application developer who would
	  like to provide a MIP6 application for a particular
	  platform, the need for 
   numerous interactions with the IPsec subsystem and the unavailability
   of the standardized communications channel through which such
   interactions could take place is a major obstacle to the
   implementation of the mobility protocol.  Without such a
   communication channel being available it is not possible to implement
	    a MIP6 application as a third party developer. </t>

   <t>Even if the platform would provide such a communication interface for
   the MIP6 daemon, this is still insufficient as the MIP6 protocol
   standardized today <xref target="RFC3775"/> requires numerous
   changes to the host's 
   IPsec and IKEv2 implementation.  This document enumerates various
   implementation issues related to the interactions between the MIP6
   application and the host's security subsystems.</t>

   <t>An argument can be made that the MIP6 application itself should
   provide the required changes to the IPsec subsystems of the platform
   (maybe in the form of patches).  While this is possible at least for
   some open source platforms to provide modifications to the host's
   IPsec implementation as well as the key management application(s),
   this is still an issue for several reasons:
	  </t>
   <t>
     <list>
       <t>Target platform could be a commercial platform for which no source
	 code for the security modules (IPsec and IKEv2) is available.</t>
    <t>If the MIP6 application were to patch the IPsec subsystems, then
      multiple MIP6 applications from different developers would
      implement it in different ways, which would inevitably lead to
      variations and problems with interoperability at a minimum, for
      instance when the user tries to install several MIP6 applications
      it is difficult to determine which one is the best suited for his/
      her needs.</t>
    <t>Key management daemons are usually provided as third party
      software for which no source code may be available, even if the
      platform itself is available as open source.</t>
    <t>Even if the MIP6 application developer would be willing to provide
      patches for the key management daemon to make it work with his
      MIP6 application, how would the MIP6 application developer know
      which of the several available key management daemons the user is
      running?</t>
    <t>Each application would be able to work only with a single key
      management daemon, namely the one for which the MIP6 application
      provides the patches.  The user may be running another key
      management daemon and may be unwilling to change its daemon to the
      one that comes as part of the MIP6 application.</t>
     <t>Patches for the IPsec part in the kernel and the key management
      daemon would typically be valid only for the particular version of
      the kernel and the key management daemon for which they were
      written.  This might prevent the user from upgrading the
      platform or applying OS security patches that are provided as part of the
      regular platform maintenance since this would in all probability
      make the MIP6 application defunct.</t>
     <t>Modifying the security subsystems by a third party is a security
      issue and users are generally advised to refrain from allowing the
      security subsystems to be modified in any way.</t>
    <t> he developer may not have the knowledge or the time to modify the
      platform's IKEv2 and IPsec subsystems, although it might be
      perfectly capable to deliver the MIP6 application itself.</t>
     <t>There could be copyright issues as well that would prevent 
      modifications of the platform's security subsystems or the
      delivery of the modifications by the third party.</t>
     <t>Even if the MIP6 application developer is able to come up with the
      necessary patches for the security subsystem, it is not realistic
      to expect the prospective user of MIPv6 to first patch the kernel
      and the key management daemons before using the MIPv6 service.</t>
       </list>
     </t>
   <t>The above discussion shows why it is unrealistic to expect that the
   MIP6 application could provide the needed modifications to the IKEv2
   and IPsec subsystems of the host.  Section 6 presents a more
   technical discussion of various implementation issues related to the
   interworking between the MIP6 application and the IPsec/key
   management modules.</t>

   <t>The problem in a nutshell for MIP6 is the dependence on IPsec and
   IKEv2 for successful operation.
   </t>
        </section>
	
      <!-- ================================================================== -->      
      
         <section title="General issues with the use of IPsec for MIP6
			 security">
           <t>This section captures several issues with the use of
           IPsec by MIP6. 
	     </t>
	   <t>
	     <list style="numbers">
	       <t>The design of Mobile IPv6 emphasized the reuse of
        IPv6 features
        such as IPsec.  IPsec for IPv4 was a bolt-on solution.  With the
        increasing need for security, IPv6 designers chose to
        incorporate IPsec as a default feature.  There existed an
        assumption in the MIP6 working group that every IPv6 host would
        have IPsec capability as a standard feature.  While this is true
        in many host implementations today, the existence of IPsec in
        every IPv6 stack is not a given.  Hence a host which needs to
        implement Mobile IPv6 must ensure that IPsec and IKEv2 are also
        available.  As a result of this dependence, MIP6 is no longer a
        standalone host-based mobility protocol.  A good example of a
        host based mobility protocol that works as a self-sufficient
        module is Mobile IPv4 <xref target="RFC3344"/>.  The security
        associated with 
        MIP4 signaling is integrated into the protocol itself.  MIP4 has
        been successfully deployed on a large scale in several networks.
		 </t>
	       <t>IPsec use in most hosts is generally for the purpose of VPN
        connectivity to enterprises.  It has not evolved into a generic
        security protocol that can be used by Mobile IPv6 easily.  While
        <xref target="RFC4877"/> does specify the details which enable
        only the MIP6 
        signaling to be encapsulated with IPsec, the general method of
        IPsec usage has been such that all traffic between a host and
        the IPsec gateway is carried via the tunnel.  Selective
        application of IPsec to protocols is not the norm.  Use of IPsec
        with Mobile IPv6 requires configuration which in many cases is
        not easily achievable because of reasons such as enterprise
        environments preventing changes to IPsec policies.
		 </t>
	       <t>A MIP6 home agent is one end of the IPsec SA in a many-to-one
        relationship.  A MIP6 HA may support a very large number of
        mobile nodes which could be in the hundreds of thousands to
        millions.  The ability to terminate a large number of IPsec SAs
        (millions) requires signifiant hardware and platform capability.
        The cost issues of such an HA are detrimental and hence act as a
        barrier to deployment.
		 </t>
	       <t>The implementation complexity of Mobile IPv6 is greatly
        increased because of the interaction with IKEv2.  The complexity
        of the protocol implementation is even more so in the case of
        Dual stack MIP6 <xref target="RFC5555"/> wherein NAT traversal
        scenarios are considered.
		 </t>
	       <t>IPsec and IKEv2 are not implemented or available by default in
        every IPv6 or dual stack host.  Mobile IPv6 support on such
        devices is not an option.  Many low-end cellular hosts have IP
        stacks.  The need for IPsec and IKEv2 in these devices is not
        important whereas mobility support is needed in many cases.  A
        simpler security protocol than the use of IPsec/IKEv2 would make
        MIP6 much more attractive to implement and deploy.
		 </t>
	       <t><xref target="RFC4877"/> which specifies the use of
        IKEv2 and IPsec with Mobile IPv6 essentially results in a
        variant of IPsec which is specific to Mobile IP.  Hence this
        results in added complexity to implementations.
		 </t>
	       <t>Mobile IPv6 needs to be capable of being deployed in
        situations 
        where alternative security mechanisms are already well-
        understood by the network administration.  It should be possible
        to enable Mobile IPv6 to work in situations where alternative
        security mechanisms already supply the necessary authentication
        and privacy.
		 </t>
	       <t>IPsec has been successfully applied to VPN and other
        infrastructure operations, but not for general end-to-end
        applications.  Thus, the granularity for selectors was
        originally not at all sufficient for Mobile IPv6.
		 </t>
	       <t>The way that the IPsec code sits in the usual kernel, and the
        access mechanisms for the SA database, are not very convenient
        for use by straightforward implementations of Mobile IPv6.
        Unusual calling sequences and parameter passing seems to be
        required on many platforms.
		 </t>
	       <t>In certain environments the use of IPsec and IKEv2 for
        establishing the SA is considered as an overhead.  Bandwidth
        constrained links such as cellular networks and air interfaces
        which are in the licensed spectrum tend to be optimized for user
        traffic.  MIP6 signaling with the IPsec overhead and the IKEv2
        messages are viewed negatively.  It is more acceptable to have
        signaling without IPsec encapsulation.
		 </t>
	     </list>
	     </t>
	   <t>The issues listed above can be speculatively attributed as some of
   the causes for MIP6 not being implemented widely.
	     </t>
         </section>

<!-- ================================================================== -->

         <section title="Security Association Management">
            <t>Once the MN has contacted the HAC and mutual authentication has
               taken place between the MN and the HAC inside the TLS protected
               tunnel, the HAC provisions the MN with all security related
               information inside the TLS protected tunnel. This security related
               information constitutes a security association (SA) between the
               MN and the HA. The created SA MUST NOT be tied to the Care-of
               Address (CoA) of the MN.
            </t>

            <t>The HAC may proactively distribute the SA information to HAs
               under its management, or the HA may query the SA information
               from the HAC once the MN contacts the HA. If the HA queries for
               the SA information from the HAC, then the HA MUST be able to
               query/index the SA information from the HAC based on the Security
               Parameter Index (SPI).
            </t>
            <t>In certain situations, the HA may want the MN to re-establish
               the SA even if the existing SA is still valid. The HA can
               indicate this to the MN using a dedicated Status Code in a BA
               (value set to REINIT_SA_WITH_HAC). As a result, the MN would
               contact the HAC prior the SA times out, and the HAC would
               provision the MN and HAs with a new SA information.
            </t>
            <t>The SA contains at least the following information: </t>
            <t>
               <list style="hanging">
                  <t hangText="Mobility SPI:">
                     <vspace blankLines="1"/>This parameter is an SPI used by
                     the MN and the HA to index the SA between the MN and the
                     HA. The HAC is responsible for assigning SPIs to MNs.
                     There is only one SPI for both binding management messaging
                     and possible user data protection. The same SPI is used for
                     both directions between the MN and the HA. The SPI values
                     are assigned by the HAC. The HAC MUST ensure uniqueness of
                     the SPI values across all MNs controlled by the HAC.
                     <vspace blankLines="1"/>
                  </t>
                  <t hangText="MN-HA shared key for ciphering:">
                     <vspace blankLines="1"/>This parameter is a key used for ciphering Mobile IPv6
                     traffic between the MN and the HA. The HAC is responsible for generating this
                     key. The key generation algorithm is specific to the HAC implementation.
                     <vspace blankLines="1"/>
                  </t>
                  <t hangText="MN-HA shared key for integrity protection:">
                     <vspace blankLines="1"/>This parameter is a key used for
                     integrity protecting Mobile IPv6 traffic between the MN
                     and the HA. This includes both binding management messages
                     and reverse tunneled user data traffic between the MN and
                     the HA.  The HAC is responsible for generating this
                     key. The key generation algorithm is specific to the HAC
                     implementation. In case of combined algorithms a separate
                     integrity protection key is not needed and may be omitted.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Security association validity time:">
                     <vspace blankLines="1"/>This parameter represents the validity time for the
                     security association. The HAC is responsible for defining the lifetime value
                     based on its policies. The lifetime may be in the order of hours or weeks. The
                     MN MUST re-contact the HAC before the SA validity time ends.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Security Association Scope:">
                     <vspace blankLines="1"/>This parameter defines whether the
                     security association is applied to Mobile IPv6 signaling
                     messages only, or to both Mobile IPv6 signaling messages
                     and data traffic. 
                     <vspace blankLines="1"/>
                  </t>


                  <t hangText="Selected ciphersuite:">
                     <vspace blankLines="1"/>This parameter is the ciphersuite
                     used to protect the traffic between the MN and the HA.
                     This includes both binding management messages and reverse
                     tunneled user data traffic between the MN and the HA. The
                     selected algorithms SHOULD be one of the mutually supported
                     ciphersuites of the negotiated TLS version between the MN
                     and the HAC. The HAC is responsible for choosing the
                     mutually supported ciphersuite that complies with the
                     policy of the HAC. Obviously, the HAs under HAC's
                     management must have at least one ciphersuite with the HAC
                     in common and need to be aware of the implemented
                     ciphersuites.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Sequence number:">
                     <vspace blankLines="1"/>This parameter represents a monotonically increasing
                     unsigned sequence number used in all protected packets exchanged between the MN
                     and the HA. The initial sequence number MUST always be set to 0 (zero). The
                     sequence number may cycle to 0 (zero) when it increases beyond its maximum
                     defined value.
                  </t>
               </list>
            </t>

         </section>

         <section title="Bootstrapping of Additional Mobile IPv6 Parameters">
            <t>When the MN contacts the HAC to distribute of the security related               information, the HAC may also provision the MN with various Mobile
               IPv6 related bootstrapping information. Bootstrapping of the
               following information SHOULD at least be possible: </t>
            <t>
               <list style="hanging">
                  <t hangText="Home Agent IP Address:">
                     <vspace blankLines="1"/>Concerns both IPv6 and IPv4 home agent addresses.
                     <vspace blankLines="1"/>
                  </t>

                  <!-- for some odd reason folks want this feature to be removed.. -->
                  <!--t hangText="Mobile IPv6 Service Port Number:">
                     <vspace blankLines="1"/> The port number where the HA and the MN are listening
                     to UDP <xref target="RFC0768"/> packets. There is no fixed or IANA allocated
                     port number defined in this specification for Mobile IPv6. Rather, deployments
                     are free to choose any valid and available port number for their HAs and MNs.
                     <vspace blankLines="1"/>
                  </t-->

                  <t hangText="Home Address:">
                     <vspace blankLines="1"/>Concerns both IPv6 and IPv4 Home Addresses.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Home Link Prefix:">
                     <vspace blankLines="1"/>Concerns the IPv6 Home link prefix and the
                     associated prefix length.
                  </t>
               </list>
            </t>
            <t>The Mobile IPv6 related bootstrapping information is delivered from the HAC to the MN
               over the same TLS protected tunnel as the security related information. </t>
         </section>


         <section title="Protecting Traffic Between Mobile Node and Home Agent">
            <t>The same integrity and confidentiality algorithms MUST be used
               to protect both binding management messages and reverse tunneled
               user data traffic between the MN and the HA. Generally, all
               binding management messages (BUs, BAs and so on) MUST be both
               integrity and SHOULD be confidentially protected. The reverse
               tunneled user data traffic SHOULD be equivalently protected.
               Generally, the rules stated in <xref target="RFC3775"/> 
               concerning the protection of the traffic between the MN and the
               HA apply also in this specification.
            </t>
         </section>

      </section>

      <!-- OK -->

      <!-- ================================================================== -->

      <section title="Mobile Node to Home Agent Controller Communication">
        <section title="Request-response Message Framing over TLS-tunnel" anchor="record">
          <t>The MN and the HAC communicate with each other using a simple
             lock-step request-response protocol that is run directly on top
             of the TLS-tunnel. We define only one message container framing for
             the request messages and for the response messages. The
             message containers are only meant to be exchanged on top of connection
             oriented TLS-layer. Therefore, the end of message exchange is determined by the
             other end closing the transport connection (assuming the "application
             layer" has also indicated the completion of the message exchange).
             The peer initiating the TLS-connection is
             always sending "Requests" and the peer accepting the TLS-connection
             is always sending "Responses". The format of the message container
             is shown in <xref target="container"/>.
          </t>
          <t>All data inside the Content portion of the message container MUST be
             encoded using octets. Fragmentation of message containers is not supported,
             which means one request or response at the "application layer"
             MUST NOT exceed the maximum size allowed by the message container
             format.

          <figure title="Request-Response Message Container" anchor="container">
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |  Rsrvd  | Identifier    | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content portion..                                             ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          </t>
          <t>The three bit Ver field identifies the protocol version. The current
             version is 0 i.e. all bits are set to value 0 (zero).
          </t>
          <t>The Rsrvd field MUST be set to value 0 (zero),
          </t>
          <t>The Identifier field is meant for matching requests and responses. The
             valid Identifier values are between 1-255. The value 0 MUST NOT
             be used. The first request for each communication session between
             the MN and the HAC MUST have the Identifier values set to 1.
          </t>
          <t>The Length field tells the length of the Content portion of the container
             (i.e. Reserved octet, Identifier octet and Length field are excluded).
             The Content portion length MUST always be at least one octet up to 
             65535 octets. The value is in network order.
          </t>
        </section>

        <section title="Request-response Message Content Encoding">
          <t>The encoding of the message content is similar to HTTP header
             encoding, and
             complies to the augmented Backus-Naur Form (BNF) defined in
             Section 2.1 of <xref target="RFC2616"/>. All presented hexadecimal
             numbers are in network byte order. From now on, we use TypeValue
             header (TV-header) term to refer request-response message content
             HTTP-like headers.
          </t>
        </section>

        <section title="Request-Response Message Exchange">
          <t>The message exchange between the MN and the HAC is a simple lock-step
             request-response type as stated in <xref target="record"/>. A
             request message includes monotonically increasing Identifier value
             that is copied to the corresponding response message. Each request
             MUST have a different Identifier value and due the assumption of
             a reliable connection oriented transport below the message container
             framing. The number of request-response message exchanges MUST NOT
             exceed 255.
          </t>
          <t>Each new communication session between the MN and the HAC MUST
             reset the Identifier value to 1. The MN is also the peer that
             always sends only request messages and the HAC only sends
             response messages. Once the request-response message exchange 
             completes, the HAC and the MN MUST close the transport connection
             and the corresponding TLS-tunnel.
          </t>
          <t>In a case of a HAC side error, the HAC MUST send a response back
             to a MN with an appropriate status code and then close the
             transport connection.
          </t>
             
          <t>The first request message - MHAuth-Init - (i.e. the Identifier is
             1) MUST always contain at least the following parameters:
          </t>
          <t><list>
            <t>MN-Identity - See <xref target="mn-id"/>.</t>
            <t>Authentication Method - See <xref target="auth-method"/>.</t>
          </list></t>

          <t>The first response message - MHAuth-Init - (i.e. the Identifier is 1)
             MUST contain at minimum the following parameters:
          </t>
          <t><list>
            <t>Selected authentication Method - See <xref target="auth-method"/>.</t>
          </list></t>

          <t>The last request message from the MN side - MHAuth-Done -
             MUST contain the following parameters:
          </t>
          <t><list>
            <t>Security Association Scope - See <xref target="sas"/>.</t>
            <t>Proposed ciphersuites - See <xref target="ciphersuite"/>.</t>
            <t>Message Authenticator - See <xref target="msg-auth"/>.</t>
          </list></t>


          <t>The last response message  - MHAuth-Done - that ends the
             request-response message exchange MUST contain the following
             parameters:
          </t>
          <t><list>
            <t>Status Code - See <xref target="status-code"/>.</t>
            <t>Message Authenticator - See <xref target="msg-auth"/>.</t>
          </list></t>
          <t>And in a case of successful authentication the following
             additional parameters:
          </t>
          <t><list>
            <t>Selected ciphersuite - See <xref target="ciphersuite"/>.</t>
            <t>Security Association Scope - See <xref target="sas"/>.</t>
            <t>The rest of the security association data - See <xref target="httpsa"/>.</t>
          </list></t>
        </section>

        <section title="Home Agent Controller Discovery">
          <t>All bootstrapping information, whether for setting up the SA or
             for bootstrapping Mobile IPv6 specific information, is exchanged
             between the MN and the HAC using the framing protocol defined in
             <xref target="record"/>. The IP address of the HAC MAY be
             statically configured to the MN or dynamically discovered using
             for example DNS. In a case of DNS-based HAC discovery, the MN
             either queries an A/AAAA or a SRV record for the HAC IP address.
             The actual domain name used in queries is up to the deployment
             to decide and out of scope of this specification.
          </t>
        </section>
        
        <section title="Generic Request-Response Parameters">
          <section title="Mobile Node Identifier" anchor="mn-id">
            <t>An identifier that identifies a MN. The
               Mobile Node Identifier is in form of a Network Access
               Identifier (NAI) <xref target="RFC4282"/>.
            </t>
            <t><list>
              <t>mn-id = "mn-id" ":" nai CRLF
              <vspace/>
              nai = username
              <vspace/>&nbsp;&nbsp;&nbsp;
              | "@" realm
              <vspace/>&nbsp;&nbsp;&nbsp;
              | username "@" realm 
              <vspace/>
              ...
              
              </t>
            </list></t>
          </section>

          <section title="Authentication Method" anchor="auth-method">
            <t>The HAC is the peer that mandates the used authentication method.
               The MN sends its proposal to the HAC but eventually the used
                authentication method returned from the HAC defines
                the one to be used. The MN MUST propose at least one authentication
                method and it SHOULD propose more than one. The HAC MUST
                select exactly one authentication method, or return an error and
                then close the connection.
            </t>
            <t><list>
              <t>auth-method = "auth-method" ":" a-method *("," a-method) CRLF
              <vspace/>
              a-method =
              <vspace/>&nbsp;&nbsp;&nbsp;&nbsp;
              "psk" ; Pre-sharer key based authentication
              <vspace/>&nbsp;&nbsp;
              | "eap" ; EAP-based authentication
              </t>
            </list></t>
          </section>

          <section title="Extensible Authentication Protocol Payload" anchor="eap-payload">
            <t>Each Extensible Authentication Protocol (EAP) <xref target="RFC3748"/>
               message is encoded string of hexadecimal numbers. The "eap-payload"
               is completely transparent what EAP-method or EAP message is 
               carried inside it. The "eap-payload" can appear in both request
               and response messages:
            </t>
            <t><list>
              <t>eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF</t>
            </list></t>
          </section>

          <section title="Status Code" anchor="status-code">
            <t>The "status-code" MUST only be present in the response message
               that ends the request-response message exchange. The "status-code"
               follows the principles of HTTP and the definitions found in
               Section 10 of RFC 2616 also apply for these status codes listed
               below:
            </t>
            <t><list>
              <t>status-code = "status-code" ":" status-value CRLF
              <vspace/>
              status-value =
              <vspace/>&nbsp;&nbsp;&nbsp;&nbsp;
              "100"  ; Continue
              <vspace/>&nbsp;&nbsp;
              | "200" ; OK
              <vspace/>&nbsp;&nbsp;
              | "400"  ; Bad Request
              <vspace/>&nbsp;&nbsp;
              | "401"  ; Unauthorized
              <vspace/>&nbsp;&nbsp;
              | "500"  ; Internal Server Error
              <vspace/>&nbsp;&nbsp;
              | "501"  ; Not Implemented
              <vspace/>&nbsp;&nbsp;
              | "503"  ; Service Unavailable
              <vspace/>&nbsp;&nbsp;
              | "504"  ; Gateway Time-out
              </t>
            </list></t>
          </section>

          <section title="Message Authenticator" anchor="msg-auth">
            <t>The "auth" header contains data
               used for authentication purposes. It MUST be the
               last TV-header in the message and calculated over
               the whole message till the start of the "msg-header":
            </t>
            <t><list>
              <t>msg-auth = "auth" ":" 1*(HEX HEX) CRLF</t>
            </list></t>
          </section>
          <section title="Retry After" anchor="retry-after">
            <t><list>
              <t>reply-after = "retry-after" ":" rfc1123-date CRLF</t>
            </list></t>
          </section>
          <section title="End of Message Content" anchor="eof">
            <t><list>
              <t>end-of-message = 2CRLF</t>
            </list></t>
          </section>

          <section title="Random Values" anchor="rand">
            <t>Random number generated by the MN or the HAC. The length of
               the random number MUST be 32 octets (before TV-header 
               encoding):
            </t>

            <t><list>
              <t>mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF</t>
              <t>hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF</t>
            </list></t>
          </section>
        </section>
        
        
        <!-- section 5.6 -->
        <section title="Security Association Configuration Parameters" anchor="httpsa">
          <t>During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate
             a single ciphersuite for protecting the traffic between the MN and
             the HA. The allowed ciphersuites for this specification are a
             subset of those in TLS v1.2 (see Annex A.5 of <xref target="RFC5246"/>)
             as per <xref target="ciphersuite"/>. This might appear as a
             constraint as the HA and the HAC may have implemented different
             ciphersuites. These two nodes are, however, assumed to belong to
             the same administrative domain. In order to avoid exchanging
             supported MN-HA ciphersuites in the MN-HAC protocol and to reuse
             the TLS ciphersuite negotiation procedure we make this simplifying
             assumption. The selected ciphersuite MUST provide integrity and
             confidentially protection.
          </t>
          <t><xref target="ciphersuite"/> provides the mapping from  the TLS
             ciphersuites to the integrity and encryption algorithms allowed
             for MN-HA protection. This mapping mainly ignores the
             authentication algorithm part that is not required within the
             context of this specification. For example, <xref target="RFC3268"/>
             defines a number of AES based ciphersuites for TLS including
             'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification the
             relevant part is 'AES_128_CBC_SHA'. 
          </t>
          <t>All the parameters described in the following sections apply only
             to a request-response protocol response message to the MN. The MN has
             no way affecting to the provisioning decision of the HAC.
          </t>


          <section title="Security Parameter Index" anchor="spi">
            <t>The 28-bit unsigned SPI number identifies the SA used between
               the MN and the HA. The value 0 (zero) is reserved and MUST NOT
               be used. Therefore, values ranging from 1 to 268435455 are valid.
            </t>
            <t>The TV-header corresponding to the SPI number is:
            </t>
            <t><list>
              <t>mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF</t>
              </list>
            </t>
          </section>

          <section title="MN-HA Shared Keys" anchor="mnhakey">
               <t>The MN-HA shared integrity (ikey) and encryption (ekey) keys
                  are used to protect the traffic between
                  the MN and the HA. The length of these keys depend on the
                  selected ciphersuite.
               </t>
               <t>The TV-headers that carry these two parameters are: </t>
               <t>
                  <list>
                     <t>mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF</t>
                     <t>mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF</t>
                     <t>mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF</t>
                     <t>mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF</t>
                  </list>
               </t>

          </section>

          <section title="Security Association Validity Time" anchor="salifetime">
               <t>The end of the SA validity time is encoded using the "rfc1123-date" format, as
                  defined in Section 3.3.1 of <xref target="RFC2616"/>. </t>
               <t>The TV-header corresponding to the SA validity time value is: </t>
               <t>
                  <list>
                     <t>mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date CRLF</t>
                  </list>
               </t>
          </section>

          <section title="Security association scope (SAS)" anchor="sas">
               <t>The SA is applied either to Mobile IPv6 signaling messages
                   only, or to both Mobile IPv6 signaling messages and data
                   traffic. This parameter MUST be agreed between the MN and HA
                   prior to using the SA. Otherwise the receiving side would not
                   be aware of whether the SA applies to data traffic and could
                   not decide how to act when receiving unprotected packets of
                   PType 1 (see <xref target="dtamsg"/>).
               </t>
               <t>
                  <list>
                     <t>mip6-sas = "mip6-sas" ":" 1DIGIT CRLF</t>
                  </list>
               </t>
               <t>where a value of “0” indicates that the SA does not protect
                  data traffic and a value of “1” indicates that all data
                  traffic MUST be protected by the SA. If the mip6-sas value of
                  an SA is set to 1, any packet with PType = 0 MUST be silently
                  discarded when received.
               </t>
               <t>The HAC is the peer that mandates the used security association
                  scope. The MN sends its proposal to the HAC but eventually
                  the security association scope returned from the HAC defines
                  the used scope.
               </t>
          </section>




          <section title="CipherSuites and Ciphersuite-to-Algorithm Mapping" anchor="ciphersuite">
               <t>The ciphersuite negotiation between HAC and MN uses a subset
                  of the TLS 1.2 ciphersuites and follows  the TLS 1.2 numeric
                  representation defined in Annex A.5 of <xref target="RFC5246"/>.
                  The TV-headers corresponding to the selected
                  ciphersuite and ciphersuite list are:
               </t>
               <t>
                  <list>
                     <t>mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF
                     <vspace/>
                     csuite = "{" suite "}"
                     <vspace/>
                     suite =
                     <vspace/>&nbsp;&nbsp;&nbsp;&nbsp;
                       "00" "," "02" ; CipherSuite NULL_SHA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = {0x00,0x02}
                     <vspace/>&nbsp;&nbsp;
                     | "00" "," "3B" ; CipherSuite NULL_SHA256&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = {0x00,0x3B}
                     <vspace/>&nbsp;&nbsp;
                     | "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA&nbsp;&nbsp; = {0x00,0x0A}                     <vspace/>&nbsp;&nbsp;
                     | "00" "," "2F" ; CipherSuite AES_128_CBC_SHA&nbsp;&nbsp;&nbsp; = {0x00,0x2F}                     <vspace/>&nbsp;&nbsp;
                     | "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C}                     </t>                     
                     <t>mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF
                     </t>
                  </list>
               </t>
               <!--t>The following ciphersuites are defined:
               <figure>
                  <artwork><![CDATA[ 
   CipherSuite NULL_SHA            = { 0x00,0x02 };   CipherSuite NULL_SHA256         = { 0x00,0x3B };   CipherSuite 3DES_EDE_CBC_SHA    = { 0x00,0x0A };   CipherSuite AES_128_CBC_SHA     = { 0x00,0x2F };   CipherSuite AES_128_CBC_SHA256  = { 0x00,0x3C };		 ]]></artwork>
               </figure>
               </t-->
               <t>
                  All other Ciphersuite values are reserved and subject to future
                  specifications.
               </t>
               <t>The following integrity algorithms MUST be supported by all
                  implementations: 
               <figure>
                  <artwork><![CDATA[    HMAC-SHA1-96                    [RFC2404]   AES-XCBC-MAC-96                 [RFC3566]		 ]]></artwork>
               </figure>
               </t>
               <t>The binding management messages between the MN and HA MUST be
                  integrity protected. Implementations MUST NOT use a NULL
                  integrity algorithm.
               </t>
               <t>The following encryption algorithms MUST be supported:
               <figure>
                  <artwork><![CDATA[    NULL                            [RFC2410]   TripleDES-CBC                   [RFC2451]   AES-CBC with 128-bit keys       [RFC3602]		 ]]></artwork>
               </figure>
               </t>
               <t>Traffic between MN and HA MAY be encrypted. Any
                  integrity-only CipherSuite makes use of the NULL encryption
                  algorithm.
               </t>               <t>Note: In the present version, this document does not consider
                  combined algorithms. The following table provides the mapping
                  of each ciphersuite to a combination of integrity and
                  encryption algorithms that are part of the negotiated SA
                  between MN and HA.

               <figure title="Ciphersuite-to-Algorithm Mapping">
                  <artwork><![CDATA[ 
+-------------------+-----------------+--------------------------+|Ciphersuite        |Integ. Algorithm |Encr. Algorithm           |
+-------------------+-----------------+--------------------------+|NULL_SHA           |HMAC-SHA1-96     |NULL                      ||NULL_SHA256        |AES-XCBC-MAC-96  |NULL                      ||3DES_EDE_CBC_SHA   |HMAC-SHA1-96     |TripleDES-CBC             ||AES_128_CBC_SHA    |HMAC-SHA1-96     |AES-CBC with 128-bit keys ||AES_128_CBC_SHA256 |AES-XCBC-MAC-96  |AES-CBC with 128-bit keys |
+-------------------+----------------+---------------------------+		 ]]></artwork>
               </figure>
               </t>
          </section>
       </section>


       <section title="Mobile IPv6 Bootstrapping Parameters" anchor="httpmip">
            <t>In parallel with the SA bootstrapping, the HAC SHOULD provision
               the MN with relevant Mobile IPv6 related bootstrapping
               information.
            </t>
            <t>The following generic BNFs are used to form IP addresses and
               prefixes. They are used in subsequent sections.
               <figure>
                  <artwork><![CDATA[ 
   ip6-addr   = 7( word ":" ) word CRLF
   word       = 1*4HEX
   ip6-prefix = ip6-addr "/" 1*2DIGIT
   ip4-addr   = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
		 ]]></artwork>
               </figure>
            </t>

          <section title="Home Agent Address">
               <t>The HAC MAY provision the MN with an IPv4 or an IPv6 address of a HA, or both. </t>
               <t>
                  <list>
                     <t>mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF</t>
                     <t>mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF</t>
                  </list>
               </t>
          </section>

          <!-- dynamic port allocation replaced by IANA defined fixed port.. -->
          <!--section title="Mobile IPv6 Service Port Number">
               <t>The HAC SHOULD provision the MN with an UDP port number. The port number is used
                  by the MNs and the HAs as the UDP destination port number when they initiate
                  messages towards each other. </t>
               <t>
                  <list>
                     <t>mip6-port = "mip6-port" ":" 1*5DIGIT CRLF</t>
                  </list>
               </t>
          </section-->


          <section title="Home Addresses and Home Network Prefix">
               <t>The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or both. The
                  HAC MAY also provision the MN with its home network prefix.
               </t>
               <t>
                  <list>
                     <t>mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF</t>
                     <t>mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF</t>
                     <t>mip6-hnp-ip6 = "mip6-ip6-hnp" ":" ip6-prefix CRLF</t>
                  </list>
               </t>
          </section>
       </section>

       <section title="Authentication of the Mobile Node">
         <t>This section describes the basic operation required for the MN-HAC            mutual authentication and the channel binding.  The authentication            protocol described as part of this section is a simple exchange that            follows the GPSK exchange used by EAP-GPSK <xref target="RFC5433"/>.
            It is secured by the TLS tunnel and is cryptographically bound to
            the TLS tunnel through channel binding based on <xref target="RFC5056"/>
            and on the channel binding type 'tls-server-endpoint' described in
            <xref target="I-D.altman-tls-channel-bindings"/>. As a result of
            the channel binding type, this method can only be used with TLS
            ciphersuites that use server certificates and the Certificate
            handshake message. For example, TLS ciphersuites based on PSK or
            anonymous authentication cannot be used.
         </t>
         <t>The authentication exchange MUST be performed through the encrypted
            TLS tunnel. It performs mutual authentication between the MN and
            the HAC based on a pre-shared key (PSK) or based on an EAP-method
            (see <xref target="eap-method"/>).  The PSK protocol is described
            in this section. It consists of the message exchanges (MHAuth-Init,
            MHAuth-Mid, MHAuth-Done) in which both sides exchange nonces and
            their identities, and compute and exchange
            a message authenticator 'auth' over the previously exchanged
            values, keyed with the pre-shared key.  The MHAuth-Done messages
            are used to deal with error situations. Key binding with the TLS
            tunnel is ensured by channel binding of the type "tls-server-endpoint"
            as described by <xref target="I-D.altman-tls-channel-bindings"/>
            where the hash of the TLS server certificate serves as input to
            the 'auth' calculation of the MHAuth messages.
         </t>         <t>Note: The authentication exchange is based on the GPSK exchange
            used by EAP-GPSK. In comparison to GPSK, it does not support
            exchanging an encrypted container (it always runs through an
            already protected TLS tunnel). Furthermore, the initial request
            of the authentication exchange (MHAuth-Init) is sent by the MN
            (client side) and is comparable to EAP-Response/Identity, which
            reverses the roles of request and response messages compared to
            EAP-GPSK. <xref target="psk"/> shows a successful protocol
            exchange.
         </t>
         <t>
         <figure title="Authentication of the Mobile Node Using Shared Secrets" anchor="psk">
         <artwork><![CDATA[
MN                                                      HAC
 |                                                       |
 | Request/MHAuth-Init (...)                             |
 |------------------------------------------------------>|
 |                                                       |
 |                            Response/MHAuth-Init (...) |
 |<------------------------------------------------------|
 |                                                       |
 | Request/MHAuth-Done (...)                             |
 |------------------------------------------------------>|
 |                                                       |
 |                            Response/MHAuth-Done (...) |
 |<------------------------------------------------------|
 |                                                       |
]]></artwork>
          </figure>
          </t>

          <t><list style="format %d)">
          <t>Request/MHAuth-Init: (MN -> HAC)
             <list style="empty">                <t>mn-id, mn-rand, auth-method=psk</t>
             </list>
             <vspace blankLines="1"/>
          </t>
          <t>Response/MHAuth-Init: (MN &lt;- HAC)
            <list style="empty">
                <t>[mn-rand, hac-rand, auth-method=psk, [status],] auth</t>
             </list>
             <vspace blankLines="1"/>
          </t>
          <t>Request/MHAuth-Done: (MN -> HAC)
             <list style="empty">
                <t>mn-rand, hac-rand, sa-scope, ciphersuite-list, auth</t>
             </list>
             <vspace blankLines="1"/>
          </t>
          <t>Response/MHAuth-Done: (MN &lt;- HAC)
             <list style="empty">
                <t>[sa-scope, sa-data, ciphersuite, bootstrapping-data,]
                   mn-rand, hac-rand, status, auth</t>
             </list>
          </t>
          </list>
          </t>

          <t>Where:</t>
          <t>
             <list>
                <t>auth = HMAC-SHA256(PSK, msg-octets | CB-octets)</t>
             </list>
          </t>          <t>The length "mn-rand", "hac-rand" is 32 octets. Note that "|"
              indicates concatenation and optional parameters are shown in
              square brackets [..]. The square brackets can be nested.
          </t>          <t>The shared secret PSK can be variable length. 'msg-octets'
             includes all payload parameters of the respective message to be
             signed except the 'auth' payload. CB-octets is the channel binding
             input to the auth calculation that is the "TLS-server-endpoint"
             channel binding type. The content and algorithm (only required
             for the "TLS-server-endpoint" type) are the same as described in
             <xref target="I-D.altman-tls-channel-bindings"/>.
          </t>
          <t>The MN starts by selecting a random number 'mn-rand' and choosing
             a list of supported authentication methods coded in 'auth-method'.
             The MN sends its identity 'mn-id', 'mn-rand' and 'auth-method' to
             the HAC in MHAuth-Init. The decision of which authentication method
             to offer and  which to pick is policy- and implementation-dependent
             and, therefore, outside the scope of this document.
          </t>
          <t>In MHAuth-Done, the HAC sends a random
             number 'hac-rand' and the selected ciphersuite. The
             selection MUST be one of the MN-supported ciphersuites as received
             in 'ciphersuite-list'. Furthermore, it repeats the received parameters
             of the MHAuth-Init message 'mn-rand'. It
             computes a message authenticator 'auth' over all the transmitted
             parameters except 'auth' itself. The HAC calculates 'auth' over all
             parameters and appends it to the message.
          </t>
          <t>The MN verifies the received MAC and the consistency of the
             identities, nonces, and ciphersuite parameters transmitted in
             MHAuth-Auth. In case of successful verification, the MN computes
             a MAC over the session parameter and returns it to the HAC in
             MHAuth-Done. The HAC verifies the received MAC and the consistency
             of the identities, nonces, and ciphersuite parameters transmitted
             in MHAuth-Init.  If the verification is successful, MHAuth-Done
             is prepared and sent by the HAC to confirm successful completion
             of the exchange.
         </t>
       </section>

       <section title="Extensible Authentication Protocol Methods" anchor="eap-method">
         <t>Basic operation required for the MN-HAC mutual authentication 
            using EAP-based methods.
         </t>

         <figure title="Authentication of the Mobile Node Using EAP" anchor="eap">
         <artwork><![CDATA[
MN                                                      HAC
 |                                                       |
 | Request/MHAuth-Init (...)                             |
 |------------------------------------------------------>|
 |                                                       |
 |                            Response/MHAuth-Init (..., |
 |                     eap-payload=EAP-Request/Identity) |
 |<------------------------------------------------------|
 |                                                       |
 | Request/MHAuth-Mid (eap-payload=                      | 
 |              EAP-Response/Identity)                   |
 |------------------------------------------------------>|
 |                                                       |
 |     Response/MHAuth-Mid (eap-payload=EAP-Request/...) |
 |<------------------------------------------------------|
 |                                                       |
 :                                                       :
 :        ..EAP-method specific exchanges..              :
 :                                                       :
 |                                                       |
 | Request/MHAuth-Done (eap-payload=EAP-Response/...,    |
 |                      ..., auth)                       |
 |------------------------------------------------------>|
 |                                                       |
 |        Response/MHAuth-Done (eap-payload=EAP-Success, |
 |                              ..., auth)               |
 |<------------------------------------------------------|
 |                                                       |
]]></artwork>
          </figure>
          <t><list style="format %d)">
          <t>Request/MHAuth-Init: (MN -> HAC)
             <list style="empty">                <t>mn-id, mn-rand, auth-method=eap</t>
             </list>
             <vspace blankLines="1"/>
          </t>
          <t>Response/MHAuth-Init: (MN &lt;- HAC)
            <list style="empty">
                <t>[auth-method=eap, eap, [status,]] auth</t>
             </list>
             <vspace blankLines="1"/>
          </t>
          <t>Request/MHAuth-Mid: (MN –> HAC)
            <list style="empty">
                <t>eap, auth</t>
             </list>
             <vspace blankLines="1"/>
          </t>
          <t>Response/MHAuth-Mid: (MN &lt;- HAC)
            <list style="empty">
                <t>eap, auth</t>
             </list>
             <vspace blankLines="1"/>
             MHAuth-Mid exchange is repeated as many times as needed by the used
             EAP-method.
             <vspace blankLines="1"/>
          </t>
          <t>Request/MHAuth-Done: (MN -> HAC)
             <list style="empty">
                <t>sa-scope, ciphersuite-list, eap, auth</t>
             </list>
             <vspace blankLines="1"/>
          </t>
          <t>Response/MHAuth-Done: (MN &lt;- HAC)
             <list style="empty">
                <t>[sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, status, auth</t>
             </list>
          </t>
          </list>
          </t>

          <t>Where:</t>
          <t>
             <list>
                <t>auth = HMAC-SHA256(shared-key, msg-octets | CB-octets)</t>
             </list>
          </t>          <t>In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1".
             If the EAP-method is key-deriving and creates a shared MSK key as
             a side effect of Authentication shared-key MUST be the MSK in all
             MHAuth-Done messages.  This MSK MUST NOT be used for any other
             purpose. In case the EAP method does not generate an MSK key,
             shared-key is set to "1".
          </t>
          <t>'msg-octets'
             includes all payload parameters of the respective message to be
             signed except the 'auth' payload. CB-octets is the channel binding
             input to the AUTH calculation that is the "TLS-server-endpoint"
             channel binding type. The content and algorithm (only required
             for the "TLS-server-endpoint" type) are the same as described in
             <xref target="I-D.altman-tls-channel-bindings"/>.
          </t>



       </section>
     </section>


     <section title="Mobile Node to Home Agent communication">
       <section title="General" anchor="packets">
            <t>The following sections describe the packet formats used for the traffic between the
               MN and the HA. This traffic includes binding management messages (for example, BU
               and BA messages), reverse tunneled and encrypted user data, and reverse tunneled
               plain text user data. This specification defines a generic packet format, where
               everything is encapsulated inside UDP. See <xref target="bmmmsg"/> and <xref
                  target="dtamsg"/> for detailed illustrations of the corresponding packet formats.
            </t>
            <!-- fix the ha service port number.. -->
            <t>The Mobile IPv6 service port number (HALTSEC), where the HA expects to receive UDP
               packets, is reserved by IANA. The same
               port number is used for both binding management messages and user data packets. The
               reason for multiplexing data and control messages over the same port number is due to
               the possibility of Network Address and Port Translators located along the path
               between the MN and the HA. The Mobile IPv6 service MAY use any ephemeral port number
               as the UDP source port, and MUST use the Mobile IPv6 service port number (HALTSEC)
               as the UDP destination port.
            </t>
            <t>The encapsulating UDP header is immediately followed by a 4-bit
               Packet Type (PType) field that defines whether the packet
               contains an encrypted mobility management message or a, an encrypted
               user data packet, or a plain text user data packet.
            </t>
            <t>The Packet Type field is followed by a 28-bit SPI value, which
               identifies the correct SA concerning the encrypted packet. For
               any packet that is neither integrity protected nor encrypted (i.e.
               no SA is applied by the originator) the SPI MUST be set to 0
               (zero). ). Mobility management messages MUST always be at least
               integrity protected. Hence, mobility management messages MUST
               NOT be sent with a SPI value of 0 (zero).   
            </t>
            <t>There is always only one SPI per MN-HA mobility session and the
               same SPI is used for all types of protected packets independent
               of the direction.
            </t>
            <t>The SPI value is followed by a 32-bit Sequence Number value that
               is used to identify retransmissions of encrypted messages. Each
               endpoint in the security association maintains two "current"
               Sequence Numbers: the next one to be used for a packet it 
               initiates and the next one it expects to see in a packet from
               the other end. If the MN and the HA ends initiate very different
               numbers of messages, the Sequence Numbers in the two directions
               can be very different. In a case encryption is not used, the
               Sequence Number MUST be set to 0 (zero). Note that the HA SHOULD
               initiate a re-establishement of the SA before any of the Sequence
               Number cycle.
            </t>
            <t>Finally, the Sequence Number field is followed by the data
               portion, whose content is identified by the Packet Type. The
               data portion may be protected.
            </t>
        </section>
        <section title="Security Parameter Index">
          <t>The SPI is a 32-bit field, where the first 4 bits indicate the
             Packet Type (PType) of the UDP encapsulated packet. The SPI value
             itself consists of the remaining 28-bit of the SPI field. The SPI
             field is treated as one 32-bit field during the integrity
             protection calculation.

          <figure title="Security Parameter Index with Packet Type" anchor="spifig">
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType |                        SPI                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
             A SPI value of 0 (zero) indicates a plaintext packet. If the
             packet is integrity protected or both integrity protected and
             encrypted, the SPI value MUST be different from 0.
          </t>
        </section>

        <section title="Binding Management Message Formats" anchor="bmmmsg">
               <t>The binding management messages that are only meant to be
                  exchanged between the MN and the HA MUST be integrity
                  protected and MAY be encrypted. They MUST use the packet
                  format shown in <xref target="ptype8"/>. All packets that are
                  specific to the Mobile IPv6 protocol and contain a Mobility
                  Header (as defined in Section 6.1.1. of RFC 3775) SHOULD
                  use the packet format shown in <xref target="ptype8"/>.
                  (This means that some Mobile IPv6 mobility management
                  messages, such as the HoTI message, as treated as
                  data packets and using encapsulation described in
                  <xref target="dtamsg"/>).
               </t>
               <t>
                  <figure title="UDP Encapsulated Binding Management Message Format" anchor="ptype8">
                     <artwork><![CDATA[
 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |:         IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya)        :|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |:            UDP header (src-port=Xp,dst-port=Yp)               :|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------|PType=8|                    SPI                                | ^Int.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-|                      Sequence Number                          | |ered+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----|                    Payload Data* (variable)                   | |   ^:                                                               : |   ||                                                               | |Conf.+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-|               |     Padding (0-255 bytes)                     | |ered*+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   ||                               |  Pad Length   | Next Header   | v   v+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------|         Integrity Check Value-ICV   (variable)                |:                                                               :|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
                  </figure>
               </t>
               <t>The PType value 8 (eight) identifies that the UDP encapsulated
                  packet contains a RFC 3775 defined Mobility Header and other
                  relevant IPv6 extension headers. Note, there is no additional
                  IP header inside the encapsulated part. The Next Header field
                  MUST be set to value of the first encapsulated header. The
                  encapsulated headers follow the natural IPv6 and Mobile IPv6
                  extension header alignment and formatting rules.
               </t>
               <t>The Padding, Pad Length, Next Header and ICV fields follow
                  the rules of Section 2.4 to 2.8 of <xref target="RFC4303"/> unless
                  otherwise stated in this document. For a SPI value of 0 (zero)
                  that indicates an unprotected packet, the Padding, Pad Length,
                  Next Header and ICV fields MUST NOT be present.
               </t>
               <t>The source and destination IP addresses of the outer IP header
                  (i.e. the src-addr and the dst-addr in <xref target="ptype8"/>)
                  use the current care-of address of the MN and the HA address.
               </t>
        </section>

        <section title="Reverse Tunneled User Data Packet Formats" anchor="dtamsg">
               <t>There are two types of reverse tunneled user data packets
                  between the MN and the HA. Those that are integrity protected
                  and encrypted and those that are plaintext. The MN or the HA
                  decide whether to apply integrity protection and encryption
                  to a packet or to send it in plaintext based on the mip6-sas
                  value in the SA. If the mip6-sas is set to 1 the originator
                  MUST NOT send any plaintext packet, and the receiver MUST
                  silently discard any packet with the PType set to 0
                  (unprotected). It is RECOMMENDED to apply confidentiality and
                  integrity protection of user data traffic. The reverse
                  tunneled IPv4 or IPv6 user data packets are encapsulated
                  as-is inside the 'Payload Data' shown in <xref target="ptype1"/>.
                  and <xref target="ptype0"/>.
             <figure
                     title="UDP Encapsulated Protected User Data Packet Format" anchor="ptype1">
                     <artwork><![CDATA[
 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |:         IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya)        :|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |:            UDP header (src-port=Xp,dst-port=Yp)               :|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|PType=1|                    SPI                                | ^Int.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-|                      Sequence Number                          | |ered+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----|                    Payload Data* (variable)                   | |   ^:                                                               : |   ||                                                               | |Conf.+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-|               |     Padding (0-255 bytes)                     | |ered*+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   ||                               |  Pad Length   | Next Header   | v   v+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------|         Integrity Check Value-ICV   (variable)                |:                                                               :|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
                  </figure>
               </t>
               <t>The PType value 1 (one) identifies that the UDP encapsulated
                  packet contains an encrypted tunneled IPv4/IPv6 user data
                  packet. The Next Header field header MUST be set to value
                  corresponding the tunneled IP packet (e.g., 41 for IPv6).
               </t>
               <t>The Padding, Pad Length, Next Header and ICV fields follow
                  the rules of Section 2.4 to 2.8 of <xref target="RFC4303"/> unless
                  otherwise stated in this document. For a SPI value of 0 (zero)
                  that indicates an unprotected packet, the Padding, Pad Length,
                  Next Header and ICV fields MUST NOT be present.
               </t>
               <t>The source and destination IP addresses of the outer IP header
                  (i.e., the src-addr and the dst-addr in
                  <xref target="ptype1"/>) use the current care-of address of
                  the MN and the HA address. The ESP protected inner IP header,
                  which is not shown in <xref target="ptype1"/>, uses the home
                  address of the MN and the correspondent node (CN) address.
               </t>
               <t>
                  <figure title="UDP Encapsulated Non-Protected User Data Packet Format"
                     anchor="ptype0">
                     <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:         IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya)        :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:            UDP header (src-port=Xp,dst-port=Yp)               :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=0|                        0                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                0                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:           Payload Data (plain IPv4 or IPv6 Packet)            :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
                  </figure>
               </t>
               <t>The PType value 0 (zero) identifies that the UDP encapsulated
                  packet contains a plaintext tunneled IPv4/IPv6 user data
                  packet. Also the SPI and the Sequence Number fields MUST be
                  set to 0 (zero).
               </t>
               <t>The source and destination IP addresses of the outer IP header
                  (i.e., the src-addr and the dst-addr in
                  <xref target="ptype0"/>) use the current care-of address of
                  the MN and the HA address. The plain text inner IP header
                  uses the home address of the MN and the CN address.
               </t>
       </section>
   </section>


   <section title="Route Optimization" anchor="ro">
            <t>The treatment of MN-CN route optimization is outside the scope of this document.
            </t>
   </section>

      <!-- ================================================================== -->

     <section title="IANA Considerations">
       <section title="New Registry: Packet Type">
            <t>IANA is requested to create a new registry for the Packet Type as described in <xref
                  target="packets"/>. <figure>
                  <artwork><![CDATA[
Packet Type                       | Value
----------------------------------+----------------------------------
non-encrypted IP packet           | 0
encrypted IP packet               | 1
mobility header                   | 8
           ]]></artwork>
               </figure>
            </t>
            <t>Following the allocation policies from <xref target="RFC5226"/> new values for the
               Packet Type AVP MUST be assigned based on the "RFC Required" policy. </t>
       </section>
       <section title="HTTP Headers">
            <t>A number of HTTP headers with their respective parameters are reserved. See <xref
                  target="httpsa"/> and <xref target="httpmip"/> for a list of header names and
               their parameters. </t>
       </section>
       <section title="Status Codes">
            <t>A new Status Code (to be used in BA messages) is reserved for the
               cases where the HA wants to indicate to the MN that it needs to
               re-establish the SA information with the HAC. The Result Code is
               reserved from the 0-127 code space:
               <figure>
                  <artwork><![CDATA[
    REINIT_SA_WITH_HAC       TBD1
           ]]></artwork>
               </figure>
            </t>
       </section>
       <section title="Port Numbers">
       <t>A new port number (HALTSEC) for UDP packets is reserved from the PORT NUMBERS registry.
               <figure>
                  <artwork><![CDATA[
    HALTSEC                  TBD2
           ]]></artwork>
               </figure>
       
       </t>
       </section>
     </section>

      <!-- ================================================================== -->

     <section title="Security Considerations">

         <t>This document describes and uses a number of building blocks that
            introduce security mechanisms and need to interwork in a secure
            manner.
         </t>
         <t> The following building blocks are considered from a security
             point of view:
         </t>
         <t>
            <list style="numbers">
               <t>Discovery of the HAC </t>
               <t>Authentication and MN-HA SA establishment executed between
                  the MN and the HAC (PSK or EAP-based) through a TLS tunnel</t>
               <t>Protection of MN-HA communication </t>
               <t>AAA Interworking </t>
            </list>
         </t>

         <section title="Discovery of the HAC">
            <t>No dynamic procedure for discovering the HAC by the MN is
               described in this document.  As such, no specific security
               considerations apply to the scope of this document.
            </t>
         </section>
         <section
            title="Authentication and Key Exchange executed between the MN
            and the HAC">

            <t>This document describes a simple authentication and MN-HA SA
               negotiation exchange over TLS. The TLS procedures remain
               unchanged; however, channel binding is provided.
            </t>
            <t>
               <list style="hanging">
                  <t hangText="Authentication:"> Server-side certificate based
                     authentication MUST be performed  using TLS 1.2
                     <xref target="RFC5246"/>.
                     <vspace blankLines="1"/>
                     The client-side authentication may depend on the
                     specific deployment and is therefore not mandated. Note
                     that TLS-PSK <xref target="RFC4279"/> cannot be used in
                     conjunction with the methods described in section 5.8 and
                     5.9 of this document due to the limitations of the channel
                     binding type used.
                     <vspace blankLines="1"/>
                     Through the protected TLS tunnel, an additional
                     authentication exchange is performed that provides
                     client-side or mutual authentication and exchanges SA
                     parameters and optional configuration data to be used in
                     the subsequent protection of MN-HA communication. The
                     additional authentication exchange can either be PSK-based
                     (section 5.8) or EAP-based (section 5.9). Both exchanges
                     are always performed within the protected TLS tunnel and
                     MUST NOT be used as standalone protocols.                     <vspace blankLines="1"/>
                     The simple PSK-based authentication exchange provides
                     mutual authentication and follows the GPSK exchange used
                     by EAP-GPSK <xref target="RFC5433"/> and has similar
                     properties, although some features of GPSK like the
                     exchange of a protected container are not supported.                     <vspace blankLines="1"/>
                     The EAP-based authentication exchange simply defines
                     message containers to allow carrying the EAP packets
                     between the MN and the HAC. In principle, any EAP method
                     can be used. However, it is strongly recommended to use
                     only EAP methods that provide mutual authentication and
                     that derive keys including an MSK key in compliance with
                     <xref target="RFC3748"/>.                     <vspace blankLines="1"/>
                     Both exchanges use channel binding with the TLS tunnel.
                     The channel binding type ‘TLS-server-endpoint’ as per
                     <xref target="I-D.altman-tls-channel-bindings"/> MUST be
                     used.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Dictionary Attacks:">All messages of the
                     authentication exchanges specified in this document are
                     protected by TLS. However, any implementation SHOULD assume
                     that the properties of the authentication exchange are the
                     same as for GPSK <xref target="RFC5433"/> in case the
                     PSK-based method as per section 5.8. is used, and are the
                     same as those of the underlying EAP method in case the
                     EAP-based exchange as per section 5.9 is used.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Replay Protection:">The underlying TLS protection
                     provides protection against replays.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Key Derivation and Key Strength:">For TLS, the
                     TLS specific considerations apply unchanged. For the
                     authentication exchanges defined in this document, no key
                     derivation step is performed as the MN-HA keys are
                     generated by the HAC and are distributed to the MN through
                     the secure TLS connection.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Key Control:">No joint key control for MN-HA keys
                     is provided by this version of the specification.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Lifetime:"> The TLS-protected authentication
                     exchange between the MN and the HAC is only to
                     bootstrap keys and other parameters for usage with MN-HA
                     security. The SAs that contain the keys have an associated
                     lifetime. The usage of Transport Layer Security (TLS)
                     Session Resumption without Server-Side State,
                     described in <xref target="RFC5077"/>, provides the ability
                     for the MN to minimize the latency of future exchanges
                     towards the HA without having to keep state at the HA
                     itself.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Denial of Service Resistance:"> The level of
                     resistance against denial of service attacks SHOULD be
                     considered the same as for common TLS operation, as TLS
                     is used unchanged. For the PSK-based authentication
                     exchange, no additional factors are known. For the
                     EAP-based authentication exchange, any considerations
                     regarding denial-of-service resistance specific to the
                     chosen EAP method are expected to be applicable and need
                     to be be taken into account.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Session Independence:"> Each individual TLS
                     protocol run is independent from any previous exchange
                     based on the security properties of the TLS handshake
                     protocol. However, several PSK or EAP-based authentication
                     exchanges can be performed across the same TLS connection.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Fragmentation:">TLS runs on top of TCP and no
                     fragmentation specific considerations apply to the MN-HAC
                     authentication exchanges.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Channel Binding:">Both the PSK and the EAP-based
                     exchanges use channel binding with the TLS tunnel. The
                     channel binding type ‘TLS-server-endpoint’ as per
                     <xref target="I-D.altman-tls-channel-bindings"/> MUST be
                     used.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Fast Reconnect:"> This protocol provides session
                     resumption as part of TLS and optionally the support for
                     <xref target="RFC5077"/>. No fast reconnect is supported
                     for the PSK-based authentication exchange. For the
                     EAP-based authentication exchange, availability of fast
                     reconnect depends on the EAP method used.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Identity Protection:">Based on the security
                     properties of the TLS tunnel, passive user identity
                     protection is provided. An attacker acting as
                     man-in-the-middle in the TLS connection would be able to
                     observe the MN identity value sent in MHAuth-Init messages.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Protected Ciphersuite Negotiation:"> This protocol provides
                     ciphersuite negotiation based on TLS.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Confidentiality:"> Confidentiality protection of
                     payloads exchanged between the MN and the HAC are protected
                     with the TLS Record Layer. TLS ciphersuites with
                     confidentiality and integrity protection MUST be negotiated
                     and used in order to exchange security sensitive material
                     inside the TLS connection.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Cryptographic Binding:"> No cryptographic bindings are provided by
                     this protocol specified in this document.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Perfect Forward Secrecy:"> Perfect forward secrecy is provided with
                     appropriate TLS ciphersuites.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Key confirmation:"> Key confirmation of the keys established with TLS
                     is provided by the TLS Record Layer when the keys are used to protect the
                     subsequent TLS exchange.
                     <vspace blankLines="1"/>
                  </t>
               </list>
            </t>
         </section>

         <section title="Protection of MN and HA Communication">

            <t>
               <list style="hanging">

                  <t hangText="Authentication:"> Data origin authentication is provided for the
                     communication between the MN and the HA. The chosen level of security of this
                     authentication depends on the selected ciphersuite. Entity authentication is
                     offered by the MN to HAC protocol exchange.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Dictionary Attacks:"> The concept of dictionary attacks is not
                     applicable to the MN-HA communication as the keying material used for this
                     communication is randomly created by the HAC and its length depends on the
                     chosen cryptographic algorithms.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Replay Protection:"> Replay protection for the communication between
                     the MN and the HA is provided based on sequence numbers and follows the design
                     of IPsec ESP.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Key Derivation and Key Strength:"> The strength of the keying
                     material established for the communication between the MN and the HA is
                     selected based on the negotiated ciphersuite (based on the MN-HAC exchange) and
                     the key created by the HAC. The randomness requirements for security described
                     in RFC 4086 <xref target="RFC4086"/> are applicable to the key generation by
                     the HAC.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Key Control:"> The keying material established during the MN-HAC
                     protocol exchange for subsequent protection of the MN-HA communication is
                     created by the HA and therefore no joint key control is provided for it.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Key Naming:"> For the MN-HA communication the security associations
                     are indexed with the help of the SPI and additionally based on the direction
                     (in-bound communication or out-bound communication).
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Lifetime:"> The lifetime of the MN-HA security associations is based
                     on the value in the mip6-sa-validity-end HTTP header field exchanged during the
                     MN-HAC exchange. The HAC controls the SA lifetime.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Denial of Service Resistance:"> For the communication between the MN
                     and the HA there are no heavy cryptographic operations (such as public key
                     computations). As such, there are no DoS concerns.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Session Independence:"> Sessions are independent from each other when
                     new keys are created by via the MN-HAC protocol. A new MN-HAC protocol run
                     produces fresh and unique keying material for protection of the MN-HA
                     communication.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Fragmentation:"> There is no additional fragmentation support
                     provided beyond what is offered by the network layer.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Channel Binding:"> Channel binding is not applicable to the MN-HA
                     communication.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Fast Reconnect:"> The concept of fast reconnect is not applicable to
                     the MN-HA communication.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Identity Protection:"> User identities SHOULD NOT be exchanged between
                     the MN and the HA. In a case binding management messages contain
                     the user identity, the messages SHOULD be confidentity protected.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Protected Ciphersuite Negotiation:"> The MN-HAC
                     protocol provides protected ciphersuite negotiation through
                     a secure TLS connection.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Confidentiality:"> Confidentiality protection of payloads exchanged
                     between the MN and the HAC (for Mobile IPv6 signaling and optionally for the
                     data traffic) is provided utilizing algorithms
                     negotiated during the MN-HAC exchange.
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Cryptographic Binding:"> No cryptographic bindings are provided by
                     this protocol specified in this document.
                     <vspace blankLines="1"/>
                  </t>


                  <t hangText="Perfect Forward Secrecy:"> Perfect forward secrecy is provided when
                     the MN bootstraps new keying material with the help of the MN-HAC protocol
                     (assuming that a proper TLS ciphersuite is used).
                     <vspace blankLines="1"/>
                  </t>

                  <t hangText="Key confirmation:"> Key confirmation of the MN-HA keying material
                     conveyed from the HAC to the MN is provided when the first packets are
                     exchanged between the MN and the HA (in both directions as two different keys
                     are used).
                  </t>
               </list>
            </t>
         </section>


         <section title="AAA Interworking">
            <t> The AAA backend infrastructure interworking is not defined in this document and
               therefore out-of-scope. </t>
         </section>


      </section>

      <!-- ================================================================== -->

      <section title="Acknowledgements">
         <t>The authors would like to thank Pasi Eronen, Domagoj Premec, and Christian Bauer for
            their comments.</t>
      </section>

      <!-- ================================================================== -->

   </middle>

   <!-- ================================================================== -->

   <back>
      <references title="Normative References">
         &RFC2119;
         &RFC3775;
         &RFC5246;
         &RFC5226;
         &RFC2616;
         &RFC5056;
         &RFC4282;
         
         &RFC2404;
         &RFC3566;
         &RFC2410;
         &RFC2451;
         &RFC3602;
&RFC4285;
         &I-D.altman-tls-channel-bindings;
      </references>

      <references title="Informative References">
         &RFC4301;
         &RFC4303;
         &RFC4306;
         &RFC3776;
         &RFC4877;
         &RFC3344;
         &RFC5555;
<!--         &I-D.patil-mext-mip6issueswithipsec; -->
         &RFC3268;
         &RFC4279;
         &RFC4086;
         &RFC5077;
         &RFC3748;
         &RFC5433;
      </references>
   </back>
</rfc>
