One document matched: draft-ietf-hip-rfc5204-bis-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY RFC1122 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml'>
<!ENTITY RFC6724 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6724.xml'>
<!ENTITY RFC2827 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml'>
<!ENTITY RFC3013 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3013.xml'>
<!ENTITY RFC5204 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5204.xml'>
<!ENTITY I-D.ietf-hip-rfc4423-bis PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc4423-bis.xml' >
<!ENTITY I-D.ietf-hip-rfc5201-bis PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5201-bis.xml' >
<!ENTITY I-D.ietf-hip-rfc5203-bis PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5203-bis.xml' >
<!ENTITY I-D.ietf-hip-rfc5205-bis PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5205-bis.xml' >
<!ENTITY I-D.ietf-hip-rfc5206-bis PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5206-bis.xml' >
]>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc comments="yes" ?>
<rfc category="std" obsoletes="5204" ipr="trust200902" docName="draft-ietf-hip-rfc5204-bis-06">
<front>
<title abbrev="HIP Rendezvous Extension">
Host Identity Protocol (HIP) Rendezvous Extension
</title>
<author initials="J." surname="Laganier" fullname="Julien Laganier">
<organization abbrev="Luminate Wireless, Inc.">
Luminate Wireless, Inc.
</organization>
<address> <postal>
<street>
</street>
<city>Cupertino</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>julien.ietf@gmail.com</email>
</address>
</author>
<author initials="L." surname="Eggert" fullname="Lars Eggert">
<organization abbrev="NetApp">NetApp</organization>
<address>
<postal>
<street>Sonnenallee 1</street>
<code>85551</code> <city>Kirchheim</city>
<country>Germany</country>
</postal>
<phone>+49 151 12055791</phone>
<email>lars@netapp.com</email>
<uri>http://eggert.org</uri>
</address>
</author>
<date year="2015"/>
<area>Internet</area>
<keyword>HIP</keyword>
<keyword>host identity protocol</keyword>
<keyword>host identity payload</keyword>
<keyword>Rendezvous</keyword>
<abstract>
<t>
This document defines a rendezvous extension for the Host Identity
Protocol (HIP). The rendezvous extension extends HIP and the HIP
registration extension for initiating communication between HIP nodes
via HIP rendezvous servers. Rendezvous servers improve reachability and operation when
HIP nodes are multi-homed or mobile.
This document obsoletes RFC5204.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The <xref target="I-D.ietf-hip-rfc4423-bis">Host Identity
Protocol (HIP) Architecture</xref> introduces
the rendezvous mechanism to help a HIP node to contact a frequently moving HIP node.
The rendezvous mechanism involves a third party, the rendezvous server (RVS), which
serves as an initial contact point ("rendezvous point") for its clients.
The clients of an RVS are HIP nodes that use the
<xref target="I-D.ietf-hip-rfc5203-bis">HIP Registration
Extension</xref> to register their HIT->IP address mappings
with the RVS. After this registration, other HIP nodes can
initiate a base exchange using the IP address of the RVS
instead of the current IP address of the node they attempt to
contact. Essentially, the clients of an RVS become reachable
at the RVS's IP address. Peers can initiate a HIP base exchange with the IP address of the RVS, which will relay this initial communication such that the base exchange may successfully complete.
</t>
</section>
<section title="Terminology">
<t>
This section defines terms used throughout the remainder of
this specification.
</t>
<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 RFC 2119 <xref target="RFC2119"/>.
</t>
<t>
In addition to the terminology defined in the <xref target="I-D.ietf-hip-rfc5201-bis">HIP specification</xref>
and the <xref target="I-D.ietf-hip-rfc5203-bis">HIP Registration Extension</xref>, this document
defines and uses the following terms:
<list style="hanging">
<t hangText="Rendezvous Service"><vspace blankLines="0"/>
A HIP service provided by a rendezvous server
to its rendezvous clients. The rendezvous server offers to relay some
of the arriving base exchange packets between the initiator and responder.
</t>
<t hangText="Rendezvous Server (RVS)"><vspace blankLines="0"/>
A HIP registrar providing rendezvous service.
</t>
<t hangText="Rendezvous Client"><vspace blankLines="0"/>
A HIP requester that has registered for rendezvous service at a rendezvous server.
</t>
<t hangText="Rendezvous Registration"><vspace blankLines="0"/>
A HIP registration for rendezvous service, established between a rendezvous server and a rendezvous client.
</t>
</list>
</t>
</section>
<section title="Overview of Rendezvous Server Operation">
<t>
<xref target="base-ex"/> shows a simple HIP base exchange without
a rendezvous server, in which the initiator initiates the exchange
directly with the responder by sending an I1 packet to the responder's IP
address, as per the <xref target="I-D.ietf-hip-rfc5201-bis">HIP specification </xref>.
</t>
<figure anchor="base-ex" title="HIP base exchange without rendezvous server.">
<artwork align="center">
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
</artwork>
</figure>
<t>
The <xref target="I-D.ietf-hip-rfc5206-bis">End-Host Mobility and Multihoming with the
Host Identity Protocol specification</xref> allows a HIP node to notify its peers
about changes in its set of IP addresses. This specification presumes
initial reachability of the two nodes with respect to each other.
</t>
<t>
However, such a HIP node MAY also want to be reachable to
other future correspondent peers that are unaware of its location change.
The <xref target="I-D.ietf-hip-rfc4423-bis"> HIP Architecture</xref>
introduces rendezvous servers with whom a HIP node MAY register its host identity tags (HITs)
and current IP addresses. An RVS relays HIP packets arriving for these HITs to the
node's registered IP addresses. When a HIP node has registered with an RVS, it SHOULD
record the IP address of its RVS in its DNS record, using the HIP DNS resource record type
defined in the <xref target="I-D.ietf-hip-rfc5205-bis">HIP DNS Extension</xref>.
</t>
<figure anchor="lookup-rvs" title="HIP base exchange with a rendezvous server.">
<artwork align="center">
+-----+
+--I1--->| RVS |---I1--+
| +-----+ |
| v
+-----+ +-----+
| |<------R1-------| |
| I |-------I2------>| R |
| |<------R2-------| |
+-----+ +-----+
</artwork>
</figure>
<t>
<xref target="lookup-rvs"/> shows a HIP base exchange involving a
rendezvous server. It is assumed that HIP node R previously registered its HITs and current IP addresses with the RVS, using the <xref target="I-D.ietf-hip-rfc5203-bis">HIP Registration
Extension</xref>.
When the initiator I tries to establish contact with the responder R, it must
send the I1 of the base exchange either to one of R's IP addresses (if known
via DNS or other means) or to one of R's rendezvous servers.
Here, I obtains the IP address of R's rendezvous server from R's DNS record and then sends the I1 packet of the HIP base exchange to RVS. RVS, noticing that the HIT contained in the arriving I1 packet is not one of its own, MUST check its current registrations to determine if it needs to relay the packets. Here, it determines that the HIT belongs to R and then relays the I1 packet to the registered IP address. R then completes the base exchange without further assistance from RVS by
sending an R1 directly to the I's IP address, as obtained from the I1 packet.
In this specification, the client of the RVS is always the responder.
However, there might be reasons to allow a client to initiate a base exchange through its own RVS, like NAT and firewall traversal. This specification does
not address such scenarios, which should be specified in other documents.
</t>
<section title="Diagram Notation">
<figure>
<artwork align="left">
Notation Significance
-------- ------------
I, R I and R are the respective source and destination IP
addresses in the IP header.
HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the
responder's HITs in the packet, respectively.
REG_REQ A REG_REQUEST parameter is present in the HIP header.
REG_RES A REG_RESPONSE parameter is present in the HIP header.
FROM:I A FROM parameter containing the IP address I is
present in the HIP header.
RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with
the appropriate registration key is present in the HIP
header.
VIA:RVS A VIA_RVS parameter containing the IP address RVS of
a rendezvous server is present in the HIP header.
</artwork>
</figure>
</section>
<section title="Rendezvous Client Registration">
<t>
Before a rendezvous server starts to relay HIP packets to a rendezvous client,
the rendezvous client needs to register with it to receive rendezvous
service by using the
<xref target="I-D.ietf-hip-rfc5203-bis">
HIP Registration Extension
</xref>
as illustrated in the following schema:
</t>
<figure title="Rendezvous client registering with a rendezvous server.">
<artwork align="center">
+-----+ +-----+
| | I1 | |
| |--------------------------->| |
| |<---------------------------| |
| I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | |
| |--------------------------->| |
| |<---------------------------| |
| | R2(REG_RES) | |
+-----+ +-----+
</artwork></figure>
</section>
<section title="Relaying the Base Exchange">
<t>
If a HIP node and one of its rendezvous servers have a rendezvous registration,
the rendezvous servers relay inbound I1 packets (that contain one of the client's HITs) by rewriting the IP header. They replace the destination
IP address of the I1 packet with one of the IP addresses of the owner of the HIT, i.e., the rendezvous client. They MUST also recompute the IP checksum accordingly.</t>
<t> Because of egress filtering on the path from the RVS to the client <xref target="RFC2827"/><xref target="RFC3013"/>, a HIP rendezvous server SHOULD
replace the source IP address, i.e., the IP address of I, with one of its own IP
addresses. The replacement IP address SHOULD be chosen according to relevant IPv4 and IPv6
specifications <xref target="RFC1122"/><xref target="RFC6724"/>. Because this replacement conceals the initiator's IP address, the RVS MUST append a FROM parameter containing the original source IP address of the packet.
This FROM parameter MUST be integrity protected by an RVS_HMAC keyed with the corresponding
rendezvous registration integrity key <xref target="I-D.ietf-hip-rfc5203-bis"/>.
</t>
<?rfc needLines="17" ?>
<figure title="Rendezvous server rewriting IP addresses.">
<artwork align="center">
I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+
| | RVS | |
| | | |
| +---------+ |
| V
+-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+
| |<---------------------------------------------| |
| | | |
| I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| |
| |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+
</artwork>
</figure>
<t>
This modification of HIP packets at a rendezvous server can be problematic because
the HIP protocol uses integrity checks.
Because the I1 does not include HMAC
or SIGNATURE parameters, these two end-to-end integrity checks are unaffected by the
operation of rendezvous servers.
</t>
<t>
The RVS SHOULD verify the checksum field of an I1 packet before doing any modifications. After modification, it MUST recompute the checksum field using the
updated HIP header, which possibly included new FROM and RVS_HMAC parameters,
and a pseudo-header containing the updated source and destination IP addresses.
This enables the responder to validate the checksum of the I1 packet "as is", without
having to parse any FROM parameters.
</t>
</section>
</section>
<section title="Rendezvous Server Extensions">
<t>
This section describes extensions to the <xref target="I-D.ietf-hip-rfc5203-bis">HIP Registration Extension</xref>,
allowing a HIP node
to register with a rendezvous server
for rendezvous service and
notify the RVS aware of changes to its current location. It also describes an extension to
the <xref target="I-D.ietf-hip-rfc5201-bis">HIP specification</xref> itself,
allowing establishment of HIP associations via
one or more HIP rendezvous server(s).
</t>
<section title="RENDEZVOUS Registration Type">
<t>
This specification defines an additional registration for the
<xref target="I-D.ietf-hip-rfc5203-bis">HIP Registration Extension</xref>
that allows registering with a rendezvous server for rendezvous
service.
</t>
<?rfc needLines="4" ?>
<figure>
<artwork align="left">
Number Registration Type
------ -----------------
1 RENDEZVOUS
</artwork>
</figure>
</section>
<section title="Parameter Formats and Processing" anchor="ext-parm">
<section title="RVS_HMAC Parameter" anchor="ext-parm-rvahmac">
<t>
The RVS_HMAC is a non-critical parameter
whose only difference with the HMAC parameter defined
in the <xref target="I-D.ietf-hip-rfc5201-bis">HIP specification</xref> is its "type" code.
This change causes it to be located after the FROM parameter (as opposed
to the HMAC):
</t>
<figure>
<artwork align="left">
Type 65500
Length Variable. Length in octets, excluding Type, Length, and
Padding.
HMAC HMAC computed over the HIP packet, excluding the
RVS_HMAC parameter and any following parameters. The
HMAC is keyed with the appropriate HIP integrity key
(HIP-lg or HIP-gl) established when rendezvous
registration happened. The HIP "checksum" field MUST be
set to zero, and the HIP header length in the HIP common
header MUST be calculated not to cover any excluded
parameter when the HMAC is calculated. The size of the
HMAC is the natural size of the hash computation
output depending on the used hash function.
</artwork>
</figure>
<t>
To allow a rendezvous client and its RVS to verify the integrity of
packets flowing between them, both SHOULD protect packets with an
added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity
key established while registration occurred. A valid RVS_HMAC SHOULD
be present on every packet flowing between a client and a server and
MUST be present when a FROM parameter is processed.
</t>
</section>
<?rfc needLines="17" ?>
<section title="FROM Parameter" anchor="ext-parm-from">
<figure>
<artwork align="center">
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65498
Length 16
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
</artwork>
</figure> <t>
A rendezvous server MUST add a FROM parameter containing the
original source IP address of a HIP packet
whenever the source IP address in the IP header is rewritten. If one or more FROM
parameters are already present, the new FROM parameter MUST be
appended after the existing ones.
</t> <t>
Whenever an RVS inserts a FROM parameter, it MUST insert
an RVS_HMAC protecting the packet integrity, especially
the IP address included in the FROM parameter.
</t>
</section>
<section title="VIA_RVS Parameter" anchor="ext-parm-viarvs">
<figure>
<artwork align="center">
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65502
Length Variable
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
</artwork>
</figure>
<t>
After the responder receives a relayed I1 packet, it can begin to send
HIP packets addressed to the initiator's IP address, without further assistance
from an RVS. For debugging purposes, it MUST append a newly created VIA_RVS
parameter at the end of the R1 packet that contains the IP address of the RVS
that relayed the I1 packet. Including more than one IP address in the VIA_RVS
parameter is outside the scope of this specification. The main goal of using
the VIA_RVS parameter is to allow operators to diagnose possible issues
encountered while establishing a HIP association via an RVS.
</t>
</section>
</section>
<section title="Modified Packets Processing">
<t>
The following subsections describe the differences of processing of I1
and R1 while a rendezvous server is involved in the base exchange.
</t>
<section title="Processing Outgoing I1 Packets">
<t>
An initiator SHOULD NOT send an opportunistic I1 with a NULL
destination HIT to an IP address that is known to be a rendezvous
server address, unless it wants to establish a HIP association with the
rendezvous server itself and does not know its HIT.
</t>
<?rfc needLines="5" ?>
<t>
When an RVS rewrites the source IP address of an I1 packet due to egress filtering,
it MUST add a FROM parameter to the I1 that contains the initiator's source IP address. This FROM parameter MUST be protected by an RVS_HMAC keyed with the integrity key established at rendezvous registration.
</t>
</section>
<section title="Processing Incoming I1 Packets">
<t>
When a rendezvous server receives an I1 whose destination HIT is not its own, it
consults its registration database to find a registration for the rendezvous service
established by the HIT owner. If it finds an appropriate registration, it relays the packet to the registered IP address. If it does not find an appropriate registration, it drops the packet.
</t>
<t>
A rendezvous server SHOULD interpret any incoming opportunistic I1
(i.e., an I1 with a NULL destination HIT) as an I1 addressed to itself and SHOULD NOT
attempt to relay it to one of its clients.
</t>
<t>
When a rendezvous client receives an I1, it MUST validate any present RVS_HMAC parameter.
If the RVS_HMAC cannot be verified, the packet SHOULD be dropped. If the RVS_HMAC cannot be
verified and a FROM parameter is present, the packet MUST be dropped.
</t>
<t>
A rendezvous client acting as responder SHOULD drop opportunistic I1s that
include a FROM parameter, because this indicates that the I1 has been
relayed.
</t>
</section>
<section title="Processing Outgoing R1 Packets">
<t>
When a responder replies to an I1 relayed via an RVS, it
MUST append to the regular R1 header a VIA_RVS parameter containing the
IP addresses of the traversed RVSs.
</t>
</section>
<section title="Processing Incoming R1 Packets">
<t>
The <xref target="I-D.ietf-hip-rfc5201-bis">HIP specification</xref> mandates
that a system receiving an R1 MUST first check to see if it has sent an I1 to
the originator of the R1 (i.e., the system is in state I1-SENT). When the R1 is
replying to a relayed I1, this check SHOULD be based on HITs only. In case the IP
addresses are also checked, then the source IP address MUST be checked against
the IP address included in the VIA_RVS parameter.
</t>
</section>
</section>
</section>
<?rfc needLines="6" ?>
<section title="Security Considerations">
<t>
This section discusses the known threats introduced by these HIP extensions
and the implications on the overall security of HIP. In particular, it
argues that the extensions described in this document do not introduce
additional threats to the Host Identity Protocol.
</t>
<t>
It is difficult to encompass the whole scope of threats introduced by
rendezvous servers because their presence has implications both at
the IP and HIP layers. In particular, these extensions
might allow for redirection, amplification, and reflection attacks at the
IP layer, as well as attacks on the HIP layer itself, for example,
man-in-the-middle attacks against the HIP base exchange.
</t>
<t>
If an initiator has a priori knowledge of the responder's host identity
when it first contacts the responder via an RVS, it has a means to verify
the signatures in the HIP base exchange, which protects
against man-in-the-middle attacks.
</t>
<t>
If an initiator does not have a priori knowledge of the responder's host identity (so-called "opportunistic initiators"), it is almost impossible to defend the HIP
exchange against these attacks, because the public keys exchanged cannot be authenticated. The
only approach would be to mitigate hijacking threats on HIP state by
requiring an R1 answering an opportunistic I1 to come from the same IP address that originally sent the I1. This procedure retains a level of security that is equivalent to what exists in the Internet today.
</t>
<t>
However, for reasons of simplicity, this specification does not allow the
establishment of a HIP association via a rendezvous server in an opportunistic manner.
</t>
</section>
<section title="IANA Considerations">
<t>
This section is to be interpreted according to the <xref target="RFC5226">Guidelines for Writing an
IANA Considerations Section in RFCs</xref>.
</t>
<t>
This document updates the IANA Registry for HIP Parameters Types by
replacing references to <xref target="RFC5204"/> by references to this
document.
</t>
</section>
<section title="Acknowledgments">
<t>
The following people have provided thoughtful and helpful
discussions and/or suggestions that have improved this document:
Marcus Brunner, Tom Henderson, Miika Komu, Mika Kousa, Pekka
Nikander, Justino Santos, Simon Schuetz, Tim Shepard, Kristian Slavov,
Martin Stiemerling, and Juergen Quittek.
</t>
<t>
Lars Eggert has received funding from the European Union's Horizon 2020
research and innovation program 2014-2018 under grant agreement No. 644866.
This document reflects only the authors' views and the European Commission is
not responsible for any use that may be made of the information it contains.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5226;
&RFC1122;
&RFC6724;
&I-D.ietf-hip-rfc5201-bis;
&I-D.ietf-hip-rfc5203-bis;
&I-D.ietf-hip-rfc5205-bis;
</references>
<references title="Informative References">
&I-D.ietf-hip-rfc4423-bis;
&RFC2827;
&RFC3013;
&RFC5204;
&I-D.ietf-hip-rfc5206-bis;
</references>
<section title="Changes from RFC 5204">
<t>
<list style="symbols">
<t>
Updated HIP references to revised HIP specifications.
</t>
<t>
Added relaying of UPDATE packets to support double jump mobility scenario.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:53:30 |