One document matched: draft-moskowitz-hip-ipnhip-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-ipnhip-01.txt" ipr="trust200902">
<front>
<title abbrev="IP-within-IP-with-HIP">Encapsulation of IP within IP managed by HIP</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 defines how to encapsulate IP within IP when the
tunnel is managed with <xref target="RFC7401">HIPv2</xref>. The
goal is reduced header size and improved security over <xref
target="RFC2003">IPnIP</xref> and <xref
target="RFC2004" />.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
MobileIP has opted for a simple IP within IP tunneling mechanism
without any tunnel security. The justification for this approach
over secure tunneling mechanisms like <xref
target="RFC4303">ESP</xref> is outside the scope of this document.
The approach here is to define a IPnIP header that leverages the
HIP Security Association and is potentiality smaller than <xref
target="RFC2004">RFC2004</xref> as well as provides for a higher
security posture.
</t>
<t>
The IPnHIP header defined here also supports the per-packet
compression, <xref target="I-D.moskowitz-gpcomp">GPCOMP</xref>,
which offers further gains in transmission efficiency.
</t>
<t>
Implementors are expected to be familiar with both HIPv2 and <xref
target="RFC7402">ESP with HIP</xref>. This document draws heavily
on RFC7402 to the extent that much of the flow process is not
duplicated here.
</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="SPI:">
The Security Parameter Index.
</t>
</list>
</t>
</section>
</section>
<section anchor="SPI" title="The advantage of a HIP managed IP-within-IP Tunnel">
<t>
HIP maps the peer address pair into two 32 bit uni-directional
Security Parameter Indexes (SPI). It is only necessary for a
tunnel to include the SPI that indicates the traffic direction. The
HIP layer provides the translation between the SPI and the
addresses. The resultant header is thus almost always smaller than
with RFC2004.
</t>
<t>
This results that an attacker will have to learn about this SPI to
addressing mapping to execute an attack against the higher layers
within the tunnel.
</t>
<t>
The addition of an ESP-styled sequence number further reduces the
attack window as the attacker must know the current sequence number
window. The inclusion of a 32 bit sequence number enlarges the
header, but for IPv4 it is still in line with the size for RFC2004
and for IPv6 it is still considerably smaller.
</t>
</section>
<section anchor="IPnHIP1" title="IPnHIP Header Format">
<t>
The Protocol field in the IP header is replaced by protocol
number TBD for the IPnHIP encapsulation protocol.
</t>
<t>
The format of the IP-within-IP-with-HIP header is as follows:
</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Flags | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Header Format
Protocol
Copied from the Protocol field in the original IP header.
Flags
Is a set of 8 options flags.
Header Checksum
The 16-bit one's complement of the one's complement sum of all
16-bit words in this header. For purposes of computing the
checksum, the value of the checksum field is 0. The IP header
and IP payload (after the minimal forwarding header) are not
included in this checksum computation.
SPI
The SPI as defined in section SPI.
Sequence Number
As defined in RFC 4303.
</artwork>
</figure>
<t>
Flags is a set of 8 options flags. Bit 7 is the GPComp
<xref target="I-D.moskowitz-gpcomp" /> bit compression option bit.
</t>
<figure>
<artwork>
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| C|
+-+-+-+-+-+-+-+-+
Figure 2 - Flags Field
</artwork>
</figure>
</section>
<section title="HIP parameters to negotiate IPnHIP">
<t>
Two HIP parameters are defined for setting up IPnHIP tunnel format
associations in HIP communication and for restarting existing ones.
</t>
<figure>
<artwork>
Parameter Type Length Data
IPnHIP_INFO [TBD-IANA] 8 Remote's old SPI, new SPI
IPnHIP_TRANSFORM [TBD-IANA] variable IP Encapsulation in IP
</artwork>
</figure>
<section anchor="IPnHIP_INFO" title="IPnHIP_INFO">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLD SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEW SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD-IANA]
Length 8
OLD SPI old SPI for data sent to address(es) associated
with this SA. If this is an initial SA setup, the
OLD SPI value is zero.
NEW SPI new SPI for data sent to address(es) associated
with this SA.
</artwork>
</figure>
<t>
The processing of IPnHIP_INFO is similar to ESP_INFO, section 5.1.1
of <xref target="RFC7402">RFC7402</xref>, without the KEYMAT
generation.
</t>
</section>
<section anchor="IPnHIP_TRANSFORM" title="IPnHIP_TRANSFORM">
<t>
The IPnHIP_TRANSFORM parameter is used during IPnHIP SA
establishment. The first party sends a selection of transform
families in the IPnHIP_TRANSFORM parameter, and the peer must
select one of the proposed values and include it in the response
IPnHIP_TRANSFORM parameter.
</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Suite ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #2 | Suite ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD-IANA]
Length length in octets, excluding Type, Length, and
padding.
Reserved zero when sent, ignored when received.
Suite ID defines the IPnHIP Suite to be used.
The following Suite IDs can be used:
Suite ID Value
RESERVED 0 [this draft]
IPnHIP 1 [sec IPnHIP1]
</artwork>
</figure>
<t>
The sender of an IPnHIP transform parameter MUST make sure that
there are no more than six (6) Suite IDs in one IPnHIP transform
parameter. Conversely, a recipient MUST be prepared to handle
received transform parameters that contain more than six Suite IDs.
The limited number of Suite IDs sets the maximum size of the
IPnHIP_TRANSFORM parameter. As the default configuration, the
IPnHIP_TRANSFORM parameter MUST contain at least one of the
mandatory Suite IDs. There MAY be a configuration option that
allows the administrator to override this default.
</t>
<t>
Currently only one IPnHIP_TRANSFORM is defined. Future work may
define others.
</t>
</section>
</section>
<section anchor="IPnHIP_SA" title="HIP IPnHIP Security Association Setup">
<t>
The IPnHIP Security Association is set up during the base exchange.
The following subsections define the IPnHIP SA setup procedure
using both base exchange messages (R1, I2, R2) and UPDATE messages.
</t>
<t>
The IPnHIP Security Association follows the same process as that of
the ESP Security Association (sec 5.2 <xref
target="RFC7402">RFC7402</xref> except for the KEYMAT.
</t>
<t>
IPnHIP SA does not have any keying material, and thus those
processes are not needed. 'Rekeying' to assign new SPIs is still
needed to manage the sequence numbering.
</t>
</section>
<section title="ICMP Messages">
<t>
ICMP Message handling is the same as sec 5.4 <xref
target="RFC7402">RFC7402</xref>.
</t>
</section>
<section title="Packet Processing">
<t>
Packet processing is mainly defined in sec 6 <xref
target="RFC7402">RFC7402</xref> with following changes.
</t>
<section title="Packet Compression">
<t>
Packet compression is negotiated by HIP using the GPCOMP_INFO
parameter defined in <xref target="I-D.moskowitz-ssls-hip" />.
</t>
<t>
IPnHIP uses the Implied Structure of <xref
target="I-D.moskowitz-gpcomp">GPCOMP</xref> and follows the
Compress/Uncompresing process defined there in.
</t>
</section>
<section title="Processing Application Data">
<t>
IPnHIP sequence number processing follows <xref
target="RFC4303">RFC4303</xref>. With the extended 64 bit sequence
number, the rarely will be the need to update the SPI to reset the
sequence number. Any resetting the SPI will be driven by privacy
concerns. The rest of the packet processing follows <xref
target="RFC2004">RFC2004</xref>.
</t>
</section>
<section title="Processing HIP Packets">
<t>
HIP packet processing is the same as sec 6 <xref
target="RFC7402">RFC7402</xref> without the keying parameter
handling.
</t>
</section>
</section>
<section title="ESP or Minimal IPnIP or IPnHIP">
<t>
There are at least three ways to compare these encapsulation protocols:
<list style="symbols">
<t>
Encapsulation cost in bytes
</t>
<t>
Encapsulation cost in processing
</t>
<t>
Security posture
</t>
</list>
</t>
<section title="Encapsulation cost in bytes">
<t>
From the analysis below, IPnHIP is consistently the cheapest option.
<list style="symbols">
<t>
ESP adds 9 bytes + pad (0 - 3 bytes) + ICV. For GMAC-96
this is 17 bytes + pad.
</t>
<t>
Minimal IPnIP is 4 bytes + 2 * IP address length. For IPv4
this is 12 bytes and for IPv6 36 bytes.
</t>
<t>
IPnHIP is 12 bytes (Note: Can use GPCOMP with Implied
Structure, i.e. no header cost, for further savings.)
</t>
</list>
</t>
</section>
<section title="Encapsulation cost in processing">
<t>
<list style="symbols">
<t>
ESP with GMAC-96 is perhaps the computationally lightest
transform. GMAC has only 2 AES operations + n GHASH
operations.
</t>
<t>
Minimal IPnIP has no cryptographic processing overhead.
</t>
<t>
IPnHIP has no cryptographic processing overhead. GPCOMP
does add the compression processing.
</t>
</list>
</t>
</section>
<section title="Security posture">
<t>
<list style="symbols">
<t>
ESP traffic is fully protected up to the strength of the
cryptographic transform used. Plus the HIP SA is
protection against MITM attacks provided there is
authentication of the HITs used.
</t>
<t>
Minimal IPnIP has no security protection. A party that
discovers IPnIP flow can interject any traffic desired.
</t>
<t>
IPnHIP masks the internal identities by only including the
HIP SA SPIs and a sequence number. This presents a number
of challenges to an attacker. They have to know the
sequence number window and what the SPI maps to. This is
not as strong as ESP, but more protection that IPnIP
provides.
</t>
</list>
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
The IP protocol number of NN for IPnHIP is assigned by IANA.
</t>
<t>
The following change to the "Host Identity Protocol (HIP) Parameters"
registries has been made:
</t>
<t>
<list style="hanging">
<t hangText="IPnHIP_INFO:">
This document defines the new IPnHIP_INFO parameter (see
<xref target="IPnHIP_INFO" />). The parameter value will be
assigned by IANA. Its value should come from the 66-127
range.
</t>
<t hangText="IPnHIP_TRANSFORM:">
This document defines the new IPnHIP_TRANSFORM parameter (see
<xref target="IPnHIP_TRANSFORM" />). The parameter value
will be assigned by IANA. Its value should come from the
4096-4480 range.
</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>
IPnHIP lacks the protections provided by ESP. ESP with the GMAC
transform should be seriously considered for a fast, Integrity only
mode instead of IPnHIP. GMAC has only 2 AES block operations per
ESP payload.
</t>
<t>
There are policy cases where only a non-securable tunnel will be
permitted. IPnHIP provides a high level of tunnel management
security through HIP and better privacy and spoofing and replay
resiliency than IPnIP due to its use of a sequence number scheme
and an SPI instead of the internal IP addresses.
</t>
<t>
HIP fast Mobility provides the high trust provided by HIP for
address remapping without needing triangular data routing.
</t>
<t>
GPCOMP, like ESP, is not believed to be subject to the TLS
BEAST attack.
</t>
</section>
<section title="Acknowledgments">
<t>
Sue Hares of Huawei contributed to the clarity in this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.7401.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2003.xml"?>
<?rfc include="reference.RFC.2004.xml"?>
<?rfc include="reference.RFC.4303.xml"?>
<?rfc include="reference.RFC.7402.xml"?>
<?rfc include="reference.I-D.moskowitz-gpcomp.xml"?>
<?rfc include="reference.I-D.moskowitz-ssls-hip.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:08:39 |