idnits 2.17.1 draft-keranen-hip-over-hip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2010) is 5194 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group A. Keranen 3 Internet-Draft Ericsson 4 Intended status: Experimental January 26, 2010 5 Expires: July 30, 2010 7 Host Identity Protocol Signaling Message Transport Modes 8 draft-keranen-hip-over-hip-00.txt 10 Abstract 12 This document specifies two transport modes for Host Identity 13 Protocol signaling messages that allow conveying them over encrypted 14 connections initiated with the Host Identity Protocol. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 30, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Mode Negotiation in HIP Base Exchange . . . . . . . . . . . 3 60 3.2. HIP Messages on Encrypted Connections . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 66 7.2. Informational References . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 Host Identity Protocol [RFC5201] signaling messages can be exchanged 72 over plain IP using the protocol number reserved for this purpose, or 73 over UDP using the UDP port reserved for HIP NAT traversal 74 [I-D.ietf-hip-nat-traversal]. When two hosts perform a HIP base 75 exchange, they set up an encrypted connection between them for data 76 traffic, but continue to use plain IP or UDP for HIP signaling 77 messages. 79 This document defines how the encrypted connection can be used also 80 for HIP signaling messages. Two different modes are defined: HIP 81 over Encapsulating Security Payload (ESP) and HIP over TCP. The 82 benefit of sending HIP messages over ESP is that all signaling 83 traffic (including HIP headers) will be encrypted. If HIP messages 84 are sent over TCP (which in turn is transported over ESP), TCP can 85 handle also message fragmentation where needed. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 3. Protocol Extensions 95 This section defines how support for different HIP signaling message 96 transport modes is negotiated and the normative behavior required by 97 the extension. 99 3.1. Mode Negotiation in HIP Base Exchange 101 A HIP host implementing this specification SHOULD indicate the modes 102 it supports, and is willing to use, in the base exchange. The HIP 103 signaling message transport mode negotiation is similar to HIP NAT 104 traversal mode negotiation: first the Responder lists the supported 105 modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1 106 packet. If the Initiator supports, and is willing to use, any of the 107 modes proposed by the Responder, it selects one of the modes by 108 adding a HIP_TRANSPORT_MODE parameter containing the selected mode to 109 the I2 packet. Finally, if the Initiator selected one of the modes 110 and the base exchange succeeds, hosts use the selected mode for the 111 following HIP signaling messages sent between them. 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Type | Length | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Mode ID #1 | Mode ID #2 | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Mode ID #n | Padding | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 Type [ TBD by IANA; 990 ] 124 Length length in octets, excluding Type, Length, and padding 125 Mode ID defines the proposed or selected transport mode(s) 127 The following mode IDs are defined: 129 ID name Value 130 RESERVED 0 131 ESP 1 132 ESP-TCP 2 134 Figure 1: Format of the HIP_TRANSPORT_MODE parameter 136 3.2. HIP Messages on Encrypted Connections 138 If the ESP mode is selected in the base exchange, both hosts MUST 139 listen for incoming HIP signaling messages and send outgoing messages 140 on the encrypted connection. The ESP header's next header value for 141 such messages MUST be set to HIP (139). 143 If the ESP-TCP mode is selected, the Responder MUST start to listen 144 for an incoming TCP connection on the port 10500 on the encrypted 145 connection and the Initiator MUST create a TCP connection to the 146 Responder on the same port. The Initiator SHOULD use port 10500 as 147 the source port for the TCP connection. Once the TCP connection is 148 established, both hosts MUST listen for incoming HIP signaling 149 messages and send the outgoing messages using the TCP connection. 150 The ESP next header value for messages sent using the ESP-TCP mode 151 connections MUST be set to TCP (6). 153 Since TCP provides reliable transport, the HIP messages sent over TCP 154 MUST NOT be retransmitted for the purpose of achieving reliable 155 transmission. Instead, a host simply waits for the same time that 156 would be taken by the maximum amount of retransmissions with 157 unreliable transmission before concluding that there is no response. 159 4. Security Considerations 161 By exchanging the HIP messages over ESP connection, all HIP signaling 162 data (after the base exchange) will be encrypted, but only if NULL 163 encryption is not used. Thus, host requiring confidentiality for the 164 HIP signaling messages must check that encryption is negotiated to be 165 used on the ESP connection. 167 5. Acknowledgements 169 Thanks to Gonzalo Camarillo for comments on the draft. 171 6. IANA Considerations 173 This section is to be interpreted according to [RFC5226]. 175 This document updates the IANA Registry for HIP Parameter Types 176 [RFC5201] by assigning new HIP Parameter Type value for the 177 HIP_TRANSPORT_MODE parameter (defined in Section 3.1). 179 7. References 181 7.1. Normative References 183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 184 Requirement Levels", BCP 14, RFC 2119, March 1997. 186 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 187 "Host Identity Protocol", RFC 5201, April 2008. 189 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 190 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 191 May 2008. 193 7.2. Informational References 195 [I-D.ietf-hip-nat-traversal] 196 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 197 Keranen, "Basic HIP Extensions for Traversal of Network 198 Address Translators", draft-ietf-hip-nat-traversal-09 199 (work in progress), October 2009. 201 Author's Address 203 Ari Keranen 204 Ericsson 205 Hirsalantie 11 206 02420 Jorvas 207 Finland 209 Email: Ari.Keranen@ericsson.com