draft-ietf-hip-rfc5204-bis-08.txt   rfc8004.txt 
Network Working Group J. Laganier Internet Engineering Task Force (IETF) J. Laganier
Internet-Draft Luminate Wireless, Inc. Request for Comments: 8004 Luminate Wireless, Inc.
Obsoletes: 5204 (if approved) L. Eggert Obsoletes: 5204 L. Eggert
Intended status: Standards Track NetApp Category: Standards Track NetApp
Expires: February 5, 2017 August 4, 2016 ISSN: 2070-1721 October 2016
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rfc5204-bis-08
Abstract Abstract
This document defines a rendezvous extension for the Host Identity This document defines a rendezvous extension for the Host Identity
Protocol (HIP). The rendezvous extension extends HIP and the HIP Protocol (HIP). The rendezvous extension extends HIP and the HIP
registration extension for initiating communication between HIP nodes Registration Extension for initiating communication between HIP nodes
via HIP rendezvous servers. Rendezvous servers improve reachability via HIP rendezvous servers. Rendezvous servers improve reachability
and operation when HIP nodes are multi-homed or mobile. This and operation when HIP nodes are multihomed or mobile. This document
document obsoletes RFC5204. obsoletes RFC 5204.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 5, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8004.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 3 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 3
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . 5 3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . 5 3.2. Rendezvous Client Registration . . . . . . . . . . . . . 5
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . 6 3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . 7 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . 7 4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . 7 4.2. Parameter Formats and Processing . . . . . . . . . . . . 7
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . 7 4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . 7
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . 8 4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . 8
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 8 4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9 4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . 9 4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . 9
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . 10 4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . 10
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . 10 4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . 10
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . 10 4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 14 Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) Architecture "The Host Identity Protocol (HIP) Architecture" [HIP-ARCH] introduces
[I-D.ietf-hip-rfc4423-bis] introduces the rendezvous mechanism to the rendezvous mechanism to help a HIP node to contact a frequently
help a HIP node to contact a frequently moving HIP node. The moving HIP node. The rendezvous mechanism involves a third party,
rendezvous mechanism involves a third party, the rendezvous server the rendezvous server (RVS), which serves as an initial contact point
(RVS), which serves as an initial contact point ("rendezvous point") ("rendezvous point") for its clients. The clients of an RVS are HIP
for its clients. The clients of an RVS are HIP nodes that use the nodes that use the HIP Registration Extension [RFC8003] to register
HIP Registration Extension [I-D.ietf-hip-rfc5203-bis] to register
their HIT->IP address mappings with the RVS. After this their HIT->IP address mappings with the RVS. After this
registration, other HIP nodes can initiate a base exchange using the 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 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 they attempt to contact. Essentially, the clients of an RVS become
reachable at the RVS's IP address. Peers can initiate a HIP base 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 exchange with the IP address of the RVS, which will relay this
initial communication such that the base exchange may successfully initial communication such that the base exchange may successfully
complete. complete.
2. Terminology 2. Terminology
This section defines terms used throughout the remainder of this This section defines terms used throughout the remainder of this
specification. specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition to the terminology defined in the HIP specification In addition to the terminology defined in the HIP specification
[RFC7401] and the HIP Registration Extension [RFC7401] and the HIP Registration Extension [RFC8003], this document
[I-D.ietf-hip-rfc5203-bis], this document defines and uses the defines and uses the following terms:
following terms:
Rendezvous Service Rendezvous Service
A HIP service provided by a rendezvous server to its rendezvous A HIP service provided by an RVS to its rendezvous clients. The
clients. The rendezvous server offers to relay some of the RVS offers to relay some of the arriving base exchange packets
arriving base exchange packets between the initiator and between the Initiator and Responder.
responder.
Rendezvous Server (RVS) Rendezvous Server (RVS)
A HIP registrar providing rendezvous service. A HIP registrar providing rendezvous service.
Rendezvous Client Rendezvous Client
A HIP requester that has registered for rendezvous service at a A HIP requester that has registered for rendezvous service at an
rendezvous server. RVS.
Rendezvous Registration Rendezvous Registration
A HIP registration for rendezvous service, established between a A HIP registration for rendezvous service, established between an
rendezvous server and a rendezvous client. RVS and a rendezvous client.
3. Overview of Rendezvous Server Operation 3. Overview of Rendezvous Server Operation
Figure 1 shows a simple HIP base exchange without a rendezvous Figure 1 shows a simple HIP base exchange without an RVS, in which
server, in which the initiator initiates the exchange directly with the Initiator initiates the exchange directly with the Responder by
the responder by sending an I1 packet to the responder's IP address, sending an I1 packet to the Responder's IP address, as per the HIP
as per the HIP specification [RFC7401]. specification [RFC7401].
+-----+ +-----+ +-----+ +-----+
| |-------I1------>| | | |-------I1------>| |
| I |<------R1-------| R | | I |<------R1-------| R |
| |-------I2------>| | | |-------I2------>| |
| |<------R2-------| | | |<------R2-------| |
+-----+ +-----+ +-----+ +-----+
Figure 1: HIP base exchange without rendezvous server. Figure 1: HIP Base Exchange without a Rendezvous Server
The End-Host Mobility and Multihoming with the Host Identity Protocol The End-Host Mobility and Multihoming with the HIP specification
specification [I-D.ietf-hip-rfc5206-bis] allows a HIP node to notify [HIP-HOST-MOB] allows a HIP node to notify its peers about changes in
its peers about changes in its set of IP addresses. This its set of IP addresses. This specification presumes initial
specification presumes initial reachability of the two nodes with reachability of the two nodes with respect to each other.
respect to each other.
However, such a HIP node MAY also want to be reachable to other However, such a HIP node MAY also want to be reachable to other
future correspondent peers that are unaware of its location change. future correspondent peers that are unaware of its location change.
The HIP Architecture [I-D.ietf-hip-rfc4423-bis] introduces rendezvous The HIP Architecture [HIP-ARCH] introduces RVSs with whom a HIP node
servers with whom a HIP node MAY register its host identity tags MAY register its Host Identity Tags (HITs) and current IP addresses.
(HITs) and current IP addresses. An RVS relays HIP packets arriving An RVS relays HIP packets arriving for these HITs to the node's
for these HITs to the node's registered IP addresses. When a HIP registered IP addresses. When a HIP node has registered with an RVS,
node has registered with an RVS, it SHOULD record the IP address of it SHOULD record the IP address of its RVS in its DNS record, using
its RVS in its DNS record, using the HIP DNS resource record type the HIP DNS resource record type defined in the HIP DNS Extension
defined in the HIP DNS Extension [I-D.ietf-hip-rfc5205-bis]. [RFC8005].
+-----+ +-----+
+--I1--->| RVS |---I1--+ +--I1--->| RVS |---I1--+
| +-----+ | | +-----+ |
| v | v
+-----+ +-----+ +-----+ +-----+
| |<------R1-------| | | |<------R1-------| |
| I |-------I2------>| R | | I |-------I2------>| R |
| |<------R2-------| | | |<------R2-------| |
+-----+ +-----+ +-----+ +-----+
Figure 2: HIP base exchange with a rendezvous server. Figure 2: HIP Base Exchange with a Rendezvous Server
Figure 2 shows a HIP base exchange involving a rendezvous server. It Figure 2 shows a HIP base exchange involving an RVS. It is assumed
is assumed that HIP node R previously registered its HITs and current that HIP node R previously registered its HITs and current IP
IP addresses with the RVS, using the HIP Registration Extension addresses with the RVS, using the HIP Registration Extension
[I-D.ietf-hip-rfc5203-bis]. When the initiator I tries to establish [RFC8003]. When the Initiator I tries to establish contact with the
contact with the responder R, it must send the I1 of the base Responder R, it must send the I1 of the base exchange either to one
exchange either to one of R's IP addresses (if known via DNS or other of R's IP addresses (if known via DNS or other means) or to one of
means) or to one of R's rendezvous servers. Here, I obtains the IP R's RVSs. Here, I obtains the IP address of R's RVS from R's DNS
address of R's rendezvous server from R's DNS record and then sends record and then sends the I1 packet of the HIP base exchange to RVS.
the I1 packet of the HIP base exchange to RVS. RVS, noticing that RVS, noticing that the HIT contained in the arriving I1 packet is not
the HIT contained in the arriving I1 packet is not one of its own, one of its own, MUST check its current registrations to determine if
MUST check its current registrations to determine if it needs to it needs to relay the packets. Here, it determines that the HIT
relay the packets. Here, it determines that the HIT belongs to R and belongs to R and then relays the I1 packet to the registered IP
then relays the I1 packet to the registered IP address. R then address. R then completes the base exchange without further
completes the base exchange without further assistance from RVS by assistance from RVS by sending an R1 directly to the I's IP address,
sending an R1 directly to the I's IP address, as obtained from the I1 as obtained from the I1 packet. In this specification, the client of
packet. In this specification, the client of the RVS is always the the RVS is always the Responder. However, there might be reasons
responder. However, there might be reasons to allow a client to (such as NAT and firewall traversal) to allow a client to initiate a
initiate a base exchange through its own RVS, like NAT and firewall base exchange through its own RVS. This specification does not
traversal. This specification does not address such scenarios, which address such scenarios, which should be specified in other documents.
should be specified in other documents.
3.1. Diagram Notation 3.1. Diagram Notation
Notation Significance Notation Significance
-------- ------------ -------- ------------
I, R I and R are the respective source and destination IP I, R I and R are the respective source and destination IP
addresses in the IP header. addresses in the IP header.
HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the HIT-I, HIT-R HIT-I and HIT-R are the Initiator's and the
responder's HITs in the packet, respectively. Responder's HITs in the packet, respectively.
REG_REQ A REG_REQUEST parameter is present in the HIP header. REG_REQ A REG_REQUEST parameter is present in the HIP header.
REG_RES A REG_RESPONSE 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 FROM:I A FROM parameter containing the IP address I is
present in the HIP header. present in the HIP header.
RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with RVS_HMAC An RVS_HMAC parameter containing an Hashed Message
the appropriate registration key is present in the HIP Authentication Code (HMAC) keyed with the appropriate
header. registration key is present in the HIP header.
VIA:RVS A VIA_RVS parameter containing the IP address RVS of VIA:RVS A VIA_RVS parameter containing the IP address RVS of
a rendezvous server is present in the HIP header. a rendezvous server is present in the HIP header.
3.2. Rendezvous Client Registration 3.2. Rendezvous Client Registration
Before a rendezvous server starts to relay HIP packets to a Before an RVS starts to relay HIP packets to a rendezvous client, the
rendezvous client, the rendezvous client needs to register with it to rendezvous client needs to register with the RVS to receive
receive rendezvous service by using the HIP Registration Extension rendezvous service by using the HIP Registration Extension [RFC8003]
[I-D.ietf-hip-rfc5203-bis] as illustrated in the following schema: as illustrated in the following schema:
+-----+ +-----+ +-----+ +-----+
| | I1 | | | | I1 | |
| |--------------------------->| | | |--------------------------->| |
| |<---------------------------| | | |<---------------------------| |
| I | R1(REG_INFO) | RVS | | I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | | | | I2(REG_REQ) | |
| |--------------------------->| | | |--------------------------->| |
| |<---------------------------| | | |<---------------------------| |
| | R2(REG_RES) | | | | R2(REG_RES) | |
+-----+ +-----+ +-----+ +-----+
Rendezvous client registering with a rendezvous server. Rendezvous Client Registering with a Rendezvous Server
3.3. Relaying the Base Exchange 3.3. Relaying the Base Exchange
If a HIP node and one of its rendezvous servers have a rendezvous If a HIP node and one of its RVSs have a rendezvous registration, the
registration, the rendezvous servers relay inbound I1 packets (that RVSs relay inbound I1 packets (that contain one of the client's HITs)
contain one of the client's HITs) by rewriting the IP header. They by rewriting the IP header. They replace the destination IP address
replace the destination IP address of the I1 packet with one of the of the I1 packet with one of the IP addresses of the owner of the
IP addresses of the owner of the HIT, i.e., the rendezvous client. HIT, i.e., the rendezvous client. They MUST also recompute the IP
They MUST also recompute the IP checksum accordingly. checksum accordingly.
Because of egress filtering on the path from the RVS to the client Because of ingress filtering on the path from the RVS to the client
[RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source [RFC2827] [RFC3013], a HIP RVS SHOULD replace the source IP address,
IP address, i.e., the IP address of I, with one of its own IP i.e., the IP address of I, with one of its own IP addresses. The
addresses. The replacement IP address SHOULD be chosen according to replacement IP address SHOULD be chosen according to relevant IPv4
relevant IPv4 and IPv6 specifications [RFC1122][RFC6724]. Because and IPv6 specifications [RFC1122] [RFC6724]. Because this
this replacement conceals the initiator's IP address, the RVS MUST replacement conceals the Initiator's IP address, the RVS MUST append
append a FROM parameter containing the original source IP address of a FROM parameter containing the original source IP address of the
the packet. This FROM parameter MUST be integrity protected by an packet. This FROM parameter MUST be integrity protected by an
RVS_HMAC keyed with the corresponding rendezvous registration RVS_HMAC keyed with the corresponding rendezvous registration
integrity key [I-D.ietf-hip-rfc5203-bis]. integrity key [RFC8003].
I1(RVS, R, HIT-I, HIT-R I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+ +----------------------->| |--------------------+
| | RVS | | | | RVS | |
| | | | | | | |
| +---------+ | | +---------+ |
| V | V
+-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+
| |<---------------------------------------------| | | |<---------------------------------------------| |
| | | | | | | |
| I | I2(I, R, HIT-I, HIT-R) | R | | I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| | | |--------------------------------------------->| |
| |<---------------------------------------------| | | |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+ +-----+ R2(R, I, HIT-R, HIT-I) +-----+
Rendezvous server rewriting IP addresses. Rendezvous Server Rewriting IP Addresses
This modification of HIP packets at a rendezvous server can be This modification of HIP packets at an RVS can be problematic because
problematic because the HIP protocol uses integrity checks. Because HIP uses integrity checks. Because the I1 does not include HMAC or
the I1 does not include HMAC or SIGNATURE parameters, these two end- SIGNATURE parameters, these two end-to-end integrity checks are
to-end integrity checks are unaffected by the operation of rendezvous unaffected by the operation of RVSs.
servers.
The RVS SHOULD verify the checksum field of an I1 packet before doing The RVS SHOULD verify the checksum field of an I1 packet before doing
any modifications. After modification, it MUST recompute the any modifications. After modification, it MUST recompute the
checksum field using the updated HIP header, which possibly included checksum field using the updated HIP header, which possibly included
new FROM and RVS_HMAC parameters, and a pseudo-header containing the new FROM and RVS_HMAC parameters, and a pseudo-header containing the
updated source and destination IP addresses. This enables the updated source and destination IP addresses. This enables the
responder to validate the checksum of the I1 packet "as is", without Responder to validate the checksum of the I1 packet "as is", without
having to parse any FROM parameters. having to parse any FROM parameters.
4. Rendezvous Server Extensions 4. Rendezvous Server Extensions
This section describes extensions to the HIP Registration Extension This section describes extensions to the HIP Registration Extension
[I-D.ietf-hip-rfc5203-bis], allowing a HIP node to register with a [RFC8003], allowing a HIP node to register with an RVS for rendezvous
rendezvous server for rendezvous service and notify the RVS aware of service and to notify the RVS aware of changes to its current
changes to its current location. It also describes an extension to location. It also describes an extension to the HIP specification
the HIP specification [RFC7401] itself, allowing establishment of HIP [RFC7401] itself, allowing establishment of HIP associations via one
associations via one or more HIP rendezvous server(s). or more HIP RVSs.
4.1. RENDEZVOUS Registration Type 4.1. RENDEZVOUS Registration Type
This specification defines an additional registration for the HIP This specification defines an additional registration for the HIP
Registration Extension [I-D.ietf-hip-rfc5203-bis] that allows Registration Extension [RFC8003] that allows registering with an RVS
registering with a rendezvous server for rendezvous service. for rendezvous service.
Number Registration Type Number Registration Type
------ ----------------- ------ -----------------
1 RENDEZVOUS 1 RENDEZVOUS
4.2. Parameter Formats and Processing 4.2. Parameter Formats and Processing
4.2.1. RVS_HMAC Parameter 4.2.1. RVS_HMAC Parameter
The RVS_HMAC is a non-critical parameter whose only difference with The RVS_HMAC is a non-critical parameter whose only difference with
skipping to change at page 7, line 38 skipping to change at page 7, line 39
4.2.1. RVS_HMAC Parameter 4.2.1. RVS_HMAC Parameter
The RVS_HMAC is a non-critical parameter whose only difference with The RVS_HMAC is a non-critical parameter whose only difference with
the HMAC parameter defined in the HIP specification [RFC7401] is its the HMAC parameter defined in the HIP specification [RFC7401] is its
"type" code. This change causes it to be located after the FROM "type" code. This change causes it to be located after the FROM
parameter (as opposed to the HMAC): parameter (as opposed to the HMAC):
Type 65500 Type 65500
Length Variable. Length in octets, excluding Type, Length, and Length Variable. Length in octets, excluding Type, Length, and
Padding. Padding.
HMAC HMAC computed over the HIP packet, excluding the HMAC HMAC computed over the HIP packet, excluding the
RVS_HMAC parameter and any following parameters. The RVS_HMAC parameter and any following parameters. The
HMAC is keyed with the appropriate HIP integrity key HMAC is keyed with the appropriate HIP integrity key
(HIP-lg or HIP-gl) established when rendezvous (HIP-lg or HIP-gl) established when rendezvous
registration happened. The HIP "checksum" field MUST be registration happened. The HIP "checksum" field MUST be
set to zero, and the HIP header length in the HIP common set to zero, and the HIP header length in the HIP common
header MUST be calculated not to cover any excluded header MUST be calculated not to cover any excluded
parameter when the HMAC is calculated. The size of the parameter when the HMAC is calculated. The size of the
HMAC is the natural size of the hash computation HMAC is the natural size of the hash computation
output depending on the used hash function. output depending on the used hash function.
To allow a rendezvous client and its RVS to verify the integrity of To allow a rendezvous client and its RVS to verify the integrity of
packets flowing between them, both SHOULD protect packets with an packets flowing between them, both SHOULD protect packets with an
added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity
key established while registration occurred. A valid RVS_HMAC SHOULD key established while registration occurred. A valid RVS_HMAC SHOULD
skipping to change at page 8, line 25 skipping to change at page 8, line 29
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65498 Type 65498
Length 16 Length 16
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
A rendezvous server MUST add a FROM parameter containing the original An RVS MUST add a FROM parameter containing the original source IP
source IP address of a HIP packet whenever the source IP address in address of a HIP packet whenever the source IP address in the IP
the IP header is rewritten. If one or more FROM parameters are header is rewritten. If one or more FROM parameters are already
already present, the new FROM parameter MUST be appended after the present, the new FROM parameter MUST be appended after the existing
existing ones. ones.
Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC
protecting the packet integrity, especially the IP address included protecting the packet integrity, especially the IP address included
in the FROM parameter. in the FROM parameter.
4.2.3. VIA_RVS Parameter 4.2.3. VIA_RVS Parameter
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 27 skipping to change at page 9, line 30
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65502 Type 65502
Length Variable Length Variable
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
After the responder receives a relayed I1 packet, it can begin to After the Responder receives a relayed I1 packet, it can begin to
send HIP packets addressed to the initiator's IP address, without send HIP packets addressed to the Initiator's IP address, without
further assistance from an RVS. For debugging purposes, it MUST further assistance from an RVS. For debugging purposes, it MUST
append a newly created VIA_RVS parameter at the end of the R1 packet 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. 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 Including more than one IP address in the VIA_RVS parameter is
outside the scope of this specification. The main goal of using the outside the scope of this specification. The main goal of using the
VIA_RVS parameter is to allow operators to diagnose possible issues VIA_RVS parameter is to allow operators to diagnose possible issues
encountered while establishing a HIP association via an RVS. encountered while establishing a HIP association via an RVS.
4.3. Modified Packets Processing 4.3. Modified Packets Processing
The following subsections describe the differences of processing of The following subsections describe the differences of the processing
I1 and R1 while a rendezvous server is involved in the base exchange. of I1 and R1 while an RVS is involved in the base exchange.
4.3.1. Processing Outgoing I1 Packets 4.3.1. Processing Outgoing I1 Packets
An initiator SHOULD NOT send an opportunistic I1 with a NULL An Initiator SHOULD NOT send an opportunistic I1 with a NULL
destination HIT to an IP address that is known to be a rendezvous destination HIT to an IP address that is known to be a rendezvous
server address, unless it wants to establish a HIP association with server address, unless it wants to establish a HIP association with
the rendezvous server itself and does not know its HIT. the RVS itself and does not know its HIT.
When an RVS rewrites the source IP address of an I1 packet due to 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 egress filtering, it MUST add a FROM parameter to the I1 that
contains the initiator's source IP address. This FROM parameter MUST contains the Initiator's source IP address. This FROM parameter MUST
be protected by an RVS_HMAC keyed with the integrity key established be protected by an RVS_HMAC keyed with the integrity key established
at rendezvous registration. at rendezvous registration.
4.3.2. Processing Incoming I1 Packets 4.3.2. Processing Incoming I1 Packets
When a rendezvous server receives an I1 whose destination HIT is not When an RVS receives an I1 whose destination HIT is not its own, it
its own, it consults its registration database to find a registration consults its registration database to find a registration for the
for the rendezvous service established by the HIT owner. If it finds rendezvous service established by the HIT owner. If it finds an
an appropriate registration, it relays the packet to the registered appropriate registration, it relays the packet to the registered IP
IP address. If it does not find an appropriate registration, it address. If it does not find an appropriate registration, it drops
drops the packet. the packet.
A rendezvous server SHOULD interpret any incoming opportunistic I1 An RVS SHOULD interpret any incoming opportunistic I1 (i.e., an I1
(i.e., an I1 with a NULL destination HIT) as an I1 addressed to with a NULL destination HIT) as an I1 addressed to itself and SHOULD
itself and SHOULD NOT attempt to relay it to one of its clients. NOT attempt to relay it to one of its clients.
When a rendezvous client receives an I1, it MUST validate any present When a rendezvous client receives an I1, it MUST validate any present
RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet 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 SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM
parameter is present, the packet MUST be dropped. parameter is present, the packet MUST be dropped.
A rendezvous client acting as responder SHOULD drop opportunistic I1s A rendezvous client acting as Responder SHOULD drop opportunistic I1s
that include a FROM parameter, because this indicates that the I1 has that include a FROM parameter, because this indicates that the I1 has
been relayed. been relayed.
4.3.3. Processing Outgoing R1 Packets 4.3.3. Processing Outgoing R1 Packets
When a responder replies to an I1 relayed via an RVS, it MUST append 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 to the regular R1 header a VIA_RVS parameter containing the IP
addresses of the traversed RVSs. addresses of the traversed RVSs.
4.3.4. Processing Incoming R1 Packets 4.3.4. Processing Incoming R1 Packets
The HIP specification [RFC7401] mandates that a system receiving an The HIP specification [RFC7401] mandates that a system receiving an
R1 MUST first check to see if it has sent an I1 to the originator of 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 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. 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 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 MUST be checked against the IP address included in the VIA_RVS
parameter. parameter.
5. Security Considerations 5. Security Considerations
This section discusses the known threats introduced by these HIP This section discusses the known threats introduced by these HIP
extensions and the implications on the overall security of HIP. In extensions and the implications on the overall security of HIP. In
particular, it argues that the extensions described in this document particular, it argues that the extensions described in this document
do not introduce additional threats to the Host Identity Protocol. do not introduce additional threats to HIP.
It is difficult to encompass the whole scope of threats introduced by It is difficult to encompass the whole scope of threats introduced by
rendezvous servers because their presence has implications both at RVSs because their presence has implications both at the IP and HIP
the IP and HIP layers. In particular, these extensions might allow layers. In particular, these extensions might allow for redirection,
for redirection, amplification, and reflection attacks at the IP amplification, and reflection attacks at the IP layer, as well as
layer, as well as attacks on the HIP layer itself, for example, man- attacks on the HIP layer itself, for example, man-in-the-middle
in-the-middle attacks against the HIP base exchange. attacks against the HIP base exchange.
If an initiator has a priori knowledge of the responder's host 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 identity when it first contacts the Responder via an RVS, it has a
means to verify the signatures in the HIP base exchange, which means to verify the signatures in the HIP base exchange, which
protects against man-in-the-middle attacks. protects against man-in-the-middle attacks.
If an initiator does not have a priori knowledge of the responder's If an Initiator does not have a priori knowledge of the Responder's
host identity (so-called "opportunistic initiators"), it is almost host identity (so-called "opportunistic Initiators"), it is almost
impossible to defend the HIP exchange against these attacks, because impossible to defend the HIP exchange against these attacks, because
the public keys exchanged cannot be authenticated. The only approach the public keys exchanged cannot be authenticated. The only approach
would be to mitigate hijacking threats on HIP state by requiring an would be to mitigate hijacking threats on HIP state by requiring an
R1 answering an opportunistic I1 to come from the same IP address R1 answering an opportunistic I1 to come from the same IP address
that originally sent the I1. This procedure retains a level of that originally sent the I1. This procedure retains a level of
security that is equivalent to what exists in the Internet today. security that is equivalent to what exists in the Internet today.
However, for reasons of simplicity, this specification does not allow However, for reasons of simplicity, this specification does not allow
the establishment of a HIP association via a rendezvous server in an the establishment of a HIP association via an RVS in an opportunistic
opportunistic manner. manner.
6. IANA Considerations 6. IANA Considerations
[RFC5204], obsoleted by this document, made the following definitions [RFC5204], obsoleted by this document, made the following definitions
and reservations in the IANA Registry for HIP Parameters Types: and reservations in the "Parameter Types" subregistry under "Host
Identity Protocol (HIP) Parameters":
Value Parameter Type Length Value Parameter Type Length
----- -------------- -------- ----- -------------- --------
65498 FROM 16 65498 FROM 16
65500 RVS_HMAC variable 65500 RVS_HMAC variable
65502 VIA_RVS variable 65502 VIA_RVS variable
This document updates the IANA Registry for HIP Parameters Types by In the "Parameter Types" subregistry under "Host Identity Protocol
replacing references to [RFC5204] by references to this document. (HIP) Parameters", references to [RFC5204] have been replaced by
references to this document.
[RFC5204], obsoleted by this document, made the following definition [RFC5204], obsoleted by this document, made the following definition
and reservation in the IANA Registry for HIP Registration Types: and reservation in the "Registration Types" subregistry under "Host
Identity Protocol (HIP) Parameters":
Value Registration Type Value Registration Type
----- ----------------- ----- -----------------
1 RENDEZVOUS 1 RENDEZVOUS
This document updates the IANA Registry for HIP Registration Types by In the "Registration Types" subregistry under "Host Identity Protocol
replacing references to [RFC5204] by references to this document. (HIP) Parameters", references to [RFC5204] have been replaced by
references to this document.
7. Acknowledgments
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.
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.
Thanks to Joel M. Halpern for performing the Gen-ART review of this
document as part of the publication process.
8. References
8.1. Normative References
[I-D.ietf-hip-rfc5203-bis] 7. References
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-ietf-hip-rfc5203-bis-10
(work in progress), January 2016.
[I-D.ietf-hip-rfc5205-bis] 7.1. Normative References
Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", draft-ietf-hip-rfc5205-bis-09
(work in progress), January 2016.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 13, line 15 skipping to change at page 12, line 41
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>. <http://www.rfc-editor.org/info/rfc7401>.
8.2. Informative References [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
October 2016, <http://www.rfc-editor.org/info/rfc8003>.
[I-D.ietf-hip-rfc4423-bis] [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
Moskowitz, R. and M. Komu, "Host Identity Protocol System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
Architecture", draft-ietf-hip-rfc4423-bis-14 (work in October 2016, <http://www.rfc-editor.org/info/rfc8005>.
progress), June 2016.
[I-D.ietf-hip-rfc5206-bis] 7.2. Informative References
[HIP-ARCH] Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", Work in Progress, draft-ietf-hip-rfc4423-
bis-14, June 2016.
[HIP-HOST-MOB]
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-12 the Host Identity Protocol", Work in Progress, draft-ietf-
(work in progress), May 2016. hip-rfc5206-bis-14, October 2016.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC3013] Killalea, T., "Recommended Internet Service Provider [RFC3013] Killalea, T., "Recommended Internet Service Provider
Security Services and Procedures", BCP 46, RFC 3013, Security Services and Procedures", BCP 46, RFC 3013,
DOI 10.17487/RFC3013, November 2000, DOI 10.17487/RFC3013, November 2000,
<http://www.rfc-editor.org/info/rfc3013>. <http://www.rfc-editor.org/info/rfc3013>.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, DOI 10.17487/RFC5204, Rendezvous Extension", RFC 5204, DOI 10.17487/RFC5204,
April 2008, <http://www.rfc-editor.org/info/rfc5204>. April 2008, <http://www.rfc-editor.org/info/rfc5204>.
Appendix A. Changes from RFC 5204 Appendix A. Changes from RFC 5204
o Updated HIP references to revised HIP specifications. o Updated HIP references to revised HIP specifications.
Acknowledgments
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, Juergen
Quittek, Justino Santos, Simon Schuetz, Tim Shepard, Kristian Slavov,
and Martin Stiemerling.
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.
Thanks to Joel M. Halpern for performing the Gen-ART review of this
document as part of the publication process.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Luminate Wireless, Inc. Luminate Wireless, Inc.
Cupertino, CA Cupertino, CA
USA United States of America
EMail: julien.ietf@gmail.com Email: julien.ietf@gmail.com
Lars Eggert Lars Eggert
NetApp NetApp
Sonnenallee 1 Sonnenallee 1
Kirchheim 85551 Kirchheim 85551
Germany Germany
Phone: +49 151 12055791 Phone: +49 151 12055791
EMail: lars@netapp.com Email: lars@netapp.com
URI: http://eggert.org URI: http://eggert.org
 End of changes. 66 change blocks. 
204 lines changed or deleted 197 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/