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

[Magnus Westerlund <[e-mail]>]

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.





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.

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? Maybe remove the sentence and simply add something about "that the client supports" in the prior sentence.





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.

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.

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).

Flow Label:

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

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.


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.



 IPv4 Options

      Preferred Behavior: The outgoing packet is sent without any IPv4
      options.


IPv6 Extensions Headers:

      Set per default for originated IPv6 packets.

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.

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.

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

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
IPv6 Extension headers are processed by server if possible as intended endpoint, else ignored.









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.






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]>
----------------------------------------------------------------------