draft-ietf-hip-rfc5204-bis-03.txt   draft-ietf-hip-rfc5204-bis-04.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: June 14, 2014 December 11, 2013 Expires: December 11, 2014 June 9, 2014
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rfc5204-bis-03 draft-ietf-hip-rfc5204-bis-04
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 June 14, 2014. This Internet-Draft will expire on December 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . 13 Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 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")
for its clients. The clients of an RVS are HIP nodes that use the for its clients. The clients of an RVS are HIP nodes that use the
HIP Registration Extension [I-D.ietf-hip-rfc5203-bis] to register HIP Registration Extension [I-D.ietf-hip-rfc5203-bis] to register
skipping to change at page 5, line 7 skipping to change at page 5, line 7
completes the base exchange without further assistance from RVS by 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 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 packet. In this specification, the client of the RVS is always the
responder. However, there might be reasons to allow a client to responder. However, there might be reasons to allow a client to
initiate a base exchange through its own RVS, like NAT and firewall initiate a base exchange through its own RVS, like NAT and firewall
traversal. This specification does not address such scenarios, which traversal. This specification does not 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 the RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with
appropriate registration key is present in the HIP the appropriate registration key is present in the HIP
header. header.
VIA:RVS A VIA_RVS parameter containing the IP address RVS of a VIA:RVS A VIA_RVS parameter containing the IP address RVS of
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 a rendezvous server starts to relay HIP packets to a
rendezvous client, the rendezvous client needs to register with it to rendezvous client, the rendezvous client needs to register with it to
receive rendezvous service by using the HIP Registration Extension receive rendezvous service by using the HIP Registration Extension
[I-D.ietf-hip-rfc5203-bis] as illustrated in the following schema: [I-D.ietf-hip-rfc5203-bis] as illustrated in the following schema:
+-----+ +-----+ +-----+ +-----+
| | I1 | | | | I1 | |
skipping to change at page 7, line 34 skipping to change at page 7, line 36
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
[I-D.ietf-hip-rfc5201-bis] is its "type" code. This change causes it [I-D.ietf-hip-rfc5201-bis] is its "type" code. This change causes it
to be located after the FROM parameter (as opposed to the HMAC): to be located after the FROM 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 set registration happened. The HIP "checksum" field MUST be
to zero, and the HIP header length in the HIP common header set to zero, and the HIP header length in the HIP common
MUST be calculated not to cover any excluded parameter header MUST be calculated not to cover any excluded
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
be present on every packet flowing between a client and a server and be present on every packet flowing between a client and a server and
MUST be present when a FROM parameter is processed. MUST be present when a FROM parameter is processed.
4.2.2. FROM Parameter 4.2.2. FROM Parameter
skipping to change at page 12, line 24 skipping to change at page 12, line 31
8.1. Normative References 8.1. Normative References
[I-D.ietf-hip-rfc5201-bis] [I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf- "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-14 (work in progress), October 2013. hip-rfc5201-bis-14 (work in progress), October 2013.
[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-02 Registration Extension", draft-ietf-hip-rfc5203-bis-05
(work in progress), September 2012. (work in progress), March 2014.
[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-02 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-04
(work in progress), September 2012. (work in progress), January 2014.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[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, March 1997.
[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. May 2008.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., 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, September 2012.
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-06 (work in Architecture", draft-ietf-hip-rfc4423-bis-08 (work in
progress), November 2013. progress), April 2014.
[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-06 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06
(work in progress), July 2013. (work in progress), July 2013.
[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, May 2000.
 End of changes. 19 change blocks. 
42 lines changed or deleted 42 lines changed or added

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