Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Magnus,

Please see inline [TR]

From: Magnus Westerlund <[e-mail]>
Sent: Friday, April 26, 2019 5:07 PM
To: Konda, Tirumaleswar Reddy <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi,

Cutting away what appear settled.

On 2019-04-18 10:20, Konda, Tirumaleswar Reddy wrote:



 error packet, the server also relays certain layer 3/4 header fields from the

ICMP header to the client. When the client sends a packet to the server, the

server relays the transport protocol data from the packet to the appropriate

peer using the relayed transport address as the source.



"appropriate" appears wrong. The peer is the one the client have configure for

the allocation. So I think a more direct language can be used.

"appropriate peer" is used at several places in https://tools.ietf.org/html/rfc5766.

There is now a single occurrence of it in this document. And in that context, it appears that using "intended" or "addressed" peer would work better and be clearer.

[TR] Okay, replaced with “intended peer”.



Othewise fine with me.




H. Section 5:

   If the server requires requests to be

   authenticated, then the server's administrator MUST choose a realm

   value that will uniquely identify the username and password

   combination that the client must use, even if the client uses

   multiple servers under different administrations.



Just to verify, TURN does not allow a single server address to host

multiple realms do it? Each Realm needs its own unique server transport

address?

No, I don't see any such restriction in TURN.  For example, in an Enterprise

network with multiple realms, the TURN server based on the client subnet can

choose the realm.



I think this is a not expressed assumption, that realm determination may be

done based on source IP address of the client's request. That is an assumption

that is not generally applicable, but can work for some combinations of realms.

For example an server that has a REALM for an WebRTC service that is

intended to have no restrictions can't be co-located with anything that has a

small scope as that can lead to selection of the wrong realm.

Yes, both assumptions are deployment specific.  Enterprise TURN servers are discussed in https://tools.ietf.org/html/rfc7478.

Username and password is not the only way to perform mutual authentication b/w the TURN client and server, https://tools.ietf.org/html/rfc7635 discusses using OAuth and is used by WebRTC (see https://w3c.github.io/webrtc-pc/).



What do you think is the best option here. Simple document that there are no

mechanism in the protocol for the client to indicate which REALM it thinks it

belongs to and state that the basic mechanism is using different server ports

for different realms. Or to write even more where the possibility in source IP

address identification of realm is described but also its limitations?

If different server ports are used for different realms, the client needs to learn the server ports and manual configuration may not be a suitable option. The public TURN server could have different domain names for different realms, and the client can discover the server port for the TURN server domain using S-NAPTR.  I don't think the draft should discuss deployment specific solutions.

So if I understand this correctly your stating that it is up to the server implementation to figure out what the realm on what ever information is gets based on the request. From a client implementation perspective it appears less clear if anything the client will affect the realm response it will receive.

[TR] The client cannot affect the realm response from the server, similar to HTTP authentication using realm (please see https://tools.ietf.org/html/rfc7235).

I don't think this Section 18 quote is not clear either.

   Following the procedures of the long-term credential mechanism of
   STUN [I-D.ietf-tram-stunbis], the server includes an ERROR-CODE
   attribute with a value of 401 (Unauthorized), a REALM attribute that
   specifies the authentication realm used by the server (in this case,
   the server's domain "example.com"), and a nonce value in a NONCE
   attribute.

So I will not persist on this, but I would appreciate some indications on that the server may do more than simply have a single realm for a given server transport address.

L. Section 7.1:



  The client then picks a transport protocol to use between the client

   and the server.  The transport protocol MUST be one of UDP, TCP, TLS-

   over-TCP or DTLS-over-UDP.



I find it strange that this indicates that one should pick the

transport protocol to use client to server without considering the

server capabilities. Especially as the client configuration or server

discovery procedures will indicate transport protocol support.

The server may support more than one transport protocol.

Sorry, should have been clearer. Should there be any references to how the

client can determine the servers capabilities? You have recommendations

about using UDP and a pointer to Section 2.1 for some discussion of the choices.

So that covers giving some guidance to the protocol choice.

I have updated the text as follows:



   The client then picks a transport protocol to use between the client

   and the server based on the transport protocols supported by the

   server.  The transport protocol MUST be one of UDP, TCP, TLS- over-TCP or DTLS-over-UDP.

   Since this specification only allows UDP between the server

   and the peers, it is RECOMMENDED that the client pick UDP unless it

   has a reason to use a different transport.  One reason to pick a

   different transport would be that the client believes, either through

   configuration or discovery or by experiment, that it is unable to

   contact any TURN server using UDP.  See Section 2.1 for more

   discussion.



The subsequent paragraph in Section 7.1 discusses use of [RFC8155] to discovery TURN server, and use of [RFC5928] and [RFC7350] to discover server transport capabilities.

I still think the MUST is unnecessary and problematic. The problem is that it first of all prevents any future extension to the transport protocols be used. Isn't the point, that the client picks one of the protocols it supports?

[TR] Yes.

Maybe remove the sentence and simply add something about "that the client supports" in the prior sentence.

[TR] Works for me, removed the sentence with MUST and modified the first line in the paragraph as follows:

The client then picks a transport protocol that the client supports to use between the client and the server based on the transport protocols supported by the server.

Also shouldn't this paragraph come before the previous one. I.e. that you first

must pick your transport protocol before you can pick a host transport address ?

No, middle-boxes may drop UDP traffic to the TURN server, and the client by experiment will identify the transport protocol permitted to the TURN server and eventually uses the

host transport address using which successful response was received from the server.

Ok.









Secondly, what is the motivation for the MUST in the second sentence?

This is appears to have strange interactions with any future

extensions and have no impact. A client must obvious chose a client

to server transport protocol it supports, and one that the server

supports or the client hope it will support.

https://tools.ietf.org/html/rfc5766#section-6.1 has the same text, I have

updated the text as follows:

The client then picks a transport protocol to use between the client and the

server based on the transport protocols supported by the server.

The TURN server MUST enable one of the transport protocols, UDP, TCP, TLS-

over-TCP or DTLS-over-UDP.



If the intention is to move the requirement to the server side for making it

normative to support at least one of the 4 options listed, I think you need to

rewrite it to say:



A TURN server MUST enable at least one of the transport protocols, UDP, TCP,

TLS- over-TCP or DTLS-over-UDP.

The above point is already discussed in Section 5 as follows:



 To ensure interoperability, a TURN server MUST support the use of UDP

 transport between the client and the server, and SHOULD support the

 use of TCP, TLS-over-TCP and DTLS-over-UDP transports.



So, this sentence lays out the implementation requirement on the server side and is very reasonable and likely needed.













M. Section 7.1:



   The client also picks a server transport address, which SHOULD be

   done as follows.  The client uses one or more procedures described in

   [RFC8155] to discover a TURN server and uses the TURN server

   resolution mechanism defined in [RFC5928] to get a list of server

   transport addresses that can be tried to create a TURN allocation.



1) So RFC 8155 states that it has no recommendation on server

selection, nor on how to related local configuration to any auto-discovery

servers.

To me it appears that the protocol utilizing TURN should consider

what makes sense in their deployments. Thus, does the need for such

consideration needs to be highlighted somewhere in this specification.

https://tools.ietf.org/html/rfc8155#section-3 discusses using auto-discovery in

the absence of local configuration or if the local configuration does not work.

https://tools.ietf.org/html/rfc8155#section-9 explains the mechanisms to

authenticate the discovered TURN server.

I am not sure about the additional considerations you are looking in this

specification.



Let me attempt to formulate the question in another way. As the Discovery

procedure documented in RFC 8155 does not mandate any specific order or

even what mechanisms are actually used / supported, then did the WG consider

to make either a stricter recommendation or some other considerations to

better ensure that TURN clients can discover TURN servers?



It is fine to say no.

No, it was left to implementation. If local configuration does not work for a TURN client, RFC8155 explains performing all the discovery mechanisms to find the TURN server.



Okay, then lets drop this point.





O. Section 7.1:



   If the client wishes to obtain a relayed transport address of a

   specific address type then it includes a REQUESTED-ADDRESS-FAMILY

   attribute in the request.



I don't find anything describing what the default behavior is if one

doesn't include the attribute, but the TURN server supports multiple address

families.

I see that bullet 7 in Section 7.2 indicates that IPv4 is default.

Should the text in 7.1 be explicit about this default?

The text in Section 7.1 is added for TURN clients not supporting TURNbis

specification to provide backward compatibility.



But if I understand this correctly, the legacy way is to not include the

REQUESTED-ADDRESS-FAMILY attribute for an IPv4 address.

Yes.



Thus, shouldn't a

sentence be added after the above to state that if the client wants an

IPv4 address it should skip using REQUESTED-ADDRESS-FAMILY attribute to

enable legacy interoperability, or do I missunderstand?

REQUEST-ADDRESS-FAMILY attribute is initially defined in https://tools.ietf.org/html/rfc6156 as comprehension-required attribute. If the legacy server does not understand this attribute, the request will be rejected (420 (Unknown Attribute), and if the client wants IPv4 relayed transport address, the client will have to retry the request without the REQUEST-ADDRESS-FAMILY attribute.



Okay, then I think this issue can be closed.









Q. Section 8.3:



   If the client receives a success response to its Refresh request with

   a non-zero lifetime, it updates its copy of the allocation data

   structure with the time-to-expiry value contained in the response.



   If the client receives a 437 (Allocation Mismatch) error response to

   a request to delete the allocation, then the allocation no longer

   exists and it should consider its request as having effectively

   succeeded.



So there are no considerations for the client if it receives an error

response to a refresh request when Lifetime was non-zero?



I am bit surprised by that. I assume that there are certain cases

when the request could be resent, and others where the meaning is

that the allocation is gone.

TURNbis does not update the refresh behavior already defined in

https://tools.ietf.org/html/rfc5766#section-7.3.  I will add the following line:

If the client receives an error response to its request to refresh the allocation,

it should consider the allocation no longer exists.



Isn't that over simplifying cases where one attempts to refresh an allocation

and could actually handle the issue. For example an error response to the client

of 438 (Stale Nonce)  where the client can retry the request with the new

Nonce. I also wonder if request time out as well as 400 (if it can figure out what

the issue was) could be re-attempted prior to allocation expires. But at leat hte

438 appears to indicate a situation where the client should not give up, and

thus should have some text here.

Good point, Modified the above line follows:

If the client receives a 437 (Allocation Mismatch) error response to its request to refresh the allocation, it should consider the allocation no longer exists. If the client receives a 438 (Stale Nonce) error to its request to refresh the allocation,

it should reattempt the request with the new nonce value.

Good works for me.





R. Section 11.5:



   When the server receives an ICMP packet, the server verifies that the

   type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either

   1, 2, or 3 for an ICMPv6 [RFC4443] packet.  It also verifies that the

   IP packet in the ICMP packet payload contains a UDP header.  If

   either of these conditions fail, then the ICMP packet is silently

   dropped.



Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter

Problem are for ICMPv4?

I don't get the above comment, please explain the question with an example.

So if a server receives an ICMP for sent packet with ICMPv4 type 12

(Parameter Problem) then that is relayed to the client according to this text.

But if the server sent a packet with IPv6 towards the peer and receives an

ICMPv6 message with Type 4 (Parameter Problem) that is not relayed to the

client. Why this discrepancy?

Thanks, got the comment. ICMPv4 and ICMPv6 error message (Parameter problem) need not be relayed back to the client because IPv6 extension header and IPv4 option set in the packet from the client will not be relayed to the peer (Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-14 and https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-13.2).  Removed ICMPv4 12 type. Added the following lines to Section 16.3 to convey the MTU of the next-hop link:



   Error Data:  This field size is 4 bytes long.  If the ICMPv6 type is

      2 (Packet Too Big Message) or ICMPv4 type is 3 ( Destination

      Unreachable) and Code is 4 (fragmentation needed and DF set), the

      Error Data field will be set to the Maximum Transmission Unit of

      the next-hop link (Section 3.2 of [RFC4443]) and Section 4 of

      [RFC1191]).  For other ICMPv6 types and ICMPv4 types and codes,

     Error Data field MUST be set to zero.



Thanks, that clarification. Issue resolved.







U. Section 13. 1,2,3:



      For both preferred and alternate behavior, the DONT-FRAGMENT

      attribute MUST be ignored by the server.



I don't understand why just because one performs v4<->v6 or v6 to v4

translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT

attribute. If the client has request to not fragment and the server

is unable to do that when forwarding to the peer it needs to generate

an ICMP attribute response saying the packet is to big. Otherwise the

relay breaks the Path MTU discovery mechanisms.

TURNbis is using the translation algorithms specified in RFC7915.



[a] For IPv4 to IPv6: The translator uses the DF bit in the IPv4 header to not

fragment the IPv6 packet (see https://tools.ietf.org/html/rfc7915#section-4),

DON'T-FRAGMENT attribute can be ignored.

[b] For IPv6 to IPv4: The translation algorithm in

https://tools.ietf.org/html/rfc7915#section-5 is used.  If the IPv6 endpoint wants

to discover the path MTU, it will send IPv6 packets without Fragment header

and DON'T-FRAGMENT attribute can be ignored.

[c] For IPv6 to IPv6: If the IPv6 endpoint wants to discover the path MTU, it

will send IPv6 packets without Fragment header and DON'T-FRAGMENT

attribute can be ignored.

Please note ignoring the DONT-FRAGMENT attribute is picked from

https://tools.ietf.org/html/rfc6156#section-8 and discussed in the BEHAVE WG

https://mailarchive.ietf.org/arch/msg/behave/oabu0VtUMBE-X3-vhgjdSFCboxc.



Thanks for the clarification on the context. I should have read Section

4 of 7915. Then I would have likely gotten the implication that the IP header DF

or Fragmentation header impacts how things are working.



However, I find the reasoning behind this choice very strange. I don't see how

you can implement a TURN server that does IPv4 <->IPv6, or IPv6 relaying

without having privileged access and where it reads the raw headers. An

implementation based on UDP sockets will not be able to do the right thing

here to my understanding. However, it could follow the DONT-FRAGMENT

attribute to instructing the sending using the Socket to do the right thing.

As per the discussion in BEHAVE WG, it seems possible to set and get various IP header fields using sockets, see https://mailarchive.ietf.org/arch/msg/behave/j6FfzgVLuSeHfOWz9zRO5iPCp98 and https://mailarchive.ietf.org/arch/msg/behave/3I-DvtVf_4cGcDnIktsWNEtfIYM.



I think there are two directions we can proceed in here.



1. Redefine this text to enable usage of DONT-FRAGMENT

I prefer not to change the behavior discussed and finalized for RFC6156 in BEHAVE WG.



or



2. Clarify the scope and implications of Unpriviliged TURN Server doing

translation





For the second option I think there are several aspects that I like to see

addressed:



  2a: Update the sentence I quoted for this issue to make it clear that you are

relying solely on IPv4 DF and IPv6 Fragmentation Header to control the

fragmentation.

Added the following line to Packet Translations (Section 13.6).

The TURN server solely relies on the DF bit in the IPv4 header and Fragmentation header in IPv6 header to handle fragmentation and does not rely on the DONT-FRAGMENT attribute.



Thanks, that clarifies that aspect.





  2b: Clarify that Unpriviliged TURN Severs that do IPv4<-> IPv6 translation will

not handle fragmentation well. And include a point to the last paragraph of

Section 2.7 and the use of DONT-FRAGMENT In Allocate requests to determine

support and that these needs to be rejected by such a server.

Depending on the OS, Unprivileged TURN Severs may or may not handle fragmentation (i.e. have access to DF bit).  I will add the following line:

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.

This is also good. Think these two changs resolve the issue.





By the way, there must be a typo with a "not" that shouldn't be in this

paragraph in Section 4 of 7915:



   When the IPv4 sender does not set the DF bit, the translator MUST NOT

   include the Fragment Header for the non-fragmented IPv6 packets.



To me it make sense for a IPv4->IPv6 translation where the IPv4 has DF=TRUE

to not include the fragmentation header, do you agree?

https://tools.ietf.org/html/rfc7915#section-4.1 says to include the fragment header only when IPv4 header has DF=0 and the packet size exceeds the MTU.

Okay, I think I understand the text and that it is not a real issue.











X. Section 14:



How are these IP level fields handled when the transport is TCP or TLS/TCP?

There there are not necessary a one to one mapping between datagrams

and TCP packets. And if there are no support then there are need for

clarification of behaviors when using TCP based transport.

Section 14 already clarifies that the descriptions in this section do not apply to

TURN messages sent over TCP or TLS transport from the server to the client.



Yes you are right. What are the recommendations for how to set the fields

when the Channel message or Send Indication arrives over

TCP/(TLS) to the server? To me the basis is the alternative behavior with the

exception for the DF bit. However, behaviors for datagrams orignated by the

server and delivered to the server over non datagram transport will need to

have recommendations also for IPv6.

I am not aware of any standard 1:1 mapping of IP level fields between UDP and TCP,  https://tools.ietf.org/html/rfc5766#section-12 does not define the behavior to set the fields, the topic was discussed in BEHAVE WG https://mailarchive.ietf.org/arch/msg/behave/QBZaYgk-x5lZNFpE4qCLiztcg8Y and the decision was to focus only on UDP to UDP case.  What specific change are you proposing in this Section ?

So I am not asking for a 1:1 mapping. What I see as missing is the definition of how shall be set in UDP packets sent out from the TURN server, and how to deal with any information in the incoming packets. I think this is something that should have recommendations as not being obvious for everyone, but at the same time such a description is not a huge task to define.

[TR] Okay, will add a new section (IP Header Fields for TCP-to-UDP translation).

For UDP packets generated based on Channel or Send Indications arriving at the TURN server over a TCP Transport I think the following should be done.  Note, this a rough sketch, some adjustment of the language should be done and formatted like the other options.

TTL: Set to default outgoing value.

DSCP: Set to value used by TCP connection, unless the server implements a remarker. Note, the TCP connection can only use a single DSCP code point so inter flow differentiation is not possible, see Section 5.1 of RFC 7657.

[TR] TTL and DSCP explanation looks good, will update draft.

ECN: No mechanism is defined to indicate what ECN value should be used for outgoing UDP packets for an allocations, therefore the ECN field shall be set to Not ECT (=0b00).

[TR] I think you mean the following:

Due to the lack of feedback mechanisms in UDP, Set the outgoing value to Not-ECT (=0b00).

Flow Label:

     [As discussed earlier based on the resulting UDP flow].

[TR] Flow Label is already discussed in IPv4-to-IPv6 and IPv6-to-IPv6 translations (sections 13. 1 and 13.2), and not specific to TCP-to-UDP translation. https://tools.ietf.org/html/draft-ietf-tram-turnbis-24#section-14 (IP header fields) does not discuss Flow label.

IPv4 Fragmentation:

      When the server sends a packet to a peer in

      response to a Send indication containing the DONT-FRAGMENT

      attribute, then set the DF bit in the outgoing IP header to 1.  In

      all other cases when sending an outgoing packet containing

      application data (e.g., Data indication, ChannelData message, or

      DONT-FRAGMENT attribute not included in the Send indication), set the DF bit

      in the outgoing IP header to 0.



[TR] Why not use the same behavior as UDP-to-UDP translation for IPv4 fragmentation ?



We can re-use the following text:

   IPv4 Fragmentation fields

      Preferred Behavior: When the server sends a packet to a peer in
      response to a Send indication containing the DONT-FRAGMENT
      attribute, then set the DF bit in the outgoing IP header to 1.  In
      all other cases when sending an outgoing packet containing
      application data (e.g., Data indication, ChannelData message, or
      DONT-FRAGMENT attribute not included in the Send indication), copy
      the DF bit from the DF bit of the incoming packet that contained
      the application data.

      Set the other fragmentation fields (Identification, More
      Fragments, Fragment Offset) as appropriate for a packet
      originating from the server.

      Alternate Behavior: As described in the Preferred Behavior, except
      always assume the incoming DF bit is 0.

      In both the Preferred and Alternate Behaviors, the resulting
      packet may be too large for the outgoing link.  If this is the
      case, then the normal fragmentation rules apply [RFC1122].



IPv6 Fragmentation:

           Independent if the TCP traffic arrives over IPv4 or IPv6 the fragmentation settings for outgoing  IPv6 UDP packets will have to follow what is defined for IPv4 to IPv6 translation and ignore the DF bit in incoming packets, and interpret the presence of the DONT-FRAGMENT attribute as DF=1 in incoming packet, and for all other cases consider DF=0 to apply.

 [TR] The behavior is already discussed in IPv4-to-IPv6 and IPv6-to-IPv6 translations in the draft. https://tools.ietf.org/html/draft-ietf-tram-turnbis-24#section-14 (IP header fields) section does not discuss IPv6 fragmentation.

 IPv4 Options



      Preferred Behavior: The outgoing packet is sent without any IPv4

      options.



 [TR] I will add IPv4 options.



IPv6 Extensions Headers:



      Set per default for originated IPv6 packets.



[TR] The behavior is already discussed in IPv6-to-IPv6 translations, https://tools.ietf.org/html/draft-ietf-tram-turnbis-24#section-14 (IP header fields)section does not discuss extension headers.







On Reception of UDP Packets



If TTL=0 then drop packet, else ignore.



DSCP: Ignore, the DSCP value for the Server to Client direction of the TCP connection should be based on the value

used for the client to server.



[TR] Both TTL and DSCP explanation looks good, will update draft.



ECN: Ignore. Higher layer protocols attempting to use ECN will not receive any ECN signal and thus sender

should stop sending ECT packets if sent.



[TR] I think you mean “Set the outgoing value to Not-ECT (=0b00).”



Flow Label: Ignore, the TCP connection has its own that is related to peer to server flow.

[TR] Flow Label is already discussed in IPv4-to-IPv6 and IPv6-to-IPv6 translations (sections 13. 1 and 13.2), and not specific to UDP-to-TCP translation between the peer and the client.

Fragmentation:



Any fragmented packets are reassembled in server and then forwarded to the client over the TCP connection.

ICMP messages resulting from sent UDP packets, MUST be forward to client using TURN's mechanism for relevant ICMP types.



IPv4 Options are processed by server if possible, else ignored



[TR] Let’s use the same behavior as UDP-to-UDP translation for IPv4 options.



IPv6 Extension headers are processed by server if possible as intended endpoint, else ignored.



[TR] The IPv6 Extension behavior is already discussed in IPv6-to-IPv6 translation.







Y. Section 16.4.  DATA



   The DATA attribute is present in all Send and Data indications.  The

   value portion of this attribute is variable length and consists of

   the application data (that is, the data that would immediately follow

   the UDP header if the data was been sent directly between the client

   and the peer).  If the length of this attribute is not a multiple of

   4, then padding must be added after this attribute.



Can you please clarify if one would get all the remaining bytes of

the IP packet payload or only the number of bytes the UDP length field

indicates ?

The reason I ask is that there is possibility that there are a

discrepancy between these fields, something the proposal for an

experimental specification for UDP options attempt to utilize.

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/



Note, I only want you to clarify what is actually included. I would

assume using the UDP length field makes sense in this case.

The application data does not include the options discussed in draft-ietf-

tsvwg-udp-options.

Please clarify the specific update you are looking in this section.

My intention here was not to bring in UDP options, only to ensure that the

specification text is clear. As UDP options draft points out there could be a

discrepancy between the UDP length and IP length. Thus, I think there is a point

to make it clear that the data includes UDP length -8 bytes of UDP payload.

Possible include a informative reference for why there might be a discrepancy.

The data only includes the application data, and the length of the attribute is also based on the application data, and I don't see any discrepancy in the client to determine the length of the application data.

To avoid any future confusion if UDP options gets deployed I think this document can clarify that the DATA part is what is defined as UDP user data in the below figure, i.e. the UDP length field - UDP header length amount of data after the UDP header in the IP packet such that the surplus area never is included.

                             IP transport payload

                <------------------------------------------------->

      +--------+---------+----------------------+------------------+

      | IP Hdr | UDP Hdr |     UDP user data    |   surplus area   |

      +--------+---------+----------------------+------------------+

                <------------------------------>

                           UDP Length



               Figure 3 IP transport payload vs. UDP Length

Note, this is to my understanding what is called UDP user data is what the current OS implementations will give you if you use their interfaces, but if the TURN Server is implemented using RAW IP packets this nuance may be missed.

[TR] Thanks for the explanation, I will add the following the line to avoid future confusion:

The application data is equivalent to the "UDP user data" and does not include the "surplus area" defined in Section 4 of draft-ietf-tsvwg-udp-options.

Cheers,

-Tiru



AI. DTLS Cipher Suits



Am I understanding it correct that the definition of what DTLS cipher

suit that a TURN Server currently is to support is the ones in RFC 7525 ?

No, the cipher suites and (D)TLS profile is discussed in

https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3 and it

follows the recommendations in RFC7525.



Ahaa, of course. But, maybe an explicit reference to STUNbis in section

2.1 that the transports for TURN and STUN messages are defined there?



In that case, I think the wording is a bit weak as the only reference

I find are in Section 2.1:



If (D)TLS transport is

   used between the TURN client and the TURN server, the guidance given

   in [RFC7525] MUST be followed to avoid attacks on (D)TLS.

RFC7525 provides various recommendations to avoid attacks on (D)TLS.

It was really the text in STUNbis that I was looking for.

Okay, modified the above line as follows:



   If (D)TLS transport is

   used between the TURN client and the TURN server, the cipher suites

   discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis] and the guidance

   given in [RFC7525] MUST be followed to avoid attacks on (D)TLS.



Looks good to me.



Cheers



Magnus Westerlund



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

Network Architecture & Protocols, Ericsson Research

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

Ericsson AB                 | Phone  [phone]

Torshamnsgatan 23           | Mobile [phone]

SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>

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