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
|
<pre>Internet Engineering Task Force (IETF) X. Fu
Request for Comments: 6084 C. Dickmann
Category: Experimental University of Goettingen
ISSN: 2070-1721 J. Crowcroft
University of Cambridge
January 2011
<span class="h1">General Internet Signaling Transport (GIST)</span>
<span class="h1">over Stream Control Transmission Protocol (SCTP)</span>
<span class="h1">and Datagram Transport Layer Security (DTLS)</span>
Abstract
The General Internet Signaling Transport (GIST) protocol currently
uses TCP or Transport Layer Security (TLS) over TCP for Connection
mode operation. This document describes the usage of GIST over the
Stream Control Transmission Protocol (SCTP) and Datagram Transport
Layer Security (DTLS).
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/rfc6084">http://www.rfc-editor.org/info/rfc6084</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
<span class="grey">Fu, et al. Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology and Abbreviations . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. GIST over SCTP . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Message Association Setup . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1.1">3.1.1</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1.2">3.1.2</a>. Protocol-Definition: Forwards-SCTP . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Effect on GIST State Maintenance . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.4">3.4</a>. API between GIST and NSLP . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5">5</a>. Application of GIST over SCTP . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. Multihoming Support of SCTP . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. Streaming Support in SCTP . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9">9</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-10">10</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="grey">Fu, et al. Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document describes the usage of the General Internet Signaling
Transport (GIST) protocol [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>] and Datagram Transport Layer Security
(DTLS) [<a href="#ref-2" title=""Datagram Transport Layer Security"">2</a>].
GIST, in its initial specification for Connection mode (C-mode)
operation, runs on top of a byte-stream-oriented transport protocol
providing a reliable, in-sequence delivery, i.e., using the
Transmission Control Protocol (TCP) [<a href="#ref-9" title=""Transmission Control Protocol"">9</a>] for signaling message
transport. However, some Next Steps in Signaling (NSIS) Signaling
Layer Protocol (NSLP) [<a href="#ref-10" title=""Next Steps in Signaling (NSIS): Framework"">10</a>] context information has a definite
lifetime; therefore, the GIST transport protocol could benefit from
flexible retransmission, so stale NSLP messages that are held up by
congestion can be dropped. Together with the head-of-line blocking
and multihoming issues with TCP, these considerations argue that
implementations of GIST should support SCTP as an optional transport
protocol for GIST. Like TCP, SCTP supports reliability, congestion
control, and fragmentation. Unlike TCP, SCTP provides a number of
functions that are desirable for signaling transport, such as
multiple streams and multiple IP addresses for path failure recovery.
Furthermore, SCTP offers an advantage of message-oriented transport
instead of using the byte-stream-oriented TCP where the framing
mechanisms must be provided separately. In addition, its Partial
Reliability extension (PR-SCTP) [<a href="#ref-3" title=""Stream Control Transmission Protocol (SCTP) Partial Reliability Extension"">3</a>] supports partial retransmission
based on a programmable retransmission timer. Furthermore, DTLS
provides a viable solution for securing SCTP [<a href="#ref-4" title=""Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)"">4</a>], which allows SCTP
to use almost all of its transport features and its extensions.
This document defines the use of SCTP as the underlying transport
protocol for GIST and the use of DTLS as a security mechanism for
protecting GIST Messaging Associations and discusses the implications
on GIST state maintenance and API between GIST and NSLPs.
Furthermore, this document describes how GIST is transported over
SCTP and used by NSLPs in order to exploit the additional
capabilities offered by SCTP to deliver GIST C-mode messages more
effectively. More specifically:
o How to use the multiple streams feature of SCTP.
o How to use the PR-SCTP extension of SCTP.
o How to take advantage of the multihoming support of SCTP.
GIST over SCTP as described in this document does not require any
changes to the high-level operation and structure of GIST. However,
adding new transport options requires additional interface code and
configuration support to allow applications to exploit the additional
<span class="grey">Fu, et al. Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
transport when appropriate. In addition, SCTP implementations to
transport GIST MUST support the optional feature of fragmentation of
SCTP user messages.
Additionally, this document also specifies how to establish GIST
security using DTLS for use in combination with, e.g., SCTP and UDP.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology and Abbreviations</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="#ref-5" title=""Key words for use in RFCs to Indicate Requirement Levels"">5</a>]. Other
terminologies and abbreviations used in this document are taken from
related specifications ([<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>], [<a href="#ref-2" title=""Datagram Transport Layer Security"">2</a>], [<a href="#ref-3" title=""Stream Control Transmission Protocol (SCTP) Partial Reliability Extension"">3</a>], [<a href="#ref-6" title=""Stream Control Transmission Protocol"">6</a>]):
o SCTP - Stream Control Transmission Protocol
o PR-SCTP - SCTP Partial Reliability Extension
o MRM - Message Routing Method
o MRI - Message Routing Information
o SCD - Stack-Configuration-Data
o Messaging Association (MA) - A single connection between two
explicitly identified GIST adjacent peers, i.e., between a given
signaling source and destination address. A messaging association
may use a transport protocol; if security protection is required,
it may use a specific network layer security association, or use a
transport layer security association internally. A messaging
association is bidirectional: signaling messages can be sent over
it in either direction, referring to flows of either direction.
o SCTP Association - A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information.
An association can be uniquely identified by the transport
addresses used by the endpoints in the association. Two SCTP
endpoints MUST NOT have more than one SCTP association between
them at any given time.
o Stream - A unidirectional logical channel established from one to
another associated SCTP endpoint, within which all user messages
are delivered in sequence except for those submitted to the
unordered delivery service.
<span class="grey">Fu, et al. Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. GIST over SCTP</span>
This section defines a new MA-Protocol-ID type, "Forwards-SCTP", for
using SCTP as the GIST transport protocol. The use of DTLS in GIST
is defined in <a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Message Association Setup</span>
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Overview</span>
The basic GIST protocol specification defines two possible protocols
to be used in Messaging Associations, namely Forwards-TCP and TLS.
This information is a main part of the Stack Configuration Data (SCD)
[<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>]. This section adds Forwards-SCTP (value 3) as another possible
protocol option. In Forwards-SCTP, analog to Forwards-TCP,
connections between peers are opened in the forwards direction, from
the querying node, towards the responder.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Protocol-Definition: Forwards-SCTP</span>
The MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP
between peers. Support for this protocol is OPTIONAL. If this
protocol is offered, MA-protocol-options data MUST also be carried in
the SCD object. The MA-protocol-options field formats are:
o in a Query: no information apart from the field header.
o in a Response: 2-byte port number at which the connection will be
accepted, followed by 2 pad bytes.
The connection is opened in the forwards direction, from the querying
node towards the responder. The querying node MAY use any source
address and source port. The destination for establishing the
message association MUST be derived from information in the Response:
the address from the interface-address in the Network-Layer-
Information object and the port from the SCD object as described
above.
Associations using Forwards-SCTP can carry messages with the transfer
attribute Reliable=True. If an error occurs on the SCTP connection
such as a reset, as can be reported by an SCTP socket API
notification [<a href="#ref-11" title=""Sockets API Extensions for Stream Control Transmission Protocol (SCTP)"">11</a>], GIST MUST report this to NSLPs as discussed in
Section 4.1.2 of [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>]. For the multihoming scenario, when a
destination address of a GIST-over-SCTP peer encounters a change, the
SCTP API will notify GIST about the availability of different SCTP
endpoint addresses and the possible change of the primary path.
<span class="grey">Fu, et al. Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Effect on GIST State Maintenance</span>
As SCTP provides additional functionality over TCP, this section
discusses the implications of using GIST over SCTP on GIST state
maintenance.
While SCTP defines unidirectional streams, for the purpose of this
document, the concept of a bidirectional stream is used.
Implementations MUST establish both downstream and upstream
(unidirectional) SCTP streams and use the same stream identifier in
both directions. Thus, the two unidirectional streams (in opposite
directions) form a bidirectional stream.
Due to the multi-streaming support of SCTP, it is possible to use
different SCTP streams for different resources (e.g., different NSLP
sessions), rather than maintaining all messages along the same
transport connection/association in a correlated fashion as TCP
(which imposes strict (re)ordering and reliability per transport
level). However, there are limitations to the use of multi-
streaming. When an SCTP implementation is used for GIST transport,
all GIST messages for a particular session MUST be sent over the same
SCTP stream to assure the NSLP assumption of in-order delivery.
Multiple sessions MAY share the same SCTP stream based on local
policy.
The GIST concept of Messaging Association re-use is not affected by
this document or the use of SCTP. All rules defined in the GIST
specification remain valid in the context of GIST over SCTP.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. PR-SCTP Support</span>
A variant of SCTP, PR-SCTP [<a href="#ref-3" title=""Stream Control Transmission Protocol (SCTP) Partial Reliability Extension"">3</a>] provides a "timed reliability"
service, which would be particularly useful for delivering GIST
Connection mode messages. It allows the user to specify, on a per-
message basis, the rules governing how persistent the transport
service should be in attempting to send the message to the receiver.
Because of the chunk bundling function of SCTP, reliable and
partially reliable messages can be multiplexed over a single PR-SCTP
association. Therefore, an SCTP implementation for GIST transport
SHOULD attempt to establish a PR-SCTP association using "timed
reliability" service instead of a standard SCTP association, if
available, to support more flexible transport features for potential
needs of different NSLPs.
When using a normally reliable session (as opposed to a partially
reliable session), if a node has sent the first transmission before
the lifetime expires, then the message MUST be sent as a normal
reliable message. During episodes of congestion, this is
<span class="grey">Fu, et al. Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
particularly unfortunate, as retransmission wastes bandwidth that
could have been used for other (non-lifetime expired) messages. The
"timed reliability" service in PR-SCTP eliminates this issue and is
hence RECOMMENDED to be used for GIST over PR-SCTP.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. API between GIST and NSLP</span>
The GIST specification defines an abstract API between GIST and
NSLPs. While this document does not change the API itself, the
semantics of some parameters have slightly different interpretations
in the context of SCTP. This section only lists those primitives and
parameters that need special consideration when used in the context
of SCTP. The relevant primitives from [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>] are as follows:
o The Timeout parameter in API "SendMessage": According to [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>], this
parameter represents the "length of time GIST should attempt to
send this message before indicating an error". When used with
PR-SCTP, this parameter is used as the timeout for the "timed
reliability" service of PR-SCTP.
o "NetworkNotification": According to [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>], this primitive "is passed
from GIST to a signalling application. It indicates that a
network event of possible interest to the signalling application
occurred". Here, if SCTP detects a failure of the primary path,
GIST SHOULD also indicate this event to the NSLP by calling this
primitive with Network-Notification-Type "Routing Status Change".
This notification should be done even if SCTP was able to retain
an open connection to the peer due to its multihoming
capabilities.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Bit-Level Formats</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. MA-Protocol-Options</span>
This section provides the bit-level format for the MA-protocol-
options field that is used for SCTP protocol in the Stack-
Configuration-Data object of GIST.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SCTP port number | Reserved :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCTP port number = Port number at which the responder will accept
SCTP connections
The SCTP port number is only supplied if sent by the responder.
<span class="grey">Fu, et al. Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Application of GIST over SCTP</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Multihoming Support of SCTP</span>
In general, the multihoming support of SCTP can be used to improve
fault-tolerance in case of a path or link failure. Thus, GIST over
SCTP would be able to deliver NSLP messages between peers even if the
primary path is not working anymore. However, for the Message
Routing Methods (MRMs) defined in the basic GIST specification, such
a feature is only of limited use. The default MRM is path-coupled,
which means that if the primary path is failing for the SCTP
association, it most likely is also failing for the IP traffic that
is signaled for. Thus, GIST would need to perform a refresh to the
NSIS nodes to the alternative path anyway to cope with the route
change. When the two endpoints of a multihomed SCTP association (but
none of the intermediate nodes between them) support NSIS, GIST over
SCTP provides a robust means for GIST to deliver NSLP messages even
when the primary path fails but at least one alternative path between
these (NSIS-enabled) endpoints of the multihomed path is available.
Additionally, the use of the multihoming support of SCTP provides
GIST and the NSLP with another source to detect route changes.
Furthermore, for the time between detection of the route change and
recovering from it, the alternative path offered by SCTP can be used
by the NSLP to make the transition more smoothly. Finally, future
MRMs might have different properties and therefore benefit from
multihoming more broadly.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Streaming Support in SCTP</span>
Streaming support in SCTP is advantageous for GIST. It allows better
parallel processing, in particular by avoiding the head-of-line
blocking issue in TCP. Since a single GIST MA may be reused by
multiple sessions, using TCP as the transport for GIST signaling
messages belonging to different sessions may be blocked if another
message is dropped. In the case of SCTP, this can be avoided, as
different sessions having different requirements can belong to
different streams; thus, a message loss or reordering in a stream
will only affect the delivery of messages within that particular
stream, and not any other streams.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. NAT Traversal Issue</span>
NAT traversal for GIST over SCTP will follow Section 7.2 of [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>] and
the GIST extensibility capabilities defined in [<a href="#ref-12" title=""Using and Extending the NSIS Protocol Family"">12</a>]. This
specification does not define NAT traversal procedures for GIST over
SCTP, although an approach for SCTP NAT traversal is described in
[<a href="#ref-13" title=""Stream Control Transmission Protocol (SCTP) Network Address Translation"">13</a>].
<span class="grey">Fu, et al. Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Use of DTLS with GIST</span>
This section specifies a new MA-Protocol-ID "DTLS" (value 4) for the
use of DTLS in GIST, which denotes a basic use of datagram transport
layer channel security, initially in conjunction with GIST over SCTP.
It provides server (i.e., GIST transport receiver) authentication and
integrity (as long as the NULL ciphersuite is not selected during
ciphersuite negotiation), as well as optionally replay protection for
control packets. The use of DTLS for securing GIST over SCTP allows
GIST to take the advantage of features provided by SCTP and its
extensions. The usage of DTLS for GIST over SCTP is similar to TLS
for GIST as specified in [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>], where a stack-proposal containing both
MA-Protocol-IDs for SCTP and DTLS during the GIST handshake phase.
The usage of DTLS [<a href="#ref-2" title=""Datagram Transport Layer Security"">2</a>] for securing GIST over datagram transport
protocols MUST be implemented and SHOULD be used.
GIST message associations using DTLS may carry messages with transfer
attributes requesting confidentiality or integrity protection. The
specific DTLS version will be negotiated within the DTLS layer
itself, but implementations MUST NOT negotiate to protocol versions
prior to DTLS v1.0 and MUST use the highest protocol version
supported by both peers. NULL authentication and integrity ciphers
MUST NOT be negotiated for GIST nodes supporting DTLS. For
confidentiality ciphers, nodes can negotiate the NULL ciphersuites.
The same rules for negotiating TLS ciphersuites as specified in
Section 5.7.3 of [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>] apply.
DTLS renegotiation [<a href="#ref-7" title=""Transport Layer Security (TLS) Renegotiation Indication Extension"">7</a>] may cause problems for applications such that
connection security parameters can change without the application
knowing it. Hence, it is RECOMMENDED that renegotiation be disabled
for GIST over DTLS.
No MA-protocol-options field is required for DTLS. The configuration
information for the transport protocol over which DTLS is running
(e.g., SCTP port number) is provided by the MA-protocol-options for
that protocol.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The security considerations of [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>], [<a href="#ref-6" title=""Stream Control Transmission Protocol"">6</a>], and [<a href="#ref-2" title=""Datagram Transport Layer Security"">2</a>] apply.
Additionally, although [<a href="#ref-4" title=""Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)"">4</a>] does not support replay detection in DTLS
over SCTP, the SCTP replay protection mechanisms [<a href="#ref-6" title=""Stream Control Transmission Protocol"">6</a>] [<a href="#ref-8" title=""Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)"">8</a>] should be
able to protect NSIS messages transported using GIST over (DTLS over)
SCTP from replay attacks.
<span class="grey">Fu, et al. Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
According to this specification, IANA has registered the following
codepoints (MA-Protocol-IDs) in a registry created by [<a href="#ref-1" title=""GIST: General Internet Signalling Transport"">1</a>]:
+---------------------+------------------------------------------+
| MA-Protocol-ID | Protocol |
+---------------------+------------------------------------------+
| 3 | SCTP opened in the forwards direction |
| | |
| 4 | DTLS initiated in the forwards direction |
+---------------------+------------------------------------------+
Note that MA-Protocol-ID "DTLS" is never used alone but always
coupled with a transport protocol specified in the stack proposal.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
The authors would like to thank John Loughney, Jukka Manner, Magnus
Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert
Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan
Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their
helpful suggestions.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", <a href="./rfc5971">RFC 5971</a>, October 2010.
[<a id="ref-2">2</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", <a href="./rfc4347">RFC 4347</a>, April 2006.
[<a id="ref-3">3</a>] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad,
"Stream Control Transmission Protocol (SCTP) Partial
Reliability Extension", <a href="./rfc3758">RFC 3758</a>, May 2004.
[<a id="ref-4">4</a>] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control Transmission
Protocol (SCTP)", <a href="./rfc6083">RFC 6083</a>, January 2011.
[<a id="ref-5">5</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-6">6</a>] Stewart, R., "Stream Control Transmission Protocol", <a href="./rfc4960">RFC 4960</a>,
September 2007.
<span class="grey">Fu, et al. Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
[<a id="ref-7">7</a>] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport
Layer Security (TLS) Renegotiation Indication Extension",
<a href="./rfc5746">RFC 5746</a>, February 2010.
[<a id="ref-8">8</a>] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", <a href="./rfc4895">RFC 4895</a>, August 2007.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-9">9</a>] Postel, J., "Transmission Control Protocol", STD 7, <a href="./rfc793">RFC 793</a>,
September 1981.
[<a id="ref-10">10</a>] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", <a href="./rfc4080">RFC 4080</a>,
June 2005.
[<a id="ref-11">11</a>] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei,
"Sockets API Extensions for Stream Control Transmission
Protocol (SCTP)", Work in Progress, January 2011.
[<a id="ref-12">12</a>] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and
Extending the NSIS Protocol Family", <a href="./rfc5978">RFC 5978</a>, October 2010.
[<a id="ref-13">13</a>] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
Transmission Protocol (SCTP) Network Address Translation", Work
in Progress, December 2010.
<span class="grey">Fu, et al. Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6084">RFC 6084</a> GIST over SCTP and DTLS January 2011</span>
Authors' Addresses
Xiaoming Fu
University of Goettingen
Institute of Computer Science
Goldschmidtstr. 7
Goettingen 37077
Germany
EMail: fu@cs.uni-goettingen.de
Christian Dickmann
University of Goettingen
Institute of Computer Science
Goldschmidtstr. 7
Goettingen 37077
Germany
EMail: mail@christian-dickmann.de
Jon Crowcroft
University of Cambridge
Computer Laboratory
William Gates Building
15 JJ Thomson Avenue
Cambridge CB3 0FD
UK
EMail: jon.crowcroft@cl.cam.ac.uk
Fu, et al. Experimental [Page 12]
</pre>
|
