]>
Encapsulation of IP within IP managed by HIPHuaweiOak ParkMI48237USArgm@labs.htt-consult.comHuaweiHuawei Bld, No.156 Beiqing Rd.BeijingHai-Dian District100095Chinaxuxiaohu@huawei.comHuaweiHuawei Bld, No.156 Beiqing Rd.BeijingHai-Dian District100095Chinaxuxiaohu@huawei.comInternet
HIPRFCRequest for CommentsI-DInternet-DraftHIP
This document defines how to encapsulate IP within IP when the
tunnel is managed with HIPv2. The
goal is reduced header size and improved security over IPnIP and .
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 ESP 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 RFC2004 as well as provides for a higher
security posture.
The IPnHIP header defined here also supports the per-packet
compression, GPCOMP,
which offers further gains in transmission efficiency.
Implementors are expected to be familiar with both HIPv2 and ESP with HIP. This document draws heavily
on RFC7402 to the extent that much of the flow process is not
duplicated here.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.
The short name for IP-within-IP managed by HIP.
The Security Parameter Index.
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.
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.
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.
The Protocol field in the IP header is replaced by protocol
number TBD for the IPnHIP encapsulation protocol.
The format of the IP-within-IP-with-HIP header is as follows:
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.
Flags is a set of 8 options flags. Bit 7 is the GPComp
bit compression option bit.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| C|
+-+-+-+-+-+-+-+-+
Figure 2 - Flags Field
Two HIP parameters are defined for setting up IPnHIP tunnel format
associations in HIP communication and for restarting existing ones.
Parameter Type Length Data
IPnHIP_INFO [TBD-IANA] 8 Remote's old SPI, new SPI
IPnHIP_TRANSFORM [TBD-IANA] variable IP Encapsulation in IP
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.
The processing of IPnHIP_INFO is similar to ESP_INFO, section 5.1.1
of RFC7402, without the KEYMAT
generation.
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.
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]
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.
Currently only one IPnHIP_TRANSFORM is defined. Future work may
define others.
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.
The IPnHIP Security Association follows the same process as that of
the ESP Security Association (sec 5.2 RFC7402 except for the KEYMAT.
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.
ICMP Message handling is the same as sec 5.4 RFC7402.
Packet processing is mainly defined in sec 6 RFC7402 with following changes.
Packet compression is negotiated by HIP using the GPCOMP_INFO
parameter defined in .
IPnHIP uses the Implied Structure of GPCOMP and follows the
Compress/Uncompresing process defined there in.
IPnHIP sequence number processing follows RFC4303. 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 RFC2004.
HIP packet processing is the same as sec 6 RFC7402 without the keying parameter
handling.
There are at least three ways to compare these encapsulation protocols:
Encapsulation cost in bytes
Encapsulation cost in processing
Security posture
From the analysis below, IPnHIP is consistently the cheapest option.
ESP adds 9 bytes + pad (0 - 3 bytes) + ICV. For GMAC-96
this is 17 bytes + pad.
Minimal IPnIP is 4 bytes + 2 * IP address length. For IPv4
this is 12 bytes and for IPv6 36 bytes.
IPnHIP is 12 bytes (Note: Can use GPCOMP with Implied
Structure, i.e. no header cost, for further savings.)
ESP with GMAC-96 is perhaps the computationally lightest
transform. GMAC has only 2 AES operations + n GHASH
operations.
Minimal IPnIP has no cryptographic processing overhead.
IPnHIP has no cryptographic processing overhead. GPCOMP
does add the compression processing.
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.
Minimal IPnIP has no security protection. A party that
discovers IPnIP flow can interject any traffic desired.
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.
The IP protocol number of NN for IPnHIP is assigned by IANA.
The following change to the "Host Identity Protocol (HIP) Parameters"
registries has been made:
This document defines the new IPnHIP_INFO parameter (see
). The parameter value will be
assigned by IANA. Its value should come from the 66-127
range.
This document defines the new IPnHIP_TRANSFORM parameter (see
). The parameter value
will be assigned by IANA. Its value should come from the
4096-4480 range.
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.
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.
HIP fast Mobility provides the high trust provided by HIP for
address remapping without needing triangular data routing.
GPCOMP, like ESP, is not believed to be subject to the TLS
BEAST attack.
Sue Hares of Huawei contributed to the clarity in this document.