draft-ietf-hip-rfc5204-bis-06.txt   draft-ietf-hip-rfc5204-bis-07.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Luminate Wireless, Inc. Internet-Draft Luminate Wireless, Inc.
Obsoletes: 5204 (if approved) L. Eggert Obsoletes: 5204 (if approved) L. Eggert
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: December 12, 2015 June 10, 2015 Expires: June 19, 2016 December 17, 2015
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rfc5204-bis-06 draft-ietf-hip-rfc5204-bis-07
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 multi-homed or mobile. This
document obsoletes RFC5204. document obsoletes RFC5204.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2015. This Internet-Draft will expire on June 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 14 Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) Architecture The Host Identity Protocol (HIP) Architecture
[I-D.ietf-hip-rfc4423-bis] introduces the rendezvous mechanism to [I-D.ietf-hip-rfc4423-bis] introduces the rendezvous mechanism to
help a HIP node to contact a frequently moving HIP node. The help a HIP node to contact a frequently moving HIP node. The
rendezvous mechanism involves a third party, the rendezvous server rendezvous mechanism involves a third party, the rendezvous server
(RVS), which serves as an initial contact point ("rendezvous point") (RVS), which serves as an initial contact point ("rendezvous point")
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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
[I-D.ietf-hip-rfc5201-bis] and the HIP Registration Extension [RFC7401] and the HIP Registration Extension
[I-D.ietf-hip-rfc5203-bis], this document defines and uses the [I-D.ietf-hip-rfc5203-bis], this document 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 a rendezvous server to its rendezvous
clients. The rendezvous server offers to relay some of the clients. The rendezvous server offers to relay some of the
arriving base exchange packets between the initiator and arriving base exchange packets between the initiator and
responder. responder.
Rendezvous Server (RVS) Rendezvous Server (RVS)
skipping to change at page 3, line 41 skipping to change at page 3, line 41
Rendezvous Registration Rendezvous Registration
A HIP registration for rendezvous service, established between a A HIP registration for rendezvous service, established between a
rendezvous server and a rendezvous client. rendezvous server 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 a rendezvous
server, in which the initiator initiates the exchange directly with server, in which the initiator initiates the exchange directly with
the responder by sending an I1 packet to the responder's IP address, the responder by sending an I1 packet to the responder's IP address,
as per the HIP specification [I-D.ietf-hip-rfc5201-bis]. as per the HIP 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 rendezvous server.
skipping to change at page 7, line 13 skipping to change at page 7, line 13
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 [I-D.ietf-hip-rfc5203-bis], allowing a HIP node to register with a
rendezvous server for rendezvous service and notify the RVS aware of rendezvous server for rendezvous service and notify the RVS aware of
changes to its current location. It also describes an extension to changes to its current location. It also describes an extension to
the HIP specification [I-D.ietf-hip-rfc5201-bis] itself, allowing the HIP specification [RFC7401] itself, allowing establishment of HIP
establishment of HIP associations via one or more HIP rendezvous associations via one or more HIP rendezvous server(s).
server(s).
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 [I-D.ietf-hip-rfc5203-bis] that allows
registering with a rendezvous server for rendezvous service. registering with a rendezvous server 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
the HMAC parameter defined in the HIP specification the HMAC parameter defined in the HIP specification [RFC7401] is its
[I-D.ietf-hip-rfc5201-bis] is its "type" code. This change causes it "type" code. This change causes it to be located after the FROM
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
skipping to change at page 10, line 41 skipping to change at page 10, line 41
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 [I-D.ietf-hip-rfc5201-bis] mandates that a The HIP specification [RFC7401] mandates that a system receiving an
system receiving an R1 MUST first check to see if it has sent an I1 R1 MUST first check to see if it has sent an I1 to the originator of
to the originator of the R1 (i.e., the system is in state I1-SENT). the R1 (i.e., the system is in state I1-SENT). When the R1 is
When the R1 is replying to a relayed I1, this check SHOULD be based replying to a relayed I1, this check SHOULD be based on HITs only.
on HITs only. In case the IP addresses are also checked, then the In case the IP addresses are also checked, then the source IP address
source IP address MUST be checked against the IP address included in MUST be checked against the IP address included in the VIA_RVS
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 the Host Identity Protocol.
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 rendezvous servers because their presence has implications both at
skipping to change at page 12, line 11 skipping to change at page 12, line 11
Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino
Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin
Stiemerling, and Juergen Quittek. Stiemerling, and Juergen Quittek.
Lars Eggert has received funding from the European Union's Horizon Lars Eggert has received funding from the European Union's Horizon
2020 research and innovation program 2014-2018 under grant agreement 2020 research and innovation program 2014-2018 under grant agreement
No. 644866. This document reflects only the authors' views and the No. 644866. This document reflects only the authors' views and the
European Commission is not responsible for any use that may be made European Commission is not responsible for any use that may be made
of the information it contains. 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. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-20 (work in progress), October 2014.
[I-D.ietf-hip-rfc5203-bis] [I-D.ietf-hip-rfc5203-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-ietf-hip-rfc5203-bis-07 Registration Extension", draft-ietf-hip-rfc5203-bis-09
(work in progress), April 2015. (work in progress), June 2015.
[I-D.ietf-hip-rfc5205-bis] [I-D.ietf-hip-rfc5205-bis]
Laganier, J., "Host Identity Protocol (HIP) Domain Name Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", draft-ietf-hip-rfc5205-bis-06 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-08
(work in progress), January 2015. (work in progress), December 2015.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6724] Thaler, D., 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, September 2012. (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-hip-rfc4423-bis] [I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-11 (work in Architecture", draft-ietf-hip-rfc4423-bis-13 (work in
progress), April 2015. progress), December 2015.
[I-D.ietf-hip-rfc5206-bis] [I-D.ietf-hip-rfc5206-bis]
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-08 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-09
(work in progress), January 2015. (work in progress), July 2015.
[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, May 2000. Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/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,
November 2000. DOI 10.17487/RFC3013, November 2000,
<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, April 2008. Rendezvous Extension", RFC 5204, DOI 10.17487/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.
o Added relaying of UPDATE packets to support double jump mobility
scenario.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Luminate Wireless, Inc. Luminate Wireless, Inc.
Cupertino, CA Cupertino, CA
USA USA
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
Lars Eggert Lars Eggert
 End of changes. 24 change blocks. 
44 lines changed or deleted 52 lines changed or added

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