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

[Magnus Westerlund <[e-mail]>]

Hi,

I think we are getting close to resolve all issues. Removed the parts where there are conclusion since earlier.

On 2019-04-28 11:47, Konda, Tirumaleswar Reddy wrote:
Hi Magnus,

Please see inline [TR]

From: Magnus Westerlund <[e-mail]><mailto:[e-mail]>
Sent: Friday, April 26, 2019 5:07 PM
To: Konda, Tirumaleswar Reddy <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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:



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

Ok. lets end the discussion of this without any change.


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.











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

I actually mean that there are no mechanism for negotiating and have allocations set the ECT value in outgoing and propagate the received ECN in Data indication to the TURN client. The application on top of the UDP may actually implement an ECN feedback scheme. These exist for both QUIC and RTP for example.

I


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

Because you can't copy the DF bit from the incoming packet. There are no 1-to-1 correspondence here. With TCP to UDP I can easily generate a SEND indication requesting that a oversized packet be sent.  That send indication will be fragmented after all by TCP over multiple packets. So it becomes the TURN server to determine if the packet can be sent at all due to interface limitations. For this case I think the most straight forward solution is simply to have the client indicate when it want the DF set.




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.

Well, in this case the TURN server is originating a packet, which is why section 14 applies to these outgoing packets to the peer. And as you note it doesn't discuss IPv6 fragmentation. Thus, I think there need to be a definition. That can either be specified in this section or by reference. The translation scenarios don't apply.


 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.

Like before this is section 14 text, and not a translation scenario.








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

No, this is incoming. I just wanted to note that the ECN signal is dropped in the TURN server for incoming packets.




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.

This is not a translation scenario, but it is irrelevant. So if you simply want to say "Ignore" or not discuss it at all doesn't matter to me.


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.

I can't find that there are anything at all written about this, and that is likely fine. Or did you have any particular text in mind? In that case please quote.




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.

Sure.








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.

Good.


Cheers,

-Tiru


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