One document matched: draft-moskowitz-hip-fast-mobility-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="std" docName="draft-moskowitz-hip-fast-mobility-01.txt" ipr="trust200902">

<front>
<title abbrev="Fast HIP Mobility">Fast HIP Host Mobility</title>
	<author fullname="Robert Moskowitz" initials="R" surname="Moskowitz">
    <organization>Huawei</organization>
    <address>
      <postal> 
	    <street></street>
        <city>Oak Park</city>
        <region>MI</region>
        <code>48237</code>
        <country>USA</country>
      </postal>
      <email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Xiaohu Xu" initials="X." surname="Xu">
	<organization>Huawei</organization>
	<address>
	  <postal>
	    <street>Huawei Bld, No.156 Beiqing Rd.</street>
	    <city>Beijing</city>
	    <region>Hai-Dian District</region>
	    <code>100095</code>
	    <country>China</country>
	  </postal>
	  <email>xuxiaohu@huawei.com</email>
	</address>
	</author>
	<author fullname="Bingyang Liu" initials="B." surname="Liu">
	<organization>Huawei</organization>
	<address>
	  <postal>
	    <street>Huawei Bld, No.156 Beiqing Rd.</street>
	    <city>Beijing</city>
	    <region>Hai-Dian District</region>
	    <code>100095</code>
	    <country>China</country>
	  </postal>
	  <email>xuxiaohu@huawei.com</email>
	</address>
	</author>
<date year="2016" />
   <area>Internet</area>
   <workgroup>HIP</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>HIP</keyword>
<abstract>
<t>
	This document describes mobility scenarios and how to aggressively 
	support them in HIP.  The goal is minimum lag in the mobility 
	event.
</t>
</abstract>
</front>
<middle>   
<section title="Introduction">
<t> 
	This document expands on <xref 
	target="I-D.ietf-hip-rfc5206-bis">HIP Host Mobility</xref> to 
	describe a set of mobility scenarios that can be addressed by 
	mechanisms that accelerate the basic HIP mobility UPDATE exchange.
</t> 
<t> 
	<xref target="I-D.ietf-hip-rfc5206-bis">HIP Host Mobility</xref> 
	performs a return address validation to ensure that the UPDATE 
	address is reachable by the peer.  Two reasons are given for this 
	approach: middleboxes blocking return reachablity and malicious 
	peers providing false address updates to flood a target.
</t> 
<t> 
	The approach here is to start using the new address while it is 
	being validated.  Worst case is a few packets are lost or sent to a 
	wrong target.  These are acceptable risks while gaining a fast 
	address update that works in most cases.
</t> 
<t>
	One mechanism used is to piggyback data using Next Header even 
	while the mobile peer address is flagged UNVERIFIED.  This is 
	practical as the new peer address is authenticated by the HIP_MAC 
	in UPDATE.  The UPDATE can neither be forged nor can it be 
	replayed.  The verification is more to ensure reverse reachability 
	particularly across NATs and firewalls.
</t>
<t>
	Another mechanism expands the use of the VIA_RVS parameter to 
	"shotgun" mobility UPDATEs.  These and other optimizations will be 
	covered in detail.
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
	<section title="Requirements Terminology">
	<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">RFC 2119</xref>.
	</t>
	</section>
	<section title="Definitions">
	<t>
		<list style="hanging">
		<t hangText="IPnHIP:">
			The short name for IP-within-IP managed by HIP.
		</t>
		<t hangText="MTU:">
			The Maximum Transmit Unit or maximum number of bytes in a 
			datagram that the Interface supports.
		</t>
		<t hangText="SPI:">
			The Security Parameter Index.
		</t>
		</list>
	</t>
	</section>
</section>
<section anchor="prob-space" title="Problem Space">
<section title="Time to complete move">
<t>
	Most mobility environments are built with a "break then make" model 
	for connectivity.  Thus there is measurable time between the old 
	address being unusable and the new address being functional. Adding 
	mobility convergence times just further aggravates the delay which 
	negatively impacts the user experience.
</t>
<t>
	The "make then break" model for connectivity is supported via HIP 
	multihoming and is the subject of a separate recommendation.
</t>
<t>
	HIP mobility relies on a 3 packet UPDATE exchange which in some 
	cases can be optimized to 2 packets.  This can be further delayed 
	in a "double-jump" scenario with waiting for the direct connection 
	to fail before falling over to contacting the peer's RVS.  These 
	processes have resulted in other technologies to be preferred over 
	HIP as they have faster convergence even if they achieve this while 
	sacrificing security.
</t>
</section>
<section title="Apriori move knowledge">
<t>
	A HIP Host that has the potential to 'move' (acquire a new address 
	for an interface) during the lifetime of a HIP association SHOULD 
	be registered to an RVS.  Such a HIP host SHOULD always inform its 
	peer of its RVS address, as it may experience a "Double-Jump" move 
	as in <xref target="dMov" />.
</t>
<t>
	In an RVS assisted base exchange, the Responder ensures the 
	Initiator knows its RVS with the VIA_RVS parameter in the R1 as 
	specified in <xref target="RFC8004">HIP Rendezvous 
	Extension</xref>.  However, the Responder has no mechanism to learn 
	the Initiator's RVS address.  Additionally, it is possible for an 
	Initiator to directly contact the Responder and thus not learn about 
	the Responder's RVS in the base exchange.
</t>
<t>
	A host may not publish its RVS if it does not wish to be easily 
	discovered.  It still should notify its peers of its RVS if it 
	expects to be found in some move scenarios.
</t>
<t>
	The HIP base exchange needs to include more RVS information.
</t>
</section>
</section>
<section anchor="vRVS" title="Enhanced availability of VIA_RVS">
<t>
	The VIA_RVS parameter is defined in <xref 
	target="RFC8004">HIP Rendezvous Extension</xref> 
	for use in R1, but only identifies the Responder's RVS to the 
	Initiator when the I1 was routed through the RVS.
</t>
<t>
	Firstly, a Responder SHOULD always provide its VIA_RVS information 
	in R1 even when the I1 came directly from the Initiator.  Secondly, 
	the Initiator SHOULD always provide its VIA_RVS information in I2.  
	The VIA_RVS address is always maintained as part of the HIT to IP 
	addressing information.  Through these two expansions in the 
	availability of VIA_RVS, the hosts are assured to possess their 
	peer's RVS address to "shotgun" UPDATEs and thus accelerate 
	mobility.
</t>
</section>
<section anchor="sMov" title="Single move mobility">
<t>
	Data traffic between host A and B may use <xref 
	target="RFC7402">ESP with HIP</xref>, <xref 
	target="RFC2004">IPnIP</xref>, <xref 
	target="I-D.moskowitz-hip-ipnhip">IPnHIP</xref> or any other 
	tunneling protocol.  If ESP, or to some extent IPnHIP, the 
	relationship of the tunnel SAs with the HIP SA puts a high level of 
	trust on the following fast mobility.  With IPnIP, the risk is 
	similar to MIPv6. Adding a MAC of the IPnIP or IPnHIP datagram into 
	the HIP UPDATE as in <xref target="IPnHIP" /> adds an additional 
	level of validation during the fast mobility.
</t>
<section title="Piggybacking impact on transport window size">
<t>
	The following sections define the operation of a HIP UPDATE payload 
	followed by some transport (e.g. TCP or UDP) payload in a single IP 
	datagram.  This multicontent IP datagram works best with a smaller 
	window size for the higher layer.  The normal operation is to 
	compare the size of the transport datagram plus HIP UPDATE payload 
	and ensure it is less than the MTU.  An implementation may be able 
	to adjust the transport window size downward so that the higher 
	layer could still fill it and the whole piece then still fit within 
	the MTU.
</t>
</section>
<section title="Environment">
<t>
	<list style="symbols">
		<t>
			Host A is mobile.
		</t>
		<t>
			Host B may be mobile, but not changing IP address at this time.
		</t>
		<t>
			Only Host A is moving in the network and changing its IP address.
		</t>
		<t>
			Host A and B share a HIP Security Association.
		</t>
		<t>
			Host A and B are registered to a RVS server, not 
			necessarily the same and each has the others RVS address.
		</t>
	</list>
	
</t>
</section>
<section anchor="SubA" title="Scenario 1: Neither host has data to transmit">
<t>
	Host A triggers a HIP mobility UPDATE with Locator to inform Host B 
	of new address.  Host B, upon validating Host A HIP UPDATE, 
	continues with Address Verification.
</t>
</section>
<section title="Scenario 2: Host A has data to transmit">
<section title="IPv6 datagram + HIP UPDATE > MTU">
<t>
	Host A triggers a HIP mobility UPDATE with Locator to inform Host B 
	of new address.  As the UPDATE + datagram would exceed the MTU, the 
	datagram is sent separately after receipt of the HIP UPDATE from 
	Host B.
</t>
<t>
	The HIP UPDATE packets vary in length as follows:
</t>
	<t>
		<list style="hanging">
		<t hangText="Move notification:">
			302 bytes - UPDATE(ESP_INFO, LOCATOR, SEQ, HMAC, HIP_SIGNATURE)
		</t>
		<t hangText="Move verification:">
			286 bytes - UPDATE(ESP_INFO, SEQ, ACK, HMAC, HIP_SIGNATURE, ECHO_REQUEST_UNSIGNED)
		</t>
		<t hangText="Verification ack:">
			262 bytes - UPDATE(ESP_INFO, ACK, HMAC, HIP_SIGNATURE, ECHO_RESPONSE_UNSIGNED)
		</t>
		</list>
	</t>
</section>
<section title="IPv6 datagram + HIP UPDATE <= MTU">
<t>
	Host A sends HIP UPDATE with Locator to inform Host B of new 
	address.  Datagram is appended to HIP UPDATE using Next Header. 
	Host B, upon validating Host A HIP UPDATE, sends next header to 
	proper module and continues with Address Verification.  This 
	datagram is processed even though the address is UNVERIFIED.
</t>
<t>
	The ESP and IPnHIP anti-replay window managed by their envelope 
	sequence number can protect against replayed UPDATE+ESP packets 
	prior to address verification.
</t>
</section>
</section>
<section title="Scenario 3: Host B has data to transmit">
	<t>
		After Host B receives a HIP mobility UPDATE from A it has data 
		to send to A.  Or Host B may have been sending data to Host A 
		while Host A was moving.  The old data may have been lost; for 
		example the data is over UDP with no keepalives during the move 
		time.  The old data may be in a retransmission state; for 
		example the data is over TCP.  Or the data reached the 
		interface from the higher layer at the same time that the HIP 
		UPDATE with new locator was successfully processed.
	</t>
<section title="IPv6 datagram + HIP UPDATE > MTU">
	<t>
		Host B sends the HIP UPDATE validation followed by the IPv6 
		datagram.  Host B may place the address in ACTIVE state or wait 
		from HIP UPDATE confirmation from Host A.
	</t>
</section>
<section title="IPv6 datagram + HIP UPDATE <= MTU">
	<t>
		Host B sends the HIP UPDATE validation within the IPv6 
		datagram.  Host B may place the address in ACTIVE state or wait 
		from HIP UPDATE confirmation from Host A.
	</t>
</section>
</section>
</section>
<section anchor="dMov" title="Double-Jump mobility">
<t>
	The HIP mobility UPDATE will fail without the use of RVS.  In fact 
	both RVS are needed for both UPDATEs to find its peer.  This is why 
	the "shotgun" acceleration SHOULD always be used when the peer's 
	RVS is known.
</t>
<section title="Environment">
<t>
	<list style="symbols">
		<t>
			Both host A and B are mobile.
		</t>
		<t>
			Host A and B share a HIP Security Association.
		</t>
		<t>
			Both hosts move in the network and change their IP 
			addresses.  Before either receives the others HIP mobility 
			UPDATE.
		</t>
		<t>
			Host A and B are registered to a RVS server, not 
			necessarily the same and each has the others RVS address.
		</t>
	</list>
</t>
</section>
<section anchor="Shotgun" title="Shotgunning UPDATEs">
<t>
	Shotgunning is the process of sending the same UPDATE to more than 
	one LOCATOR.  In particular it refers to sending the UPDATE to at 
	least the peer's last known IP address and to its RVS address 
	learned from the VIA_RVS for either the R1 or I2 packet.
</t>
<t>
	A host MUST be prepared to receive and discard multiple HIP 
	mobility UPDATEs. The duplicates will be readily identified as 
	having the same SEQ (UPDATE sequence umber).
</t>
<t>
	Shotgunning SHOULD always be used when an RVS is known.  A peer 
	never knows of a "double-jump" event until after it receives its 
	peer's UPDATE.
</t>
</section>
<section anchor="SubB" title="Neither host has data to transmit">
<t>
	Host A triggers a HIP mobility UPDATE with Locator to inform Host B 
	of new address.  Host B, upon validating Host A HIP UPDATE, 
	continues with Address Verification.
</t>
<t>
	No attempt should be made to piggyback the two UPDATE processes.  
	They may run simultaneously but not in the same IP datagrams.
</t>
</section>
<section title="Either host has data to transmit">
	<t>
	The following acceleration advice presents a number of challenges.  
	The best rule of thumb is to send the data as soon as possible.
	</t>
<section title="IPv6 datagram + HIP UPDATE > MTU">
	<t>
		Same process as <xref target="SubB" />
	</t>
</section>
<section title="IPv6 datagram + HIP UPDATE <= MTU">
	<t>
		Host A sends HIP UPDATE with Locator to inform Host B of new 
		address.  Datagram is appended to HIP UPDATE using Next Header. 
		Host B, may have already sent a datagram with its original HIP 
		UPDATE.  If since then a receipt of Host A's UPDATE it has more 
		data to transmit, upon validating Host A HIP UPDATE, sends next 
		header to proper module and continues with Address 
		Verification.  This datagram is processed even though the 
		address is UNVERIFIED.
	</t>
</section>
</section>
</section>
<section anchor="IPnHIP" title="Special considerations when used with IPnHIP">
<t>
	<xref target="I-D.moskowitz-hip-ipnhip">IPnHIP</xref> has superior 
	resiliency to attack over <xref target="RFC2004">IPnIP</xref> as it 
	uses an ESP-styled sequence number and the HIP SPI rather than the 
	encapsulated IP addresses. Still a host SHOULD use the PAYLOAD_MIC 
	from <xref target="RFC6078">HICCUPS</xref> whenever an IPnHIP 
	datagram is appended to a HIP mobility UPDATE.  This effectively 
	blocks any substitution attack.  It also lengthens the HIP UPDATE 
	by 24 bytes which may result in NOT being able to append the IPnHIP 
	datagram and stay within the MTU.
</t>
<t>
	Use of the PAYLOAD_MIC is a recommendation and not a requirement.  
	The risk of bloating the UPDATE packet such that the IPnHIP payload 
	cannot be carried in the same datagram may be reason enough not to 
	use it.
</t>
</section>

<section anchor="IANA" title="IANA Considerations">
    <t>
      The following change to the "Host Identity Protocol (HIP) Parameters"
      registries has been made:
    </t>
    <t>
	  The PAYLOAD_MIC parameter used here is defined in HICCUPS which 
	  is an Experimental RFC.  Here it is being used in a Standards 
	  Track document.
    </t>
</section>
<section title="Security Considerations">
<t>
	HIP fast mobility does not introduce any new security 
	considerations beyond that in <xref 
	target="I-D.ietf-hip-rfc5206-bis">HIP Host Mobility</xref>.  If 
	anything its requirement to know and use the RVS for a peer improve 
	the frequency of a successful mobility notification.
</t>
</section>
<section title="Acknowledgments">
<t>
	The term "shotgun" for fast mobility comes from the InfraHIP 
	project.  The HIP UPDATE lengths were supplied by Jeff Ahrenholz.
</t>
<t>
	Sue Hares of Huawei and Jeff Ahrenholz of Tempered Networks 
	contributed to the clarity in this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
	<?rfc include="reference.RFC.2119.xml"?>
</references>
<references title="Informative References">
	<?rfc include="reference.RFC.2004.xml"?>
	<?rfc include="reference.RFC.6078.xml"?>
	<?rfc include="reference.RFC.7343.xml"?>
	<?rfc include="reference.RFC.7401.xml"?>
	<?rfc include="reference.RFC.7402.xml"?>
	<?rfc include="reference.RFC.8004.xml"?>
	<?rfc include="reference.I-D.ietf-hip-rfc5206-bis.xml"?>
	<?rfc include="reference.I-D.moskowitz-hip-ipnhip.xml"?>
</references>
</back>
</rfc>