draft-ietf-hip-native-nat-traversal-08.txt   draft-ietf-hip-native-nat-traversal-09.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft J. Melen Internet-Draft J. Melen
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: July 26, 2015 January 22, 2015 Expires: January 24, 2016 July 23, 2015
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-08 draft-ietf-hip-native-nat-traversal-09
Abstract Abstract
This document specifies a new Network Address Translator (NAT) This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP). The new mode is traversal mode for the Host Identity Protocol (HIP). The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic. The main and UDP encapsulation of data and signaling traffic. The main
difference from the previously specified modes is the use of HIP difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures. messages for all NAT traversal procedures.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 July 26, 2015. This Internet-Draft will expire on January 24, 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 36 skipping to change at page 2, line 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is The Host Identity Protocol (HIP) [RFC7401] is specified to run
specified to run directly on top of IPv4 or IPv6. However, many directly on top of IPv4 or IPv6. However, many middleboxes found in
middleboxes found in the Internet, such as NATs and firewalls, often the Internet, such as NATs and firewalls, often allow only UDP or TCP
allow only UDP or TCP traffic to pass [RFC5207]. Also, especially traffic to pass [RFC5207]. Also, especially NATs usually require the
NATs usually require the host behind a NAT to create a forwarding host behind a NAT to create a forwarding state in the NAT before
state in the NAT before other hosts outside of the NAT can contact other hosts outside of the NAT can contact the host behind the NAT.
the host behind the NAT. To overcome this problem, different To overcome this problem, different methods, commonly referred to as
methods, commonly referred to as NAT traversal techniques, have been NAT traversal techniques, have been developed.
developed.
Two NAT traversal techniques for HIP are specified in [RFC5770]. One Two NAT traversal techniques for HIP are specified in [RFC5770]. One
of them uses only UDP encapsulation, while the other uses also the of them uses only UDP encapsulation, while the other uses also the
Interactive Connectivity Establishment (ICE) [RFC5245] protocol, Interactive Connectivity Establishment (ICE) [RFC5245] protocol,
which in turn uses Session Traversal Utilities for NAT (STUN) which in turn uses Session Traversal Utilities for NAT (STUN)
[RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766]
protocols to achieve a reliable NAT traversal solution. protocols to achieve a reliable NAT traversal solution.
The benefit of using ICE and STUN/TURN is that one can re-use the NAT The benefit of using ICE and STUN/TURN is that one can re-use the NAT
traversal infrastructure already available in the Internet, such as traversal infrastructure already available in the Internet, such as
skipping to change at page 3, line 28 skipping to change at page 3, line 28
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
This document uses the same terminology as [RFC5770] and the This document uses the same terminology as [RFC5770] and the
following: following:
HIP data relay: HIP data relay:
A host that forwards HIP data packets, such as Encapsulating A host that forwards HIP data packets, such as Encapsulating
Security Payload (ESP) [I-D.ietf-hip-rfc5202-bis], between two Security Payload (ESP) [RFC7402], between two hosts.
hosts.
Registered host: Registered host:
A host that has registered for a relaying service with a HIP data A host that has registered for a relaying service with a HIP data
relay. relay.
3. Protocol Description 3. Protocol Description
This section describes the normative behavior of the protocol This section describes the normative behavior of the protocol
extension. Most of the procedures are similar to what is defined in extension. Most of the procedures are similar to what is defined in
[RFC5770] but with different, or additional, parameter types and [RFC5770] but with different, or additional, parameter types and
values. In addition, a new type of relaying server, HIP data relay, values. In addition, a new type of relaying server, HIP data relay,
is specified. Also, it should be noted that HIP version 2 is specified. Also, it should be noted that HIP version 2 [RFC7401]
[I-D.ietf-hip-rfc5201-bis] (instead of [RFC5201] used in [RFC5770]) (instead of [RFC5201] used in [RFC5770]) is expected to be used with
is expected to be used with this NAT traversal mode. this NAT traversal mode.
3.1. Relay Registration 3.1. Relay Registration
Relay registration procedure for HIP signaling is identical to the Relay registration procedure for HIP signaling is identical to the
one specified in Section 4.1 of [RFC5770]. However, a host MAY also one specified in Section 4.1 of [RFC5770]. However, a host MAY also
register for UDP encapsulated ESP relaying using Registration Type register for UDP encapsulated ESP relaying using Registration Type
RELAY_UDP_ESP (value [TBD by IANA: 3]). RELAY_UDP_ESP (value [TBD by IANA: 3]).
If the HIP relay server supports relaying of UDP encapsulated ESP, If the HIP relay server supports relaying of UDP encapsulated ESP,
the host is allowed to register for a data relaying service (see the host is allowed to register for a data relaying service (see
skipping to change at page 4, line 39 skipping to change at page 4, line 39
3.2. Forwarding Rules and Permissions 3.2. Forwarding Rules and Permissions
The HIP data relay uses a similar permission model as a TURN server: The HIP data relay uses a similar permission model as a TURN server:
before any ESP data packets sent by a peer are forwarded, a before any ESP data packets sent by a peer are forwarded, a
permission MUST be set for the peer's address. The permissions also permission MUST be set for the peer's address. The permissions also
install a forwarding rule, similar to TURN's channels, based on the install a forwarding rule, similar to TURN's channels, based on the
Security Parameter Index (SPI) values in the ESP packets. Security Parameter Index (SPI) values in the ESP packets.
Permissions are not required for the connectivity checks, but if a Permissions are not required for the connectivity checks, but if a
relayed address is selected to be used for data, the registered host relayed address is selected to be used for data, the registered host
MUST send an UPDATE message [I-D.ietf-hip-rfc5201-bis] with a MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION
PEER_PERMISSION parameter (see Section 4.2) with the address of the parameter (see Section 4.2) with the address of the peer and the
peer and the outbound and inbound SPI values the host is using with outbound and inbound SPI values the host is using with this peer.
this peer.
When a data relay receives an UPDATE with a PEER_PERMISSION When a data relay receives an UPDATE with a PEER_PERMISSION
parameter, it MUST check if the sender of the UPDATE is registered parameter, it MUST check if the sender of the UPDATE is registered
for data relaying service, and drop the UPDATE if the host was not for data relaying service, and drop the UPDATE if the host was not
registered. If the host was registered, the relay checks if there is registered. If the host was registered, the relay checks if there is
a permission with matching information (address, protocol, port and a permission with matching information (address, protocol, port and
SPI values). If there is no such permission, a new permission MUST SPI values). If there is no such permission, a new permission MUST
be created and its lifetime MUST be set to 5 minutes. If an be created and its lifetime MUST be set to 5 minutes. If an
identical permission already existed, it MUST be refreshed by setting identical permission already existed, it MUST be refreshed by setting
the lifetime to 5 minutes. A registered host SHOULD refresh the lifetime to 5 minutes. A registered host SHOULD refresh
skipping to change at page 11, line 49 skipping to change at page 11, line 49
HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin
Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav
Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip
Matthews. Matthews.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC5226].
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[I-D.ietf-hip-rfc5201-bis] by assigning new HIP Parameter Type values [RFC7401] by assigning new HIP Parameter Type values for the new HIP
for the new HIP Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in Section 4.1),
in Section 4.1), and PEER_PERMISSION (defined in Section 4.2). and PEER_PERMISSION (defined in Section 4.2).
This document also updates the IANA Registry for HIP NAT traversal This document also updates the IANA Registry for HIP NAT traversal
modes [RFC5770] by assigning value for the NAT traversal mode ICE- modes [RFC5770] by assigning value for the NAT traversal mode ICE-
HIP-UDP (defined in Section 3.6). HIP-UDP (defined in Section 3.6).
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow
registering with a HIP relay server for ESP relaying service: registering with a HIP relay server for ESP relaying service:
RELAY_UDP_ESP (defined in Section 3.1); and performing server RELAY_UDP_ESP (defined in Section 3.1); and performing server
reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in
Section 3.4). Section 3.4).
8. References 8. References
8.1. Normative References 8.1. Normative References
[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>.
[I-D.ietf-hip-rfc5201-bis] [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, Henderson, "Host Identity Protocol Version 2 (HIPv2)",
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf- RFC 7401, DOI 10.17487/RFC7401, April 2015,
hip-rfc5201-bis-20 (work in progress), October 2014. <http://www.rfc-editor.org/info/rfc7401>.
[I-D.ietf-hip-rfc5202-bis] [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", draft-ietf-hip- the Host Identity Protocol (HIP)", RFC 7402,
rfc5202-bis-07 (work in progress), September 2014. DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>.
[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-06 Registration Extension", draft-ietf-hip-rfc5203-bis-09
(work in progress), September 2014. (work in progress), June 2015.
[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>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions Keranen, Ed., "Basic Host Identity Protocol (HIP)
for Traversal of Network Address Translators", RFC 5770, Extensions for Traversal of Network Address Translators",
April 2010. RFC 5770, DOI 10.17487/RFC5770, April 2010,
<http://www.rfc-editor.org/info/rfc5770>.
8.2. Informative References 8.2. Informative References
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
"Host Identity Protocol", RFC 5201, April 2008. Henderson, "Host Identity Protocol", RFC 5201,
DOI 10.17487/RFC5201, April 2008,
<http://www.rfc-editor.org/info/rfc5201>.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP) Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008. Communication", RFC 5207, DOI 10.17487/RFC5207, April
2008, <http://www.rfc-editor.org/info/rfc5207>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keranen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
 End of changes. 20 change blocks. 
46 lines changed or deleted 54 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/