draft-ietf-tram-turnbis-21.txt   draft-ietf-tram-turnbis-22.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft McAfee Internet-Draft McAfee
Obsoletes: 5766,6156 (if approved) A. Johnston, Ed. Obsoletes: 5766, 6156 (if approved) A. Johnston, Ed.
Intended status: Standards Track Rowan University Intended status: Standards Track Villanova University
Expires: August 22, 2019 P. Matthews Expires: August 31, 2019 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
February 18, 2019 February 27, 2019
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN) Traversal Utilities for NAT (STUN)
draft-ietf-tram-turnbis-21 draft-ietf-tram-turnbis-22
Abstract Abstract
If a host is located behind a NAT, then in certain situations it can If a host is located behind a NAT, then in certain situations it can
be impossible for that host to communicate directly with other hosts be impossible for that host to communicate directly with other hosts
(peers). In these situations, it is necessary for the host to use (peers). In these situations, it is necessary for the host to use
the services of an intermediate node that acts as a communication the services of an intermediate node that acts as a communication
relay. This specification defines a protocol, called TURN (Traversal relay. This specification defines a protocol, called TURN (Traversal
Using Relays around NAT), that allows the host to control the Using Relays around NAT), that allows the host to control the
operation of the relay and to exchange packets with its peers using operation of the relay and to exchange packets with its peers using
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 22, 2019. This Internet-Draft will expire on August 31, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12 2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16 2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 17
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18 2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18
2.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18 2.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 21 4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 21
4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 21 4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 21
5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21 5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21
6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25 7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25
7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25 7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25
7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27 7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27
7.3. Receiving an Allocate Success Response . . . . . . . . . 32 7.3. Receiving an Allocate Success Response . . . . . . . . . 32
7.4. Receiving an Allocate Error Response . . . . . . . . . . 32 7.4. Receiving an Allocate Error Response . . . . . . . . . . 33
8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34 8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 35
8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 35 8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 35
8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 35 8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 36
8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 36 8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 37
9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38 10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Forming a CreatePermission Request . . . . . . . . . . . 38 10.1. Forming a CreatePermission Request . . . . . . . . . . . 38
10.2. Receiving a CreatePermission Request . . . . . . . . . . 38 10.2. Receiving a CreatePermission Request . . . . . . . . . . 39
10.3. Receiving a CreatePermission Response . . . . . . . . . 39 10.3. Receiving a CreatePermission Response . . . . . . . . . 39
11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 39 11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 39
11.1. Forming a Send Indication . . . . . . . . . . . . . . . 39 11.1. Forming a Send Indication . . . . . . . . . . . . . . . 40
11.2. Receiving a Send Indication . . . . . . . . . . . . . . 40 11.2. Receiving a Send Indication . . . . . . . . . . . . . . 40
11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40 11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 41
11.4. Receiving a Data Indication . . . . . . . . . . . . . . 41 11.4. Receiving a Data Indication . . . . . . . . . . . . . . 41
11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 41 11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 42
11.6. Receiving a Data Indication with an ICMP attribute . . . 42 11.6. Receiving a Data Indication with an ICMP attribute . . . 43
12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 45 12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 45
12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 45 12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 46
12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 46 12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 47
12.4. The ChannelData Message . . . . . . . . . . . . . . . . 47 12.4. The ChannelData Message . . . . . . . . . . . . . . . . 47
12.5. Sending a ChannelData Message . . . . . . . . . . . . . 47 12.5. Sending a ChannelData Message . . . . . . . . . . . . . 48
12.6. Receiving a ChannelData Message . . . . . . . . . . . . 48 12.6. Receiving a ChannelData Message . . . . . . . . . . . . 48
12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 49 12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 49
13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 49 13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 50
13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 49 13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 50
13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 50 13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 51
13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 52 13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 52
14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 52 14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 53
15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 54 15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 55
16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 54 16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 55
16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 55 16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 55
16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 55 16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 56
16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 55 16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 56
16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 55 16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 56
16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 56 16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 56
16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 56 16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 56
16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 56 16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 57
16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 57 16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 57
16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 57 16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 58
16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 57 16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 58
16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57 16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 58
16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 58 16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 58
16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58 16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 59
17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 59 17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 59
18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 60 18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 60
19. Security Considerations . . . . . . . . . . . . . . . . . . . 68 19. Security Considerations . . . . . . . . . . . . . . . . . . . 68
19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 68 19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 68
19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 68 19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 68
19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 68 19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 68
19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 69 19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 69
19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 69 19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 69
19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 70 19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 70
19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 70 19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 70
skipping to change at page 6, line 5 skipping to change at page 6, line 5
TURN was designed as one piece in the larger ICE approach to NAT TURN was designed as one piece in the larger ICE approach to NAT
traversal. Implementors of TURN are urged to investigate ICE and traversal. Implementors of TURN are urged to investigate ICE and
seriously consider using it for their application. However, it is seriously consider using it for their application. However, it is
possible to use TURN without ICE. possible to use TURN without ICE.
TURN is an extension to the STUN (Session Traversal Utilities for TURN is an extension to the STUN (Session Traversal Utilities for
NAT) protocol [I-D.ietf-tram-stunbis]. Most, though not all, TURN NAT) protocol [I-D.ietf-tram-stunbis]. Most, though not all, TURN
messages are STUN-formatted messages. A reader of this document messages are STUN-formatted messages. A reader of this document
should be familiar with STUN. should be familiar with STUN.
The TURN specification was originally published as [RFC5766], which
was updated by [RFC6156] to add IPv6 support. This document
supersedes and obsoletes both [RFC5766] and [RFC6156].
2. Overview of Operation 2. Overview of Operation
This section gives an overview of the operation of TURN. It is non- This section gives an overview of the operation of TURN. It is non-
normative. normative.
In a typical configuration, a TURN client is connected to a private In a typical configuration, a TURN client is connected to a private
network [RFC1918] and through one or more NATs to the public network [RFC1918] and through one or more NATs to the public
Internet. On the public Internet is a TURN server. Elsewhere in the Internet. On the public Internet is a TURN server. Elsewhere in the
Internet are one or more peers with which the TURN client wishes to Internet are one or more peers with which the TURN client wishes to
communicate. These peers may or may not be behind one or more NATs. communicate. These peers may or may not be behind one or more NATs.
skipping to change at page 9, line 11 skipping to change at page 9, line 48
firewall can do is guess which flows are desired by using filtering firewall can do is guess which flows are desired by using filtering
rules. Also, TCP has explicit connection teardown; while for UDP, rules. Also, TCP has explicit connection teardown; while for UDP,
the firewall has to use timers to guess when the flow is finished. the firewall has to use timers to guess when the flow is finished.
TURN supports TLS-over-TCP transport and DTLS-over-UDP transport TURN supports TLS-over-TCP transport and DTLS-over-UDP transport
between the client and the server because (D)TLS provides additional between the client and the server because (D)TLS provides additional
security properties not provided by TURN's default digest security properties not provided by TURN's default digest
authentication; properties that some clients may wish to take authentication; properties that some clients may wish to take
advantage of. In particular, (D)TLS provides a way for the client to advantage of. In particular, (D)TLS provides a way for the client to
ascertain that it is talking to the correct server, and provides for ascertain that it is talking to the correct server, and provides for
confidentiality of TURN control messages. TURN does not require confidentiality of TURN control messages. If (D)TLS transport is
(D)TLS because the overhead of using (D)TLS is higher than that of used between the TURN client and the TURN server, the guidance given
digest authentication; for example, using (D)TLS likely means that in [RFC7525] MUST be followed to avoid attacks on (D)TLS. TURN does
most application data will be doubly encrypted (once by (D)TLS and not require (D)TLS because the overhead of using (D)TLS is higher
once to ensure it is still encrypted in the UDP datagram). than that of digest authentication; for example, using (D)TLS likely
means that most application data will be doubly encrypted (once by
(D)TLS and once to ensure it is still encrypted in the UDP datagram).
There is an extension to TURN for TCP transport between the server There is an extension to TURN for TCP transport between the server
and the peers [RFC6062]. For this reason, allocations that use UDP and the peers [RFC6062]. For this reason, allocations that use UDP
between the server and the peers are known as UDP allocations, while between the server and the peers are known as UDP allocations, while
allocations that use TCP between the server and the peers are known allocations that use TCP between the server and the peers are known
as TCP allocations. This specification describes only UDP as TCP allocations. This specification describes only UDP
allocations. allocations.
In some applications for TURN, the client may send and receive In some applications for TURN, the client may send and receive
packets other than TURN packets on the host transport address it uses packets other than TURN packets on the host transport address it uses
skipping to change at page 21, line 6 skipping to change at page 21, line 25
Realm: A string used to describe the server or a context within the Realm: A string used to describe the server or a context within the
server. The realm tells the client which username and password server. The realm tells the client which username and password
combination to use to authenticate requests. combination to use to authenticate requests.
Nonce: A string chosen at random by the server and included in the Nonce: A string chosen at random by the server and included in the
message-digest. To prevent replay attacks, the server should message-digest. To prevent replay attacks, the server should
change the nonce regularly. change the nonce regularly.
(D)TLS: This term is used for statements that apply to both (D)TLS: This term is used for statements that apply to both
Transport Layer Security [RFC5246] and Datagram Transport Layer Transport Layer Security [RFC5246] [RFC8446] and Datagram
Security [RFC6347]. Transport Layer Security [RFC6347] [I-D.ietf-tls-dtls13].
4. Discovery of TURN server 4. Discovery of TURN server
Methods of TURN server discovery, including using anycast, are Methods of TURN server discovery, including using anycast, are
described in [RFC8155]. The syntax of the "turn" and "turns" URIs described in [RFC8155]. The syntax of the "turn" and "turns" URIs
are defined in Section 3.1 of [RFC7065]. are defined in Section 3.1 of [RFC7065].
4.1. TURN URI Scheme Semantics 4.1. TURN URI Scheme Semantics
The "turn" and "turns" URI schemes are used to designate a TURN The "turn" and "turns" URI schemes are used to designate a TURN
skipping to change at page 80, line 20 skipping to change at page 80, line 20
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P.
Jones, "Traversal Using Relays around NAT (TURN) Uniform Jones, "Traversal Using Relays around NAT (TURN) Uniform
Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065, Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065,
November 2013, <https://www.rfc-editor.org/info/rfc7065>. November 2013, <https://www.rfc-editor.org/info/rfc7065>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, "IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016, DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>. <https://www.rfc-editor.org/info/rfc7915>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
24.2. Informative References 24.2. Informative References
[Frag-Harmful] [Frag-Harmful]
"Fragmentation Considered Harmful", <Proc. SIGCOMM '87, "Fragmentation Considered Harmful", <Proc. SIGCOMM '87,
vol. 17, No. 5, October 1987>. vol. 17, No. 5, October 1987>.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-30 (work in progress),
November 2018.
[I-D.ietf-tram-stun-pmtud] [I-D.ietf-tram-stun-pmtud]
Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery
Using Session Traversal Utilities for NAT (STUN)", draft- Using Session Traversal Utilities for NAT (STUN)", draft-
ietf-tram-stun-pmtud-10 (work in progress), September ietf-tram-stun-pmtud-10 (work in progress), September
2018. 2018.
[I-D.rosenberg-mmusic-ice-nonsip] [I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice- Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-
skipping to change at page 83, line 37 skipping to change at page 84, line 4
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Alan Johnston (editor) Alan Johnston (editor)
Rowan University Villanova University
Glassboro, NJ Villanova, PA
USA USA
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Philip Matthews Philip Matthews
Alcatel-Lucent Alcatel-Lucent
600 March Road 600 March Road
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: philip_matthews@magma.ca Email: philip_matthews@magma.ca
Jonathan Rosenberg Jonathan Rosenberg
jdrosen.net jdrosen.net
 End of changes. 29 change blocks. 
47 lines changed or deleted 69 lines changed or added

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