Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-turnbis-29

[Ballot comment]
Thanks for addressing my discuss!

OLD COMMENTS
----
Some other technical comments/questions:

1) Sec 3.7:
"or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]."
I believe the possibility to use UDP fragmentation was brought up by the TSV-ART review (Thanks Joe!). However, I would like to mention that this can only be used if supported by both endpoints and that should probably also be remarked here. The next sentence in the draft indicated this by saying "until UDP fragmentation support is available", however, this actually seem to be editorially a bit misplaced there and could explain more. See also this text in draft-ietf-tsvwg-udp-options:

"FRAG needs to be used with extreme care because it will present
  incorrect datagram boundaries to a legacy receiver, unless encoded
  as LITE data (see Section 5.8)."

Also note that draft-ietf-tsvwg-udp-options is still under development and we don't have much deployment experience with it yet.

And further, in the same section. There is also draft-ietf-tsvwg-datagram-plpmtud on "Packetization Layer Path MTU Discovery for Datagram Transports". Please also be aware that there is an extensive TSV-ART for draft-ietf-tram-stun-pmtud. Both might impact the final content of this section.

2) sec 11.5:
"When the server receives an ICMP packet, the server verifies that the
  type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2,
  or 3 for an ICMPv6 [RFC4443] packet."
Restricting to a set of known types, doesn't seem to support future extensibility very well...

3) sec 12.5:
"Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to
  a multiple of four bytes in order to ensure the alignment of
  subsequent messages."
Not exactly sure why this is useful...? Is this to align with STUN and therefore make processing somehow easier? Is that really needed. And exception should be easy to implement and should save some bytes which is the as I understood it the whole purpose of channels, no?

4) 12.6:
"Note that if
  the Length field in the ChannelData message is 0, then there will be
  no data in the UDP datagram, but the UDP datagram is still formed and
  sent."
Can you maybe add some more text and explain why this is useful?

5) sec 15:
RFC6824 will soon be obsoleted by draft-ietf-mptcp-rfc6824bis and please s/TCP multi-path/Multipath TCP/.

6) Just a thought looking at section 14 and 16: It could have been nice to provide an ECN feedback field from the server to the client in case a ECN marked packet is received from the peer... however, I guess that future work at this point in the process...

7) sec 18.13: Maybe I missed this because I reviewed this doc over 3 days, but is only the ICMP Attribute send to the client or is the actual ICMP packets or as much as possible of that packet includes as well?

8) sec 23:
"Response: TURN will no longer be needed once there are no longer any
  NATs.  Unfortunately, as of the date of publication of this document,
  it no longer seems very likely that NATs will go away any time soon.
  However, the need for TURN will also decrease as the number of NATs
  with the mapping property of Endpoint-Independent Mapping [RFC4787]
  increases."
Yes... so you don't think that IPv6 will be any help here?


Editorial comments:

1) Sec 6:
"The relayed transport address MUST be unique across all
  allocations, so it can be used to uniquely identify the allocation.

  Both the relayed transport address and the 5-tuple MUST be unique
  across all allocations, so either one can be used to uniquely
  identify the allocation, [...]"
These two sentences seem quite redundant. The first one was added in this draft. The second one was already there in RFC5766.

2) sec 7.1:
"Since this specification only
  allows UDP between the server and the peers, it is RECOMMENDED that [...]"
Wordings ("only allows") seems weird to me given use of other proposals is at least to some extend discussed.

Nits:
sec 7.1.: s/the client pick a currently unused transport address/the client picks a currently unused transport address/

[Ballot discuss]
I support Roman's Discuss.

I think I'm confused about whether REQUESTED-ADDRESS-FAMILY and
ADDITIONAL-ADDRESS-FAMILY are mutually exclusive.  Does sending just the
"additional" one secretly mean that you want both v4 and v6?

Section 5

I see that the secdir reviewer asked about why it is a "SHOULD" to send
SOFTWARE, and only got a response that it is defined in stunbis, but not
about why it is recommended.  There remain some privacy/security
considerations with it, and we should either point to the stunbis
security considerations or not recommend using it.  (FINGERPRINT is,
IIRC, less interesting from a security perspective as it's just about
confirming that given traffic is in fact STUN and not something else.)

Section 12

Do we need to say anything about backwards compatibility with RFC 5766
peers that use a wider range of channel IDs?

Section 12.7

  When the server receives an ICMP packet, the server processes it as
  described in Section 11.5.  A Data indication MUST be sent regardless
  of whether there is a channel bound to the peer that was the
  destination of the UDP datagram that triggered the reception of the
  ICMP packet.

This MUST seems potentially in conflict with the previous discussion
about permissions checks in Section 11.5.

Section 20

Looking at the
new nonce in the example ("obMatJos2AAABadl7W7PeDU4hKE72jda"), and
noting that it starts with the nonce cookie, help me decode the security
feature bits.  The magic prefix is "obMatJos2" so the capability bits
are encoded as "AAAB", which decodes to (hex) 00 00 01.  But stunbis
says that the bits are ordered from 0 (MSB of first byte) to 23 (LSB of
last byte), so this would have bit 23 set, which is in contrast to the
registry marking bit 0 as the password-algorithms feature.  Where am I
messing this up?

I'd prefer if the examples showed more usage of MESSAGE-INTEGRITY-SHA256
(especially, any from the server) and fewer MESSAGE-INTEGRITY.

[Ballot comment]
Thanks for keeping the diff from RFC 5766 relatively contained!
I only reviewed the diff due to time constraints, but in general support
reviewing the full document for internal consistency and any remarks
that have not aged well, especially with respect to IANA considerations.

Section 2

RFC 8174 has an updated version of the BCP 14 boilerplate text.

Section 3.1

I appreciate the response to the secdir review, but even the linked
stunbis section does not say much about which PKI's trust root is
expected to be used.  I'm forced to assume the Web PKI but don't have
much grounds for that assumption.

Section 3.2

The secdir reviewer's comments seem to have some relevance.
It seems like even when the third-party authorization mechanism is used,
the client is still limited to "the server is authenticated because it
gives me the service I asked for", which is not really documented
anywhere yet.  The long-term password mechanism at least generates an
HMAC integrity tag on messages from server to client, which can provide
some level of authentication via key confirmation.

Section  3.7

                                      If the TURN server carrying out
  packet translation from IPv4-to-IPv6 cannot get the Don't Fragment
  (DF) bit in the IPv4 header, it MUST reject the Allocate request with
  DONT-FRAGMENT attribute.

nit: does "cannot get" mean something like "read the value as sent on
the wire" (e.g., due to implementation/API limitations)?

Section 6

  o  the relayed transport address or addresses;
  [...]

  [...]
  address.  The relayed transport address MUST be unique across all
  allocations, so it can be used to uniquely identify the allocation.

nit: there's maybe a singular/plural mismatch going on here, but I don't
have any good ideas.

Section 7.1

  If the client wishes to obtain one IPv6 and one IPv4 relayed
  transport address then it includes an ADDITIONAL-ADDRESS-FAMILY
  attribute in the request.  This attribute specifies that the server
  must allocate both address types.  The attribute value in the
  ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family).
  Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
  ADDRESS-FAMILY attributes in the same request.  [...]

This reads like setting REQUESTED-ADDRESS-FAMILY and
ADDITIONAL-ADDRESS-FAMILY are mutually exclusive.  Is that the correct
reading?  (Naively, one might expect that the thing named "additional"
is applied on top of the base-level request, so I have to ask.)

Section 7.2

Why do we only have a SHOULD-level requirement for authentication of
Allocate requests where 5766 had MUST?  Could we say "may allow
unauthenticated requests in order to support [use case] but otherwise
MUST require authentication" (with better wording)?  I suppose this has
probably been discussed ad nauseum already, so feel free to point me
at the archives before getting into an actual discussion.

  7.  If the server does not support the address family requested by
        the client in REQUESTED-ADDRESS-FAMILY or is disabled by local
        policy, it MUST generate an Allocate error response, and it MUST
        include an ERROR-CODE attribute with the 440 (Address Family not
        Supported) response code.  [...]

nit: "or is disabled" needs a subject.

  9.  The server checks if the request contains an ADDITIONAL-ADDRESS-
        FAMILY attribute.  If yes, and the attribute value is 0x01 (IPv4
        address family), then the server rejects the request with a 400
        (Bad Request) error.  Otherwise, the server checks if it can
        allocate relayed transport addresses of both address types.  If
        the server cannot satisfy the request, then the server rejects

What are "both" address types?  We only have the
ADDITIONAL-ADDRESS-FAMILY (which contains one type) and no
REQUESTED-ADDRESS-FAMILY.

Section 8.1

  When refreshing a dual allocation, the client includes REQUESTED-
  ADDRESS-FAMILY attribute indicating the address family type that
  should be refreshed.  If no REQUESTED-ADDRESS-FAMILY is included then
  the request should be treated as applying to all current allocations.
  The client MUST only include family types it previously allocated and
  has not yet deleted.  [...]

I'm a bit confused about "only include family types" plural; I thought
there could only be at most one REQUESTED-ADDRESS-FAMILY and that it
would only indicate one family type.  So how could  there be multiple
types getting included by the client?

Section 11.5

[check that "type and code" is valid in both ICMPv4 and v6]

Section 12

  Reserved values may be used in the future by other protocols.  When
  the client uses channel binding, it MUST comply with the
  demultiplexing scheme discussed above.

"channel binding" is a term of art in the security world; is this usage
intended to roughly mean "channel multiplexing"?
(I do see that the subsections are talking about the specific
ChannelBind request, so I assume so; I just want to double check.)


Section 13

  The descriptions below have two parts: a preferred behavior and an
  alternate behavior.  The server SHOULD implement the preferred
  behavior.  Otherwise, the server MUST implement the alternate
  behavior and MUST NOT do anything else for the reasons detailed in
  [RFC7915].  [...]

RFC 5766 had this split on a per-field basis, but this text suggests
that if the preferred behavior is not possible for a given field, then
the alternate behavior is used for the entire packet.
I note that section 14 does retain the "for a particular field" language
for UDP-to-UDP relaying, as do section 15 for TCP-to-UDP relaying
and section 16 for UDP-to-TCP relaying.

Section 13.2

Is this flow label text consistent with both the inbound and outbound
translation directions (specifically, using relayed/peer addresses in
the 5-tuple to identify the flow)?

      If the incoming packet did not include a Fragment header and the
      outgoing packet size exceeds the outgoing link's MTU, the TURN
      server drops the outgoing packet and send an ICMP message of type
      2 code 0 ("Packet too big") to the sender of the incoming packet.
      If the packet is being sent to the peer, the TURN server reduces
      the MTU reported in the ICMP message by 48 bytes to allow room for
      the overhead of a Data indication.

(nit?) "If the packet is being send to the peer" seems to grammatically
refer to the outgoing packet that would exceed link MTU, as opposed to
the ICMP message being generated.  But I think it's supposed to refer to
the ICMP message being generated, which has not yet been referred to as
a "packet" in this text.

Section 13.3

[Same comment about ICMP packet generation/grammar]

Section 15

Maybe note that SIP and WebRTC are the primary consumers of TURN?

                                                        Even if both
  TCP-AO and UDP authentication would be used between TURN client and
  server, it would not change the end-to-end security properties of the
  UDP payload being relayed.  [...]

I wonder if we even need to say "UDP" in "payload being relayed".

Section 16

  Fragmentation

      Preferred Behavior: Any fragmented packets are reassembled in the
      server and then forwarded to the client over the TCP connection.
      ICMP messages resulting from the UDP datagrams sent to the peer
      MUST be forwarded to the client using TURN's mechanism for
      relevant ICMP types and codes.

As in section 12.7, I wonder if this MUST could be seen as overriding
other logic for ICMP handling.

Section 21.16

I agree with the secdir reviewer that there is at least potential for
username and realm to be sensitive.

Section 21.4

Do we need references for Teredo and/or 6to4?

Section 22

  The codepoints for the STUN error codes defined in this specification
  are listed in Section 19.  [IANA is requested to update the reference
  from [RFC5766] to RFC-to-be for the STUN error codes listed in
  Section 19.]

(I think some of them are from RFC 6156 as well as from 5766.)

Section 23

It seems prudent to revisit these listed IAB Considerations for whether
the situation has changed in the past ten years (though I don't have any
specific points that I would change).

Section 25

(nit) are these really "updates" to RFC 6156 so much as incorporating its
content wholesale into the core TURN specification?

[Ballot discuss]
(1) Section 12.1.6.  (Per the back-and-forth on Chris Wood’s SECDIR review – thank you Chris!) Per “Confidentiality is only a secondary concern, as TURN control messages do not include information that is particularly sensitive”, wouldn’t the USERNAME and REALM potentially be privacy sensitive?  If they aren’t sensitive in all cases (e.g., usernames might be ephemeral), this should be noted and cited.

[Ballot comment]
(2) This draft relies on the draft-ietf-tram-stunbis’s STUN Password Algo Registry which has MD5 and SHA-256.  Section 16.1.1 of that draft already discusses the limitation of SHA-256 (which it might be useful to reference).  Nevertheless, are there cases where MD5 should be used over SHA-256 if there is a choice?  Is there a reason not to recommend that implementations “SHOULD NOT use MD5”? 

(3) Section 5. Per “The client SHOULD include the SOFTWARE …” and “The client and the server MAY include the FINGERPRINT attribute …”, why is the sending of SOFTWARE not a “MAY” too?

(4) Section 5.  (Per the back-and-forth on Chris Wood’s SECDIR review) Recommend citing Section 6.3.1 of [draft-ietf-tram-stunbis] as source of 40 second request buffer timeout

(5) Section 21.4.  Per “It is RECOMMENDED that TURN servers not accept allocation or channel binding requests from addresses known to be tunneled”, I concur with the advice.  How would one recognize that the address is being tunneled?

[Ballot discuss]
(1) Section 12.1.6.  (Per the back-and-forth on Chris Wood’s SECDIR review – thank you Chris!) Per “Confidentiality is only a secondary concern, as TURN control messages do not include information that is particularly sensitive”, wouldn’t the USERNAME and REALM potentially be privacy sensitive?  If they aren’t sensitive in all cases (e.g., usernames might be ephemeral), this should be noted and cited.

(2) This draft relies on the draft-ietf-tram-stunbis’s STUN Password Algo Registry which (in Section 16.1.1) already discusses the limitation of SHA-256.  Nevertheless, it is still better than MD5 which is still supported too.  Is there a reason not to recommend that implementation “SHOULD NOT use MD5”?  Also, it seems helpful to reference the caveats about SHA-256 for password hashing from draft-ietf-tram-stunbis here too.

[Ballot comment]
(3) Section 5. Per “The client SHOULD include the SOFTWARE …” and “The client and the server MAY include the FINGERPRINT attribute …”, why is the sending of SOFTWARE not a “MAY” too?

(4) Section 5.  (Per the back-and-forth on Chris Wood’s SECDIR review) Recommend citing Section 6.3.1 of [draft-ietf-tram-stunbis] as source of 40 second request buffer timeout

(5) Section 21.4.  Per “It is RECOMMENDED that TURN servers not accept allocation or channel binding requests from addresses known to be tunneled”, I concur with the advice.  How would one recognize that the address is being tunneled?

[Ballot discuss]
One quick discussion which probably is only an oversight and therefore should be easy got fix:

I'm bit confused about the requirement on using authentication. This draft says in section 5 (as RFC5766 does):

"The server MUST demand that all requests
  from the client be authenticated using this mechanism, or that a
  equally strong or stronger mechanism for client authentication is
  used."

However, RFC 8155 which is even now cited in this draft, updates RFC5766 and relaxes this requirement. Later in the section 7.2. this draft says:

"The server SHOULD require that the request be authenticated."

I assume the requirement in section 5 is an oversight?

I also recommend to only specify this requirement normatively in one place.

[Ballot comment]
Some other technical comments/questions:

1) Sec 3.7:
"or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]."
I believe the possibility to use UDP fragmentation was brought up by the TSV-ART review (Thanks Joe!). However, I would like to mention that this can only be used if supported by both endpoints and that should probably also be remarked here. The next sentence in the draft indicated this by saying "until UDP fragmentation support is available", however, this actually seem to be editorially a bit misplaced there and could explain more. See also this text in draft-ietf-tsvwg-udp-options:

"FRAG needs to be used with extreme care because it will present
  incorrect datagram boundaries to a legacy receiver, unless encoded
  as LITE data (see Section 5.8)."

Also note that draft-ietf-tsvwg-udp-options is still under development and we don't have much deployment experience with it yet.

And further, in the same section. There is also draft-ietf-tsvwg-datagram-plpmtud on "Packetization Layer Path MTU Discovery for Datagram Transports". Please also be aware that there is an extensive TSV-ART for draft-ietf-tram-stun-pmtud. Both might impact the final content of this section.

2) sec 11.5:
"When the server receives an ICMP packet, the server verifies that the
  type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2,
  or 3 for an ICMPv6 [RFC4443] packet."
Restricting to a set of known types, doesn't seem to support future extensibility very well...

3) sec 12.5:
"Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to
  a multiple of four bytes in order to ensure the alignment of
  subsequent messages."
Not exactly sure why this is useful...? Is this to align with STUN and therefore make processing somehow easier? Is that really needed. And exception should be easy to implement and should save some bytes which is the as I understood it the whole purpose of channels, no?

4) 12.6:
"Note that if
  the Length field in the ChannelData message is 0, then there will be
  no data in the UDP datagram, but the UDP datagram is still formed and
  sent."
Can you maybe add some more text and explain why this is useful?

5) sec 15:
RFC6824 will soon be obsoleted by draft-ietf-mptcp-rfc6824bis and please s/TCP multi-path/Multipath TCP/.

6) Just a thought looking at section 14 and 16: It could have been nice to provide an ECN feedback field from the server to the client in case a ECN marked packet is received from the peer... however, I guess that future work at this point in the process...

7) sec 18.13: Maybe I missed this because I reviewed this doc over 3 days, but is only the ICMP Attribute send to the client or is the actual ICMP packets or as much as possible of that packet includes as well?

8) sec 23:
"Response: TURN will no longer be needed once there are no longer any
  NATs.  Unfortunately, as of the date of publication of this document,
  it no longer seems very likely that NATs will go away any time soon.
  However, the need for TURN will also decrease as the number of NATs
  with the mapping property of Endpoint-Independent Mapping [RFC4787]
  increases."
Yes... so you don't think that IPv6 will be any help here?


Editorial comments:

1) Sec 6:
"The relayed transport address MUST be unique across all
  allocations, so it can be used to uniquely identify the allocation.

  Both the relayed transport address and the 5-tuple MUST be unique
  across all allocations, so either one can be used to uniquely
  identify the allocation, [...]"
These two sentences seem quite redundant. The first one was added in this draft. The second one was already there in RFC5766.

2) sec 7.1:
"Since this specification only
  allows UDP between the server and the peers, it is RECOMMENDED that [...]"
Wordings ("only allows") seems weird to me given use of other proposals is at least to some extend discussed.

Nits:
sec 7.1.: s/the client pick a currently unused transport address/the client picks a currently unused transport address/

[Ballot comment]

* Section 3.7

I think an informative reference to [draft-ietf-intarea-frag-fragile] would be very useful here. It is a BCP that covers this issue in great detail and has specific recommendations for different audiences.

* Section 13.2 Page 53

"If the packet is being sent to the peer"

The term "the packet" is ambiguous here. This could potentially refer to the ICMPv6 packet being sent or the original packet that caused the error. Can you please clarify which one you mean here?

* References

I do have a better citation for the Fragmentation Considered Harmful paper if you want to use it.

  [Kent]    Kent, C. and J. Mogul, ""Fragmentation Considered
              Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in
              Computer Communications Technology, DOI
              10.1145/55483.55524", August 1987,
              .

[Ballot comment]
Thanks for all the work everyone did to update the TURN specification. I am
balloting "Yes," as I think these are important changes to have published. I
do have a small handful of comments that, while they don't rise to the level
of a DISCUSS, are nonetheless rather important to consider before progressing
this draft to an RFC.

---------------------------------------------------------------------------

§5:

>  The server SHOULD
>  include the SOFTWARE attribute in all Allocate and Refresh responses
>  (either success or failure) and MAY include it in other responses or
>  indications.

The Security Considerations section should probably include some mention of this
behavior, and the trade-offs between allowing clients to know which software
(and version) the server is running against providing this information to
potential attackers who can use it to determine what software vulnerabilities
may exist in that specific server and version.

---------------------------------------------------------------------------

§11.5:

>  It also verifies that the IP
>  packet in the ICMP packet payload contains a UDP header.

It's not clear what is being asked of implementations here. Is this just a
check of the protocol field, or is it more involved than that? Is the
intention that the server also check that the checksum is valid (i.e., matches
the computed checksum or is zero)? If so, please spell it out more precisely.
If this language is intended to imply even more rigorous checks, then it needs
a lot more text.

---------------------------------------------------------------------------

§12:

>    0x5000-0xFFFF: Reserved (For DTLS-SRTP multiplexing collision
>    avoidance, see [RFC7983].

Given that values through 0x7FFF were permitted by the previous version of the
protocol, it's unclear what what recovery path this document anticipates for
legacy clients that might request channels in the 0x5000 - 0x7FFE range. The
server behavior is well defined (the server sends a 400 response), but this
seems to represent a fundamental backwards incompatibility, given that the
client will take this to be a final request error and presumably abandon the
attempt to use the TURN server.

If the assumption is that no existing deployed legacy clients use channel
numbers greater than 0x4FFF, please include that as a note. If the intention is
instead that we're breaking backwards compatibility in a limited fashion, please
include that as a note. If the rationale is some explanation other than these
two, please include it as a note.

---------------------------------------------------------------------------

§18.12:

>  Reason Phrase:  The recommended reason phrases for error codes 440
>    and 508 are explained in Section 19.  The reason phrase MUST be a
>    UTF-8 [RFC3629] encoded sequence of less than 128 characters
>    (which can be as long as 509 bytes when encoding them or 763 bytes
>    when decoding them).

This doesn't make a lot of sense to me. If arbitrary sequences of 128 UTF-8
characters are allowed, then the on-the-wire encoding might be as long as 512
bytes (rather than 509), even if this would only result from the use of unusual
strings (e.g., 128 consecutive emoji). I'm even more lost by the indication of
"763 bytes," as I can't figure out what "decoding" operation is being indicated
here, nor can I figure out what kind of decoded sequence would use 5.96 bytes
per character. Please double-check your numbers, and add more text indicating
what is meant by "encoding" and "decoding" in this sentence.

Also, nit: "...fewer than 128 characters..."

[Ballot comment]
Sec 3.7: "or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]."
I believe the possibility to use UDP fragmentation was brought up by the TSV-ART review (Thanks Joe!). However, I would like to mention that this can only be used if supported by both endpoints and that should probably also be remarked here. See this text in draft-ietf-tsvwg-udp-options:

"FRAG needs to be used with extreme care because it will present
  incorrect datagram boundaries to a legacy receiver, unless encoded
  as LITE data (see Section 5.8)."

[Ballot comment]
Thank you all for the work put into this clear and well-written document. I also appreciate the fact that TURN server can be used to proxy between IPv4 and IPv6; on this topic, this specific use case could probably be described early in the document rather then in section 5 (e.g. when discussing the transport protocol between client and server or even earlier).

For my own curiosity, isn't TURN scope broader than plain NAT: can it also be useful in the absence of NAT if inbound 'connection' are blocked by security policy ?


== COMMENTS ==

-- Section 2 --

Please use the new boilerplate RFC 8174 ;-)

-- Section 3.1 --

Is there any reason why MPTCP is not specified for the communication between TURN client and TURN server? There is a very short explanation in section 15 "TCP multi-path is not used by both SIP and WebRTC protocols [RFC7478] for media and non-media data" but it does not address the use of MPTCP between TURN client/server.

-- Section 3.7 --

The 500 bytes guideline to avoid fragmentation, is there any data backing the sentence "...will generally avoid IP fragmentation." ?

In the same section, the text about 'DF bit' should be clear that it is obviously for IPv4 (it is indicated 2 paragraphs below).

-- Section 3.9 --

The TCP/UDP/DTLS discussion of 'happy eyeball' is confusing between "use the first TCP connection that is established" and "if connections are established on both IP address families..." Which sentence should be used? Why plain RFC 8305 is not enough?

-- Section 7.2 --

What is the expected server behavior when receiving a DONT-FRAGMENT when the REQUESTED-ADDRESS-FAMILY is IPv6 ? The STUN document appears to use DONT-FRAGMENT only when receiving traffic from the peers.

-- Section 9 --

About the permission based on the peer IP address, the text is about UDP, but what about ICMP messages? (obvioulsy their source could be any router on the path) The text should refer to section 11.5

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tram-turnbis-25. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

First, in the STUN Methods registry on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at:

https://www.iana.org/assignments/stun-parameters/

the following, existing registrations will have their references changed to [ RFC-to-be ]:

0x003 : Allocate
0x004 : Refresh
0x006 : Send
0x007 : Data
0x008 : CreatePermission
0x009 : ChannelBind

Second, in the STUN Attributes registry also on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at:

https://www.iana.org/assignments/stun-parameters/

the following, existing registrations will have their references changed to [ RFC-to-be ]:

0x000C: CHANNEL-NUMBER
0x000D: LIFETIME
0x0010: Reserved (was BANDWIDTH)
0x0012: XOR-PEER-ADDRESS
0x0013: DATA
0x0016: XOR-RELAYED-ADDRESS
0x0017: REQUESTED-ADDRESS-FAMILY
0x0018: EVEN-PORT
0x0019: REQUESTED-TRANSPORT
0x001A: DONT-FRAGMENT
0x0021: Reserved (was TIMER-VAL)
0x0022: RESERVATION-TOKEN

Third, also in the STUN Attributes registry also on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at:

https://www.iana.org/assignments/stun-parameters/

three, new attributes will be registered from the comprehension-optional range (0x8000-0xFFFF)as follows:

Value: [ TBD-at-Registration ]
Name: ADDITIONAL-ADDRESS-FAMILY
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Name: ADDRESS-ERROR-CODE
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Name: ICMP
Reference: [ RFC-to-be ]

Fourth, in the STUN error codes registry also on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at:

https://www.iana.org/assignments/stun-parameters/

the following, existing registrations will have their references changed to [ RFC-to-be ]:

403 (Forbidden)
437 (Allocation Mismatch)
440 (Address Family not Supported)
441 (Wrong Credentials)
442 (Unsupported Transport Protocol)
443 (Peer Address Family Mismatch)
486 (Allocation Quota Reached)
508 (Insufficient Capacity)

Fifth, in the Service Name and Transport Protocol Port Number Registry page located at:

https://www.iana.org/assignments/service-names-port-numbers

There are existing registrations as follows:

turn 3478 tcp TURN over TCP [RFC5766]
turn 3478 udp TURN over UDP [RFC5766]
turns 5349 tcp TURN over TLS [RFC5766]
turns 5349 udp TURN over DTLS [IESG] [IETF_Chair] 2014-07-03 [RFC7350] This service name was initially created by [RFC5766].

IANA Question --> should the references for these port number and service name registrations be changed to [ RFC-to-be ]?

Sixth, in the Traversal Using Relays around NAT (TURN) Channel Numbers registry also on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at:

https://www.iana.org/assignments/stun-parameters/

The registry will be changed as follows:

Value: 0x0000 through 0x3FFF
Name: Reserved and not available for use, since they conflict with the STUN header
Reference: [ RFC-to-be ]

Value: 0x4000 through 0x4FFF
Name: A TURN implementation is free to use channel numbers in this range
Reference: [ RFC-to-be ]

Value: 0x5000 through 0xFFFF
Name: Unassigned

The registration rules for this registry remain Standards Action.

IANA Question --> Are there any other places where the reference [RFC5766] should be changed/amended to [ RFC-to-be ]?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-05-28):

From: The IESG
To: IETF-Announce
CC: magnus.westerlund@ericsson.com, draft-ietf-tram-turnbis@ietf.org, tram@ietf.org, brandon.williams@akamai.com, Brandon Williams , tram-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard


The IESG has received a request from the TURN Revised and Modernized WG
(tram) to consider the following document: - 'Traversal Using Relays around
NAT (TURN): Relay Extensions to Session
  Traversal Utilities for NAT (STUN)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-05-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  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
  (peers).  In these situations, it is necessary for the host to use
  the services of an intermediate node that acts as a communication
  relay.  This specification defines a protocol, called TURN (Traversal
  Using Relays around NAT), that allows the host to control the
  operation of the relay and to exchange packets with its peers using
  the relay.  TURN differs from some other relay control protocols in
  that it allows a client to communicate with multiple peers using a
  single relay address.

  The TURN protocol was designed to be used as part of the ICE
  (Interactive Connectivity Establishment) approach to NAT traversal,
  though it also can be used without ICE.

  This document obsoletes RFC 5766 and RFC 6156.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ballot/


No IPR declarations have been submitted directly on this I-D.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

> Why is this the proper type of RFC?

Because it updates/obsoletes an existing "Proposed Standard" protocol
definition.

> Is this type of RFC indicated in the title page header?

Yes.

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
>
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?
>
> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification? Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?
>
> Personnel
>
>  Who is the Document Shepherd? Who is the Responsible Area
>  Director?

Technical Summary

  This document updates the definition of Traversal Using Relays around NAT
  (TURN), RFC5766, a protocol that allows the host to control the operation of
  the relay and to exchange packets with its peers using the relay. The
  updates improve protocol support for IPv6 and DTLS, adds support for
  receiving ICMP packets, and updates PMTUD. The new revision also improves
  document clarity regarding tunnel amplification attacks and packet
  translation.

Working Group Summary

  This document represents one of the core milestones for the TRAM working
  group and as such has undergone significant discussion, review, and
  revision.  There has been no significant controversy of note in the updates
  to this document. This document's dependence upon some other documents, most
  notably updates to Session Traversal Utilites for NAT (STUN)
  I-D.ietf-tram-stunbis, have led to delay in this document's completion, but
  have not increased the difficulty of coming to consensus on this document's
  contents.

Document Quality

  This draft has continuously been reviewed by many different people
  throughout its history. The most significant updates have been the subject
  of discussion in TRAM WG meetings throughout the documents lifetime.

  Comprehensive reviews of the full set of updates have been done by two
  active WG members. This review includes coverage for consistency with the
  related stunbis document. All of the review feeback has been addressed by
  the authors.

Personnel

  Document Shepherd: Brandon Williams
  Responsible Area Director: Spencer Dawkins

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

Full review + nit checker.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed? 

No

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.

No additional focused review was considered necessary for this document.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes.

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No IPR disclosure has been filed.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

Consensus represents the WG as a whole.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No such threats have been made.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

All relevant nits have been resolved.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

No such reviews were done or deemed to be required.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

All normative references are to RFCs, except for I-D.ietf-tram-stunbis, which
has already been advanced to the IESG and is under active review.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

There are no downward normative references.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

The title page, abstract, and introduction all indicate that RFCs 5766 and
6156 are obsoleted by this one.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document.

Careful review.

> Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.

I confirm.

> Confirm that any referenced IANA registries have been clearly
> identified.

I confirm.

> Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

There are no newly created IANA registries.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

No new IANA registries are requested.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

None.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

> Why is this the proper type of RFC?

Because it updates/obsoletes an existing "Proposed Standard" protocol
definition.

> Is this type of RFC indicated in the title page header?

Yes.

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
>
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?
>
> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification? Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?
>
> Personnel
>
>  Who is the Document Shepherd? Who is the Responsible Area
>  Director?

Technical Summary

  This document updates the definition of Traversal Using Relays around NAT
  (TURN), RFC5766, a protocol that allows the host to control the operation of
  the relay and to exchange packets with its peers using the relay. The
  updates improve protocol support for IPv6 and DTLS, adds support for
  receiving ICMP packets, and updates PMTUD. The new revision also improves
  document clarity regarding tunnel amplification attacks and packet
  translation.

Working Group Summary

  This document represents one of the core milestones for the TRAM working
  group and as such has undergone significant discussion, review, and
  revision.  There has been no significant controversy of note in the updates
  to this document. This document's dependence upon some other documents, most
  notably updates to Session Traversal Utilites for NAT (STUN)
  I-D.ietf-tram-stunbis, have led to delay in this document's completion, but
  have not increased the difficulty of coming to consensus on this document's
  contents.

Document Quality

  This draft has continuously been reviewed by many different people
  throughout its history. The most significant updates have been the subject
  of discussion in TRAM WG meetings throughout the documents lifetime.

  Comprehensive reviews of the full set of updates have been done by two
  active WG members. This review includes coverage for consistency with the
  related stunbis document. All of the review feeback has been addressed by
  the authors.

Personnel

  Document Shepherd: Brandon Williams
  Responsible Area Director: Spencer Dawkins

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

Full review + nit checker.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed? 

No

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.

No additional focused review was considered necessary for this document.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes.

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No IPR disclosure has been filed.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

Consensus represents the WG as a whole.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No such threats have been made.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

All relevant nits have been resolved.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

No such reviews were done or deemed to be required.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

All normative references are to RFCs, except for I-D.ietf-tram-stunbis, which
has already been advanced to the IESG and is under active review.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

There are no downward normative references.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

The title page, abstract, and introduction all indicate that RFCs 5766 and
6156 are obsoleted by this one.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document.

Careful review.

> Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.

I confirm.

> Confirm that any referenced IANA registries have been clearly
> identified.

I confirm.

> Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

There are no newly created IANA registries.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

No new IANA registries are requested.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

None.