1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 6261 Ericsson
Category: Experimental May 2011
ISSN: 2070-1721
<span class="h1">Encrypted Signaling Transport Modes for</span>
<span class="h1">the Host Identity Protocol</span>
Abstract
This document specifies two transport modes for Host Identity
Protocol (HIP) signaling messages that allow them to be conveyed over
encrypted connections initiated with the Host Identity Protocol.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6261">http://www.rfc-editor.org/info/rfc6261</a>.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Keranen Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3">3</a>. Transport Mode Negotiation . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Mode Negotiation in the HIP Base Exchange . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Mode Negotiation after the HIP Base Exchange . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Error Notifications . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. HIP Messages on Encrypted Connections . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. ESP Mode . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. ESP-TCP Mode . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Recovering from Failed Encrypted Connections . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Host Mobility and Multihoming . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9">9</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10.2">10.2</a>. Informational References . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#appendix-A">Appendix A</a>. Mobility and Multihoming Examples . . . . . . . . . . <a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Host Identity Protocol (HIP) [<a href="./rfc5201" title=""Host Identity Protocol"">RFC5201</a>] signaling messages can be
exchanged over plain IP using the protocol number reserved for this
purpose, or over UDP using the UDP port reserved for HIP NAT
traversal [<a href="./rfc5770" title=""Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators"">RFC5770</a>]. When two hosts perform a HIP base exchange,
they set up an encrypted connection between them for data traffic,
but continue to use plain IP or UDP for HIP signaling messages.
This document defines how the encrypted connection can be used also
for HIP signaling messages. Two different modes are defined: HIP
over Encapsulating Security Payload (ESP) and HIP over TCP. The
benefit of sending HIP messages over ESP is that all signaling
traffic (including HIP headers) will be encrypted. If HIP messages
are sent over TCP (which in turn is transported over ESP), TCP can
handle also message fragmentation where needed.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Keranen Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Transport Mode Negotiation</span>
This section defines how support for different HIP signaling message
transport modes is indicated and how the use of different modes is
negotiated.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Mode Negotiation in the HIP Base Exchange</span>
A HIP host implementing this specification SHOULD indicate the modes
it supports, and is willing to use, in the base exchange. The HIP
signaling message transport mode negotiation is similar to HIP NAT
traversal mode negotiation: first the Responder lists the supported
modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1
packet. The modes are listed in priority order, the more preferred
mode(s) first. If the Initiator supports, and is willing to use, any
of the modes proposed by the Responder, it selects one of the modes
by adding a HIP_TRANSPORT_MODE parameter containing the selected mode
to the I2 packet. Finally, if the Initiator selected one of the
modes and the base exchange succeeds, hosts MUST use the selected
mode for the following HIP signaling messages sent between them for
the duration of the HIP association or until another mode is
negotiated.
If the Initiator cannot, or will not, use any of the modes proposed
by the Responder, the Initiator SHOULD include an empty
HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it
supports this extension but will not use any of the proposed modes.
Depending on local policy, the Responder MAY either abort the base
exchange or continue HIP signaling without using an encrypted
connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the
parameter was empty. If the Initiator selects a mode that the
Responder does not support (and hence was not included in R1), the
Responder MUST abort the base exchange. If the base exchange is
aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the
Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE notification (see
<a href="#section-3.3">Section 3.3</a>) to the Initiator.
<span class="grey">Keranen Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 7680
Port transport layer port number (or zero if not used)
Length length in octets, excluding Type, Length, and Padding
Mode ID defines the proposed or selected transport mode(s)
The following HIP Transport Mode IDs are defined:
ID name Value
RESERVED 0
DEFAULT 1
ESP 2
ESP-TCP 3
Figure 1: Format of the HIP_TRANSPORT_MODE Parameter
The mode DEFAULT indicates that the same transport mode (e.g., plain
IP or UDP) that was used for the base exchange should be used for
subsequent HIP signaling messages. In the ESP mode, the messages are
sent as such on the encrypted ESP connection; in the ESP-TCP mode,
TCP is used within the ESP tunnel. If a mode that uses a transport
layer connection within the ESP tunnel (e.g., ESP-TCP) is offered,
the Port field MUST contain the local port number the host will use
for the connection. If none of the modes utilize a transport layer
protocol, the Port field SHOULD be set to zero when the parameter is
sent and ignored when received. The Port and Mode ID fields are
encoded as unsigned integers using network byte order.
The HIP_TRANSPORT_MODE parameter resides on the signed part of the
HIP packets, and hence it is covered by the signatures of the R1, I2,
and UPDATE packets.
<span class="grey">Keranen Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Mode Negotiation after the HIP Base Exchange</span>
If a HIP host wants to change to a different transport mode (or start
using a transport mode) some time after the base exchange, it sends a
HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter containing the
mode(s) it would prefer to use. The host receiving the UPDATE SHOULD
respond with an UPDATE packet containing the mode that is selected as
in the negotiation during the base exchange. If the receiving host
does not support, or is not willing to use, any of the listed modes,
it SHOULD respond with an UPDATE packet where the HIP_TRANSPORT_MODE
parameter contains only the currently used transport mode (even if
that was not included in the previous UPDATE packet) and continue
using that mode.
Since the HIP_TRANSPORT_MODE parameter's type is not critical (as
defined in <a href="./rfc5201#section-5.2.1">Section 5.2.1 of [RFC5201]</a>), a host not supporting this
extension would simply reply with an acknowledgement UPDATE packet
without a HIP_TRANSPORT_MODE parameter. In such a case, depending on
local policy as in mode negotiation during the base exchange, the
host that requested the new transport mode MAY close the HIP
association. If the association is closed, the host closing the
association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet
to the other host before closing the association.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Error Notifications</span>
During a HIP signaling transport mode negotiation, if a
HIP_TRANSPORT_MODE parameter does not contain any mode that the
receiving host is willing to use, or a HIP_TRANSPORT_MODE parameter
does not exist in a HIP packet where the receiving host expected to
see it, the receiving host MAY send back a NOTIFY packet with a
NOTIFICATION parameter [<a href="./rfc5201" title=""Host Identity Protocol"">RFC5201</a>] error type
NO_VALID_HIP_TRANSPORT_MODE (value 100). The Notification Data field
for the error notifications SHOULD contain the HIP header of the
rejected packet.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. HIP Messages on Encrypted Connections</span>
This specification defines two different transport modes for sending
HIP packets over encrypted ESP connections. These modes require that
the ESP transport format [<a href="./rfc5202" title=""Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)"">RFC5202</a>] is negotiated to be used between
the hosts. If the ESP transport format is not used, these modes MUST
NOT be offered in the HIP_TRANSPORT_MODE parameter. If a
HIP_TRANSPORT_MODE parameter containing an ESP transport mode is
received but the ESP transport format is not used, a host MUST NOT
select such a mode but act as specified in <a href="#section-3.1">Section 3.1</a> (if performing
a base exchange) or <a href="#section-3.2">Section 3.2</a> (if performing an UPDATE) when no
valid mode is offered.
<span class="grey">Keranen Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
The ESP mode provides simple protection for all the signaling traffic
and can be used as a generic replacement for the DEFAULT mode in
cases where all signaling traffic should be encrypted. If the HIP
messages may become so large that they would need to be fragmented,
e.g., because of HIP certificates [<a href="./rfc6253" title=""Host Identity Protocol Certificates"">RFC6253</a>] or DATA messages
[<a href="./rfc6078" title=""Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)"">RFC6078</a>], it is RECOMMENDED to use the ESP-TCP mode that can handle
message fragmentation at the TCP level instead of relying on IP-level
fragmentation.
When HIP NAT traversal [<a href="./rfc5770" title=""Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators"">RFC5770</a>] is used, the ESP and HIP packets are
sent UDP encapsulated. The use of different NAT traversal modes, and
in particular UDP encapsulation, is independent of the transport mode
(as specified in this document) of HIP packets. However, when HIP
packets are sent over an ESP connection, no additional UDP
encapsulation (i.e., within the ESP connection) for the HIP packets
is needed and MUST NOT be used since the ESP packets are already UDP
encapsulated, if needed for NAT traversal. For example, if UDP
encapsulation is used as defined in [<a href="./rfc5770" title=""Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators"">RFC5770</a>], and the ESP-TCP
transport mode is used as defined in this document, the HIP packets
are sent over IP, UDP, ESP, and TCP (in that order).
HIP messages that result in changing or generating new keying
material, i.e., the base exchange and re-keying UPDATE messages, MUST
NOT be sent over the encrypted connection that is created using the
keying material that is being changed, nor over an encrypted
connection using the newly created keying material.
It should be noted that when HIP messages are sent using an encrypted
connection, on-path network elements (e.g., firewalls and HIP-aware
NATs) that would normally see the HIP headers and contents of the
unencrypted parameters, cannot see any part of the messages unless
they have access to the encryption keying material. The original HIP
design made an explicit decision to expose some of this information
to HIP-aware NATs. If an encrypted transport mode is used, only the
base exchange or update without encryption is visible to such NATs.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. ESP Mode</span>
If the ESP mode is selected in the base exchange, both hosts MUST
listen for incoming HIP signaling messages and send outgoing messages
on the encrypted connection. The ESP header's next header value for
HIP messages sent over ESP MUST be set to HIP (139).
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. ESP-TCP Mode</span>
If the ESP-TCP mode is selected, the host with the larger HIT
(calculated as defined in <a href="./rfc5201#section-6.5">Section 6.5 of [RFC5201]</a>) MUST start to
listen for an incoming TCP connection on the encrypted connection
<span class="grey">Keranen Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
(i.e., to the HIT of the host) on the port it used in the Port field
of the transport mode parameter. The other host MUST create a TCP
connection to that port and the host MAY use the port it sent in the
transport mode parameter as the source port for the connection. Once
the TCP connection is established, both hosts MUST listen for
incoming HIP signaling messages and send the outgoing messages using
the TCP connection. The ESP next header value for messages sent
using the ESP-TCP mode TCP connections MUST be set to TCP (6).
If the hosts are unable to create the TCP connection, the host that
initiated the mode negotiation MUST restart the negotiation with the
UPDATE message and SHOULD NOT propose the ESP-TCP mode. If local
policy does not allow use of any mode other than ESP-TCP, the HIP
association SHOULD be closed. The UPDATE or CLOSE message MUST be
sent using the same transport mode that was used for negotiating the
use of the ESP-TCP mode.
Since TCP provides reliable transport, the HIP messages sent over TCP
MUST NOT be retransmitted. Instead, a host SHOULD wait to detect
that the TCP connection has failed to retransmit the packet
successfully in a timely manner (such detection is platform- and
policy-specific) before concluding that there is no response.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Recovering from Failed Encrypted Connections</span>
If the encrypted connection fails for some reason, it can no longer
be used for HIP signaling and the hosts SHOULD re-establish the
connection using HIP messages that are sent outside of the encrypted
connection. Hence, while listening for incoming HIP messages on the
encrypted connection, hosts MUST still accept incoming HIP messages
using the same transport method (e.g., UDP or plain IP) that was used
for the base exchange. When responding to a HIP message sent outside
of the encrypted connection, the response MUST be sent using the same
transport method as the original message used. If encryption was
previously used, hosts SHOULD send outside of the encrypted
connection only HIP messages that are used to re-establish the
encrypted connection. In particular, when the policy requires that
only encrypted messages (e.g., DATA messages using an encrypted
transport mode) be sent, they MUST be sent using an encrypted
connection. Note that a policy MUST NOT prevent sending unencrypted
UPDATE messages used for re-establishing the encrypted connection,
since that would prevent recovering from failed encrypted
connections.
The UPDATE messages used for re-establishing the encrypted connection
MUST contain a HIP_TRANSPORT_MODE parameter and the negotiation
proceeds as described in <a href="#section-3.2">Section 3.2</a>.
<span class="grey">Keranen Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Host Mobility and Multihoming</span>
If a host obtains a new address, a new Security Association (SA) pair
may be created for (or an existing SA pair may be moved to) the new
address, as described in [<a href="./rfc5206" title=""End- Host Mobility and Multihoming with the Host Identity Protocol"">RFC5206</a>]. If the ESP or ESP-TCP transport
mode is used, HIP signaling continues using the (new) SA pair and the
same transport mode as before.
With the ESP mode, the first mobility UPDATE message SHOULD be sent
using the old SA, and the following messages, including the response
to the first UPDATE, SHOULD be sent using the new SAs.
Retransmissions of the UPDATE messages use the same SA as the
original message. If the ESP-TCP mode is used, the HIP signaling TCP
connection is moved to the new SA pair like any other TCP connection.
However, the mobility UPDATE messages SHOULD NOT be sent over the TCP
connection, but using plain ESP as in the ESP mode, and consequently
hosts MUST be prepared to receive UPDATE messages over plain ESP even
if the ESP-TCP mode is used.
In some cases, the host may not be able to send the mobility UPDATE
messages using the encrypted connection before it breaks. This
results in a similar situation as if the encrypted connection had
failed and the hosts need to renegotiate the new addresses using
unencrypted UPDATE messages and possibly rendezvous [<a href="./rfc5204" title=""Host Identity Protocol (HIP) Rendezvous Extension"">RFC5204</a>] or HIP
relay [<a href="./rfc5770" title=""Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators"">RFC5770</a>] servers. Also, these UPDATE messages MUST contain
the HIP_TRANSPORT_MODE parameter and perform the transport mode
negotiation.
Examples of the signaling flows with mobility and multihoming are
shown in <a href="#appendix-A">Appendix A</a>.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
By exchanging the HIP messages over an ESP connection, all HIP
signaling data (after the base exchange but excluding keying material
(re)negotiation and some of the mobility UPDATE messages) will be
encrypted, but only if NULL encryption is not used. Thus, a host
requiring confidentiality for the HIP signaling messages must check
that encryption is negotiated for use on the ESP connection.
Moreover, the level of protection provided by the ESP transport modes
depends on the selected ESP transform; see [<a href="./rfc5202" title=""Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)"">RFC5202</a>] and [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>]
for security considerations of the different ESP transforms.
While this extension to HIP allows for negotiation of security
features, there is no risk of downgrade attacks since the mode
negotiation happens using signed (R1/I2 or UPDATE) packets and only
after both hosts have been securely identified in the base exchange.
If an attacker would attempt to change the modes listed in the
<span class="grey">Keranen Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
HIP_TRANSPORT_MODE parameter, that would break the signatures and the
base exchange (or update) would not complete. Furthermore, since
both "secure" modes (ESP and ESP-TCP) defined in this document are
equally secure, the only possible downgrade attack would be to make
both hosts accept the DEFAULT mode. If the local policy (of either
host) requires using a secure mode, the base exchange or update would
again simply fail (as described in <a href="#section-3.1">Section 3.1</a>).
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika
Komu, Jan Melen, and Tobias Heer for reviews and comments.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
This section is to be interpreted according to [<a href="./rfc5226" title="">RFC5226</a>].
This document updates the IANA maintained "Host Identity Protocol
(HIP) Parameters" registry [<a href="./rfc5201" title=""Host Identity Protocol"">RFC5201</a>] by assigning a new HIP Parameter
Type value (7680) for the HIP_TRANSPORT_MODE parameter (defined in
<a href="#section-3.1">Section 3.1</a>).
The HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields
for different modes, for which IANA has created and now maintains a
new sub-registry entitled "HIP Transport Modes" under the "Host
Identity Protocol (HIP) Parameters" registry. Initial values for the
transport mode registry are given in <a href="#section-3.1">Section 3.1</a>; future assignments
are to be made through IETF Review or IESG Approval [<a href="./rfc5226" title="">RFC5226</a>].
Assignments consist of a transport mode identifier name and its
associated value.
This document also defines a new HIP NOTIFICATION message type
[<a href="./rfc5201" title=""Host Identity Protocol"">RFC5201</a>] NO_VALID_HIP_TRANSPORT_MODE (100) in <a href="#section-3.3">Section 3.3</a>.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC5201">RFC5201</a>] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", <a href="./rfc5201">RFC 5201</a>, April 2008.
[<a id="ref-RFC5202">RFC5202</a>] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", <a href="./rfc5202">RFC 5202</a>, April 2008.
<span class="grey">Keranen Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informational References</span>
[<a id="ref-RFC4303">RFC4303</a>] Kent, S., "IP Encapsulating Security Payload (ESP)",
<a href="./rfc4303">RFC 4303</a>, December 2005.
[<a id="ref-RFC5204">RFC5204</a>] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", <a href="./rfc5204">RFC 5204</a>, April 2008.
[<a id="ref-RFC5206">RFC5206</a>] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", <a href="./rfc5206">RFC 5206</a>, April 2008.
[<a id="ref-RFC5770">RFC5770</a>] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", <a href="./rfc5770">RFC 5770</a>,
April 2010.
[<a id="ref-RFC6078">RFC6078</a>] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", <a href="./rfc6078">RFC 6078</a>, January 2011.
[<a id="ref-RFC6253">RFC6253</a>] Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", <a href="./rfc6253">RFC 6253</a>, May 2011.
<span class="grey">Keranen Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Mobility and Multihoming Examples</span>
When changing interfaces due to mobility or multihoming, the hosts
use HIP messages to notify the other host about the new address and
to check that the host with the new address is still reachable. The
following examples show the signaling performed during the address
change in two different scenarios. Note that not all HIP parameters
nor all the content of the parameters is shown in the examples. This
section and the examples are not normative; for normative behavior,
see previous sections.
In the examples, host A uses two different addresses (a1 and a2)
while host B has just a single address (b1). In the first example,
"Make before Break" (Figure 2), host A starts to use the new address
but can still use the old address (due to multihoming) for signaling.
In the second example, "Break before Make" (Figure 3), host A loses
the first address before obtaining the second address (e.g., due to
mobility), and the mobility HIP signaling is done without the
encrypted connection.
The following notations are used in the examples:
o ESPx(y): data y sent encapsulated in ESP with SA x; if ESP-
encapsulation is not used, the data is sent over plain IP or UDP
o UPDATE(x,y,z): HIP UPDATE message [<a href="./rfc5201" title=""Host Identity Protocol"">RFC5201</a>] with parameters x,y,z
o LOCATOR(x): HIP LOCATOR parameter [<a href="./rfc5206" title=""End- Host Mobility and Multihoming with the Host Identity Protocol"">RFC5206</a>] with locator x
o ESP_INFO(x,y): HIP ESP_INFO parameter [<a href="./rfc5202" title=""Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)"">RFC5202</a>] with "old SPI"
value x and "new SPI" value y
o ACK, ECHO_REQ, and ECHO_RSP: HIP ACK, ECHO_REQUEST, and
ECHO_RESPONSE parameters [<a href="./rfc5201" title=""Host Identity Protocol"">RFC5201</a>]
<span class="grey">Keranen Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
A B
ESP1(...)
a1 <----------------------------------------------> b1
ESP1(UPDATE(LOCATOR(a2), ESP_INFO(0,SPI2a)))
a1 -----------------------------------------------> b1
(A and B create SAs a2 <-> b1 (ESP2)
retransmissions of the first UPDATE
happen over ESP1)
ESP2(UPDATE(ACK, ESP_INFO(0,SPI2b), ECHO_REQ)))
a2 <----------------------------------------------- b1
ESP2(UPDATE(ACK, ECHO_RSP))
a2 -----------------------------------------------> b1
ESP2(...)
a2 <----------------------------------------------> b1
Figure 2: Make Before Break
A B
ESP1(...)
a1 <----------------------------------------------> b1
(A moves from a1 to a2)
UPDATE(LOCATOR(a2), ESP_INFO(SPI1a, SPI1a))
a2 -----------------------------------------------> b1
UPDATE(ACK, ECHO_REQ, ESP_INFO(SPI1b,SPI1b))
a2 <----------------------------------------------- b1
UPDATE(ACK, ECHO_RSP)
a2 -----------------------------------------------> b1
(A and B move ESP1 SAs to a2 <-> b1)
ESP1(...)
a2 <----------------------------------------------> b1
Figure 3: Break Before Make
When the ESP-TCP mode is used, the signaling flows are similar since
TCP is not used for the mobility UPDATE messages as described in
<a href="#section-6">Section 6</a>.
<span class="grey">Keranen Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6261">RFC 6261</a> HIP Encrypted Signaling Transport Modes May 2011</span>
Author's Address
Ari Keranen
Ericsson
Hirsalantie 11
02420 Jorvas
Finland
EMail: ari.keranen@ericsson.com
Keranen Experimental [Page 13]
</pre>
|
