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

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 11 Apr 2019 08:26:11 +0000

Hi Magnus,

Thanks for the detailed review. Please see inline 

> -----Original Message-----
> From: tram <[email-masked]> On Behalf Of Magnus Westerlund
> Sent: Thursday, April 4, 2019 7:30 PM
> To: [email-masked]; [email-masked]
> Subject: [tram] AD Evaluation of draft-ietf-tram-turnbis-23
> 
> 
> 
> Hi,
> 
> I have now finished the AD review. There are a lot of details that I think needs
> fixing or at least feedback on. I also think there are a couple of more serious
> issues here. Especially regarding the handling of MTU and fragmentation, as
> well as IP header fields in address family translation and with non UDP
> transport. We need to conclude on these before we go to IETF last call.
> 
> My Review comments are:
> 
> A. Section 1: "The client can arrange
>    for the server to relay packets to and from certain other hosts
>    (called peers) and can control aspects of how the relaying is done."
> 
> I don't think this is an accurate description of what Turn does. One may easily
> get the impression that the whole packet TURN receives are relayed, rather
> than the transport protocol data part and some of the header information are
> relayed between the client <-> peer, with a knowledge of the peer transport
> address for the client. I think that should be clarified in the introduction.

Sure, updated the text as follows:

When a peer sends a packet to the relayed transport address, the server relays the transport protocol data from the packet to the client. The client knows the peer from which the transport protocol data was relayed by the server. When the server receives an ICMP 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.

> 
> B. Section 2.7:
> 
> "Applications using TCP can more or less
>    ignore this issue because fragmentation avoidance is now a standard
>    part of TCP, but applications using UDP (and thus any application
>    using this version of TURN) must handle fragmentation avoidance
>    themselves."
> 
> Lower case "must", and as the document uses RFC 2119, this must have the
> meaning of "MUST". A reformulation here is likely in order.

Replaced "must" with "MUST". 

> 
> C. Section 2.7:
> 
>    In this approach, the application exploits the
>    fact that the IP specification [RFC0791] specifies that IP packets up
>    to 576 bytes should never need to be fragmented.
> 
>    As a guideline, sending a maximum of 500 bytes of application data in
>    a single TURN message (by the client on the client-to-server leg) or
>    a UDP datagram (by the peer on the peer-to-server leg) will generally
>    avoid IP fragmentation.  To further reduce the chance of
>    fragmentation, it is recommended that the client use ChannelData
>    messages when transferring significant volumes of data, since the
>    overhead of the ChannelData message is less than Send and Data
>    indications.
> 
> In that first paragraph I think it is worth discussing the IPv6 requirement of
> supporting a 1280 minimal size.

Yes. 

> 
> Secondly, I think recommending only a 500 MTU is way to conservative.
> Those studies I have seen appears to indicate that at least 1220 bytes UDP
> payloads should be be working as well as 500 bytes. See for example figure 12
> in this:
> https://static.googleusercontent.com/media/research.google.com/sv//pubs/arc
> hive/46403.pdf

I have updated the text as follows to address your comments:

   In this approach, the application MUST assume a
   PMTU of 1280 bytes, as IPv6 requires that every link in the Internet
   have an MTU of 1280 octets or greater as specified in [RFC8200].  If
   IPv4 support on legacy or otherwise unusual networks is a
   consideration, the application MAY assume on a PMTU of 576 bytes for
   IPv4 datagrams, as every IPv4 host must be capable of receiving a
   packet whose length is equal to 576 bytes as discussed in [RFC0791].

> 
> 
> D. Section 2.7:
> 
>    [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that
>    uses STUN to discover the path MTU, and so might be a suitable
>    approach to be used in conjunction with a TURN server that supports
>    the DONT-FRAGMENT attribute.  When the client includes the DONT-
>    FRAGMENT attribute in a Send indication, this tells the server to set
>    the DF bit in the resulting UDP datagram that it sends to the peer.
>    Since some servers may be unable to set the DF bit, the client should
>    also include this attribute in the Allocate request -- any server
>    that does not support the DONT-FRAGMENT attribute will indicate this
>    by rejecting the Allocate request.
> 
> I want to verify that the WG is working on resolving the issues with the STUN
> PMTUD document. I definitely sees the point of the recommendation, but only
> if the WG will conclude on that document in a reasonable time frame.

The authors of the ietf-tram-stun-pmtud draft are working on resolving the DISCUSS from ISEG review.

> 
> E. Section 3:
> 
>    Server-Reflexive Transport Address:  A transport address on the
>       "public side" of a NAT.  This address is allocated by the NAT to
>       correspond to a specific host transport address.
> 
> Shouldn't "public side" be replace with "external side"? That is the terminology
> used by the Behave RFCs.

Okay, replaced "public side" with "external side". 

> 
> F. Section 3:
> 
>    5-tuple:  The combination (client IP address and port, server IP
>       address and port, and transport protocol (currently one of UDP,
>       TCP, or (D)TLS)) used to communicate between the client and the
>       server.
> 
> I see some issues that the 5-tuple aggregates the transport protocol with the
> security protocol. I agree from the TURN protocol perspective the protocol
> combination is the important one. However, writing like you do here you
> obfuscate both that when security is in place you have a combination, as well as
> that there are 4 alternatives defined by this document.

(D)TLS can be considered as pseudo transport protocol. 

> 
> G. Section 4.1:
> 
>    The "turn" and "turns" URI schemes are used to designate a TURN
>    server (also known as a relay) on Internet hosts accessible using the
>    TURN protocol.  The TURN protocol supports sending messages over UDP,
>    TCP, TLS-over-TCP or DTLS-over-UDP.  The "turns" URI scheme MUST be
>    used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the
>    "turn" scheme MUST be used otherwise.  The required <host> part of
>    the "turn" URI denotes the TURN server host.  The <port> part, if
>    present, denotes the port on which the TURN server is awaiting
>    connection requests.  If it is absent, the default port is 3478 for
>    both UDP and TCP.  The default port for TURN over TLS and TURN over
>    DTLS is 5349.
> 
> First, I was wondering if this document needed to update RFC 7065? The high
> level obvious is the reference, but otherwise on the surface it doesn't look
> necessary. My main complaint when reading was that it was not obvious what
> not specifying the transport parameter means. Then I saw this in Section 3.1 of
> RFC 7065:
> 
>    The <host>, <port>, and <transport> components are passed without
>    modification to the [RFC5928] algorithm.  <secure> is set to false if
>    <scheme> is equal to "turn", and set to true if <scheme> is equal to
>    "turns" and passed to the [RFC5928] algorithm with the other
>    components.
> 
> After some digging I figured out that RFC5928 is actually updated by RFC
> 7350 that defines the resolution and SRV records for DTLS.
> 
> Can you please update the text in Section 4 to also reference RFC 7350 so that
> one doesn't miss this definitions.

Sure, added the following line to Section 4:
DTLS as a transport protocol for TURN is defined in RFC7350.

> 
> 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. Section 5:
> 
>    For each Allocate request, the server SHOULD generate a
>    new random nonce when the allocation is first attempted following the
>    randomness recommendations in [RFC4086] and SHOULD expire the nonce
>    at least once every hour during the lifetime of the allocation.
> 
> So, I think this text due to its use of RFC 2119 language is a bit confusing in its
> relation to STUNbis. To me it is unclear if the above overrides completely what
> is written in Section 5 of STUNbis:
> 
>    To indicate that it supports this specification, a server MUST
>    prepend the NONCE attribute value with the character string composed
>    of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648]
>    encoding of the 24 bit STUN Security Features as defined in
>    Section 18.1.  The 24 bit Security Feature set is encoded as 3 bytes,
>    with bit 0 as the most significant bit of the first byte and bit 23
>    as the least significant bit of the third byte.  If no security
>    features are used, then a byte array with all 24 bits set to zero
>    MUST be encoded instead.  For the remainder of this document the term
>    "nonce cookie" will refer to the complete 13 character string
>    prepended to the NONCE attribute value.
> 
> Or is the randomness recommendations in TURNbis only for the NONCE
> attribute value part?

Yes, the randomness recommendations in TURNbis is only for the NONCE attribute value part. 

> 
> Secondly, I interpret the text to say that compared to STUN, where a Nonce can
> be long lived after the initial Long Term Credential establishment, in TURN for
> each allocation one will have to to the Allocate, expired nonce->here is your
> new nonce, resend allocate using new nonce, success dance.
> 
> I think part of the problem with the above text in TURNbis is that the sentences
> prior to the quoted one appear to be rehashing of the STUNbis requirements.
> Then the quoted part that actually changes behavior without being clear about
> it. I think it would be good to make it clear what is a change compared to
> STUNbis.

No changes other than the randomness for the NONCE attribute value part.  Added the following line for clarity:

To indicate that the server supports [I-D.ietf-tram-stunbis], the server
 prepends the NONCE attribute value with the "nonce cookie"
(Section 9.2 of [I-D.ietf-tram-stunbis]).

Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-18, discusses using the nonce cookie with the STUN security feature for the NONCE attribute 
sent in the Allocate response.

> 
> J. Section 6:
> 
>    Note that, rather than storing the password explicitly, for
>    security reasons, it may be desirable for the server to store the key
>    value, which is a secure hash over the username, realm, and password
>    (see [I-D.ietf-tram-stunbis]).
> 
> Why isn't this recommendation stronger. Are there any reasons why a server
> would actually store the plain text password at all?

Good point, no reason to store the plain text password. Updated text as follows:

For security reasons, the server MUST NOT store the
password explicitly and MUST store the key value, which is a secure
hash over the username, realm, and password (see Section 16.1.3 in
[I-D.ietf-tram-stunbis]).

> 
> K. Section 7.1:
> 
>    The client first picks a host transport address.  It is RECOMMENDED
>    that the client pick a currently unused transport address, typically
>    by allowing the underlying OS to pick a currently unused port for a
>    new socket.
> 
> I think talk about socket in this context should be skipped as it otherwise have
> been eliminated.

The above text is from https://tools.ietf.org/html/rfc5766#section-6.1. I presume you are proposing the following update:
 
    The client first picks a host transport address.  It is RECOMMENDED
    that the client pick a currently unused transport address, typically
    by allowing the underlying OS to pick a currently unused port.

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

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

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

> 
> 2) The RFC5928 reference  should be complemented with an RFC 7350
> reference.

Done.

> 
> N. Section 7.1:
> 
>   Clients MUST NOT include a REQUESTED-ADDRESS-
>    FAMILY attribute in an Allocate request that contains a RESERVATION-
>    TOKEN attribute, for the reasons outlined in [RFC6156].
> 
> Considering that this document obsoletes RFC 6156, I think it is bad form to
> reference that document, rather than to move the necessary motivation into
> this document.

Done, updated text as follows:
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Allocate request that contains a RESERVATION-TOKEN attribute, for the reason that server uses the previously reserved transport address corresponding to the included token and the client cannot obtain a relayed transport address of a specific address type.

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

> 
> P. Section 7.2:
> 
>          Otherwise, if the attribute is included but
>         specifies a protocol other that UDP, the server rejects the
>         request with a 442 (Unsupported Transport Protocol) error.
> 
> Assuming that you don't support an extension for that transport protocol.
> Should that be made explicit?

I did not get the above comment. The attribute REQUESTED-TRANSPORT is originally defined in TURN (see https://tools.ietf.org/html/rfc5766#section-6.2), and TURNbis does not update the use of the attribute.

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

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

> 
> S. Section 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.  The padding is not reflected in the length
>    field of the ChannelData message, so the actual size of a ChannelData
>    message (including padding) is (4 + Length) rounded up to the nearest
>    multiple of 4.  Over UDP, the padding is not required but MAY be
>    included.
> 
> Are there anywhere written what one may or may not include of the TURN
> related messages in a single UDP datagram. Because it is technically feasible I
> belive to include two Send Indications in one UDP datagram to the server.

As per https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-11.2, one send indication in one UDP datagram to the server.

> 
> T. Section 13.1:
> 
>    Flow Label
> 
>       Preferred behavior: The relay sets the Flow label to 0.  The relay
>       can choose to set the Flow label to a different value if it
>       supports the IPv6 Flow Label field [RFC6437].
> 
>       Alternate behavior: The relay sets the Flow label to the default
>       value for outgoing packets.
> 
> I think this section should be improved in two ways.
> 
> First of all I think it should clarify that each allocation to peer flow is its own
> IPv6 Flow in perspective of the IPv6 Flow label.
> 
> Secondly, I think in the spirit of RFC 6473 the preferred behavior should be to
> set the IPv6 flow label if the implementation is capable, or leave it to the
> underlying network stack to actually set it. Compared to RFC 7915, the TURN
> server actually have an understanding of what are different flows without
> having examining additional protocol layers.

Updated text as follows:

Preferred behavior:
The TURN server can use the relayed transport address, peer transport address and UDP protocol number 
to generate and set the flow label value in the IPv6 packet as discussed in Section 3 of [RFC6437]. If the TURN server is incapable of 
generating the flow label value from the IPv6 packet's 5-tuple, it sets the Flow label to 0. 

(Please note the proposed update deviates from the behavior defined https://tools.ietf.org/html/rfc6156#section-8.1)   

> 
> Thirdly, I don't understand what the alternative behavior actually is.
> This as it is either setting it to 0, or classifying things as flow and then provide it
> with a random flow label. I think the right alternative behavior is to set it 0.

Updated text to say:

       Alternate behavior: The relay sets the Flow label to the default
       value of zero for outgoing packets.

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

> 
> V. Section 13.2:
> 
> Fragmentation:
> 
>       If the incoming packet included a Fragment header and the outgoing
>       packet size exceeds the outgoing link's MTU, the relay MUST
>       fragment the outgoing packet into fragments of no more than 1280
>       bytes.  The relay sets the fields of the Fragment header as
>       appropriate for a packet originating from the server.
> 
> Is really the intention here to refragment the packet without providing any
> indication that the practical MTU is smaller than what the peer or client thinks
> it is?

Yes, TURNbis is following the existing behavior already defined in https://tools.ietf.org/html/rfc6156#section-8.1. 

> 
> W. Section 14:
> 
>       Preferred Behavior: Set the outgoing value to the incoming value,
>       UNLESS the server is doing Active Queue Management, the incoming
>       ECN field is ECT(1) (=0b01) or ECT(0) (=0b10), and the server
>       wishes to indicate that congestion has been experienced, in which
>       case set the outgoing value to CE (=0b11).
> 
> First of all do you have any special meaning with all capital UNLESS?
> 
> Secondly, I don't know how wise it is to have partial definitions of what the ECN
> behavior is. Maybe simpler to say that that the relay is performing AQM it can
> support the ECN marking behavior as defined in RFC 3168.

The above text is same as https://tools.ietf.org/html/rfc5766#section-12, replaced "UNLESS" with "unless".

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

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

> 
> Z. The use of "relay" in the meaning of "Turn Server". There are many
> occurrences of relay in this meaning. Either make it explicit to be a synonym or
> change it to server.

Sure, updated draft.

> 
> AA. Section 16.7
> 
> rffu is lacking a definition. I would suggest making it upper case and copy the
> definition from 16.8.

Updated.

> 
> AB. Section 16.12:
> 
> Rsvd in Format figure does not match definition below which uses "Reserved".

Fixed.

> 
> AC. Section 16.12:
> 
> Reason Phrase (variable). This field is under defined. First of all the format of
> the text string is not defined, which it is in Stunbis Error-Code attribute is
> defined as.
> 
>    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).

Thanks, updated section to use UTF-8 encoding.  

> 
> Secondly, I think it might be worth pointing out the padding here. It is not clear
> if there is any form of string termination and how the padding which will be
> interpreted as NULL characters 0-3 depending on the alignment. I note this
> later issue appears to be existing in STUNBis also.

Padding is discussed in STUN for variable length attributes, please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-18#section-14.  

> 
> AD. Section 16.2:
> 
> Why isn't the text here say that this attribute may also be used to indicate the
> desired lifetime in allocation requests?

https://tools.ietf.org/html/rfc5766#section-14.2 did not discuss desired lifetime. Anyways, added the following line:
The TURN client can include the LIFETIME attribute with the desired lifetime in Allocate and Refresh requests.

> 
> AE. Section 16.9: DONT-FRAGMENT
> 
> I think it would be good to indicate the use of the attribute in Allocate Requests
> also.

The above point is discussed in Section 7.1:

<snip>
   If the client wishes to later use the DONT-FRAGMENT attribute in one
   or more Send indications on this allocation, then the client SHOULD
   include the DONT-FRAGMENT attribute in the Allocate request.  This
   allows the client to test whether this attribute is supported by the
   server.
</snip>

> 
> AF. Section  24.2
> 
> [Protocol-Numbers]
>               "IANA Protocol Numbers Registry", 2005,
>               <http://www.iana.org/assignments/protocol-numbers>.
> 
> This is a normative reference based on how it is used in Section 16.8.

Okay, moved as Normative reference.

> 
> AG. Seciton 18.
> 
>    Sometime before the 20 minute lifetime is up, the client refreshes
>    the allocation.  This is done using a Refresh request.  As before,
>    the client includes the latest username, realm, and nonce values in
>    the request.  The client also includes the SOFTWARE attribute,
>    following the recommended practice of always including this attribute
>    in Allocate and Refresh messages.  When the server receives the
>    Refresh request, it notices that the nonce value has expired, and so
>    replies with 438 (Stale Nonce) error given a new nonce value.  The
>    client then reattempts the request, this time with the new nonce
>    value.  This second attempt is accepted, and the server replies with
>    a success response.  Note that the client did not include a LIFETIME
>    attribute in the request, so the server refreshes the allocation for
>    the default lifetime of 10 minutes (as can be seen by the LIFETIME
>    attribute in the success response).
> 
> I notice that this part nor the text before appears to discuss the permission
> lifetime that will expire after 5 minutes. Thus, it needs to be refreshed prior to
> the Allocation.

I have added text to discuss refreshing the channel binding, https://tools.ietf.org/html/rfc5766#section-16 did not discuss refreshing the permissions and channel bindings.  

> 
> AH. Section 18.
> 
> I am missing any example having to do with Address Family interactions.

There was no ask from the WG members to add an example and even https://tools.ietf.org/html/rfc6156 did not have an translation example.

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

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

Best Regards,
-Tiru

> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Apr 2019 12:32:29 +0000

Hi,

Thanks for the reply. Sorry about the delay in responding. Comments below.

On 2019-04-11 10:27, Konda, Tirumaleswar Reddy wrote:
> When a peer sends a packet to the relayed transport address, the server relays the transport protocol data from the packet to the client. The client knows the peer from which the transport protocol data was relayed by the server. When the server receives an ICMP

Should the last "When" be an "If"?

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

Othewise fine with me.

> Replaced "must" with "MUST". 

I think it is inappropriate to make this into a MUST statement. There is
no single answer for how the application handles it. The application
needs to handle it or live with the consequences. I think swithing the
"must" to "needs to" is more appropriate.

>    packet whose length is equal to 576 bytes as discussed in [RFC0791].

Yes, I think that is quite good.

> The authors of the ietf-tram-stun-pmtud draft are working on resolving the DISCUSS from ISEG review.

Great, looking forward to have that Discuss resolved.

> (D)TLS can be considered as pseudo transport protocol. 

May I suggest that you simple reword it in this way:

   5-tuple:  The combination (client IP address and port, server IP
      address and port, and transport protocol (currently one of UDP,
      TCP, DTLS/UDP or TLS/TCP)) used to communicate between the client
and the
      server.  The 5-tuple uniquely identifies this communication
      stream.  The 5-tuple also uniquely identifies the Allocation on
      the server.

In this specification you are using the words Transport Protocol in a
way that is not the most common understanding of the word. Thus, I think
you should include a definition in section 3 of your usage of "Transport
Protocol".

Transport Protocol: The protocols above IP that carries TURN Requests,
Responses, and Indications as well as providing identifiable flows using
a 5-tuple. In this specification UDP and TCP is defined as well as their
combination with a security layer using DTLS and TLS respectively.

> DTLS as a transport protocol for TURN is defined in RFC7350.
Ok.
> 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.

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?

> sent in the Allocate response.

Ok, that clarifies the randomness part.

> [I-D.ietf-tram-stunbis]).

Looks okay to me.

>     by allowing the underlying OS to pick a currently unused port.

Yes, I see no loss of real information.

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

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?

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

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

> Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Allocate request that contains a RESERVATION-TOKEN attribute, for the reason that server uses the previously reserved transport a…

Works for me.

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

> I did not get the above comment. The attribute REQUESTED-TRANSPORT is originally defined in TURN (see https://tools.ietf.org/html/rfc5766#section-6.2), and TURNbis does not update the use of the at…

I am requesting a clarification in the text like this:

		Otherwise, if the attribute is included but
        specifies a protocol other that UDP that is not supported by the server, then the server rejects the
        request with a 442 (Unsupported Transport Protocol) error.

What I mean with extension above is the case when the TURN server supports an TURN extension that define for example TCP as server to peer protocol. 

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

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

> As per https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-11.2, one send indication in one UDP datagram to the server.

Okay, the procedure described indicates that only a single Indication
per UDP datagram . I think that is good enough.

> (Please note the proposed update deviates from the behavior defined https://tools.ietf.org/html/rfc6156#section-8.1)  

Good, but I would suggest some tweaks to clarify:

Preferred behavior:
The TURN server can use the 5-tuple of relayed transport address, peer transport address and UDP protocol number to identify each flow, generate and set the flow label value in the IPv6 packet as discussed in Section 3 of [RFC6437]. If the TURN server is incapable of generating the flow label value from the IPv6 packet's 5-tuple, it sets the Flow label to 0. 

>        value of zero for outgoing packets.

Ok

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

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. 

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

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

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 soley on IPv4 DF and IPv6 Fragmentation Header to
control the fragmentation.

  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.

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?

IF you agree I can file an errata on this.

> Yes, TURNbis is following the existing behavior already defined in https://tools.ietf.org/html/rfc6156#section-8.1. 
Okay.
> The above text is same as https://tools.ietf.org/html/rfc5766#section-12, replaced "UNLESS" with "unless".

So the UNLESS Is only for emphasis?

I think the sentence could be formulated so that it is easier to
understand that the text after "... active queue managmenet, ..." is in
case on does AQM. Also I think it is worth clarifying that the TURN
server can operate as defined by RFC 3168. In addition the use of ECT(1)
experiments has been changed so that also needs a reference. So perhaps:

      Preferred Behavior: Set the outgoing value to the incoming value. The server may perform Active Queue Management, in which case it SHOULD behave as a ECN aware router [RFC3168] and can mark traffic with Congestion Experienced (CE) instead of dropping the packet. The use of ECT(1) is subject to experimental usage [RFC8311].

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

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

> Padding is discussed in STUN for variable length attributes, please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-18#section-14.  

Thanks, missed that. I think that is clear.

> The TURN client can include the LIFETIME attribute with the desired lifetime in Allocate and Refresh requests.

Good.

>    allows the client to test whether this attribute is supported by the

Yes, but I think it is inconsistent when the text says:

This attribute is used by the client to request that the server set
   the DF (Don't Fragment) bit in the IP header when relaying the
   application data onward to the peer.

And there the is additional usage of it. When a minor change would
indicate that alternative use also.

This attribute is used by the client to request that the server set
   the DF (Don't Fragment) bit in the IP header when relaying the
   application data onward to the peer, and for determining the
capability in Allocate requests.

> Okay, moved as Normative reference.
Good.
> I have added text to discuss refreshing the channel binding, https://tools.ietf.org/html/rfc5766#section-16 did not discuss refreshing the permissions and channel bindings.  
Ok.
> There was no ask from the WG members to add an example and even https://tools.ietf.org/html/rfc6156 did not have an translation example.
Ok, let skip this for now. But, it will be commented on again most
likely by other reviewers.
> 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?

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

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

Cheers

Magnus Westerlund

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 18 Apr 2019 08:18:45 +0000

Hi Magnus,

Please see inline

> Sent: Tuesday, April 16, 2019 6:02 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> Hi,
> 

No worries.

> >> I have now finished the AD review. There are a lot of details that I
> >> think needs fixing or at least feedback on. I also think there are a
> >> couple of more serious issues here. Especially regarding the handling
> >> of MTU and fragmentation, as well as IP header fields in address
> >> family translation and with non UDP transport. We need to conclude on
> these before we go to IETF last call.
> >>
> >> My Review comments are:
> >>
> >> I don't think this is an accurate description of what Turn does. One
> >> may easily get the impression that the whole packet TURN receives are
> >> relayed, rather than the transport protocol data part and some of the
> >> header information are relayed between the client <-> peer, with a
> >> knowledge of the peer transport address for the client. I think that should be
> clarified in the introduction.
> > When a peer sends a packet to the relayed transport address, the
> > server relays the transport protocol data from the packet to the
> > client. The client knows the peer from which the transport protocol
> > data was relayed by the server. When the server receives an ICMP
> 

Yes, fixed.

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

> >> Lower case "must", and as the document uses RFC 2119, this must have
> >> the meaning of "MUST". A reformulation here is likely in order.
> I think it is inappropriate to make this into a MUST statement. There is no
> single answer for how the application handles it. The application needs to
> handle it or live with the consequences. I think swithing the "must" to "needs
> to" is more appropriate.

Okay, updated. 

> >> In that first paragraph I think it is worth discussing the IPv6
> >> requirement of supporting a 1280 minimal size.
> > Yes.
> >
> >> Those studies I have seen appears to indicate that at least 1220
> >> bytes UDP payloads should be be working as well as 500 bytes. See for
> >> example figure 12 in this:
> >> I want to verify that the WG is working on resolving the issues with
> >> the STUN PMTUD document. I definitely sees the point of the
> >> recommendation, but only if the WG will conclude on that document in a
> reasonable time frame.

Me too :)

> >> Shouldn't "public side" be replace with "external side"? That is the
> >> terminology used by the Behave RFCs.
> >> I see some issues that the 5-tuple aggregates the transport protocol
> >> with the security protocol. I agree from the TURN protocol
> >> perspective the protocol combination is the important one. However,
> >> writing like you do here you obfuscate both that when security is in
> >> place you have a combination, as well as that there are 4 alternatives
> defined by this document.
>       TCP, DTLS/UDP or TLS/TCP)) used to communicate between the client and
> the

Looks good, updated.

> 
> In this specification you are using the words Transport Protocol in a way that is
> not the most common understanding of the word. Thus, I think you should
> include a definition in section 3 of your usage of "Transport Protocol".
> 
> Responses, and Indications as well as providing identifiable flows using a 5-
> tuple. In this specification UDP and TCP is defined as well as their combination
> with a security layer using DTLS and TLS respectively.

Thanks, added above definition.

> >> First, I was wondering if this document needed to update RFC 7065?
> >> The high level obvious is the reference, but otherwise on the surface
> >> it doesn't look necessary. My main complaint when reading was that it
> >> was not obvious what not specifying the transport parameter means.
> >> Then I saw this in Section 3.1 of RFC 7065:
> >>
> >> Can you please update the text in Section 4 to also reference RFC
> >> 7350 so that one doesn't miss this definitions.
> >> 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, I think this text due to its use of RFC 2119 language is a bit
> >> confusing in its relation to STUNbis. To me it is unclear if the
> >> above overrides completely what is written in Section 5 of STUNbis:
> >>
> >> Secondly, I interpret the text to say that compared to STUN, where a
> >> Nonce can be long lived after the initial Long Term Credential
> >> establishment, in TURN for each allocation one will have to to the
> >> Allocate, expired nonce->here is your new nonce, resend allocate using new
> nonce, success dance.
> >>
> >> I think part of the problem with the above text in TURNbis is that
> >> the sentences prior to the quoted one appear to be rehashing of the STUNbis
> requirements.
> >> Then the quoted part that actually changes behavior without being
> >> clear about it. I think it would be good to make it clear what is a
> >> change compared to STUNbis.
> > To indicate that the server supports [I-D.ietf-tram-stunbis], the
> > server  prepends the NONCE attribute value with the "nonce cookie"
> > Please see
> > https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-18, discusses
> using the nonce cookie with the STUN security feature for the NONCE attribute
> >> Why isn't this recommendation stronger. Are there any reasons why a
> >> server would actually store the plain text password at all?
> > For security reasons, the server MUST NOT store the password
> > explicitly and MUST store the key value, which is a secure hash over
> > the username, realm, and password (see Section 16.1.3 in
> >> I think talk about socket in this context should be skipped as it
> >> otherwise have been eliminated.
> > The above text is from https://tools.ietf.org/html/rfc5766#section-6.1. I
> presume you are proposing the following update:
> >

Okay, Updated.

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

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

> >> 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.
> > The client then picks a transport protocol to use between the client and the
> server based on the transport protocols supported by the server.
> 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:
> 

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.

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

> >> Considering that this document obsoletes RFC 6156, I think it is bad
> >> form to reference that document, rather than to move the necessary
> >> motivation into this document.
> > Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an
> Allocate request that contains a RESERVATION-TOKEN attribute, for the reason
> that server uses the previously reserved transport address corresponding to the
> included token and the client cannot obtain a relayed transport address of a
> specific address type.
> 
> Works for me.
> 
> >
> >> O. Section 7.1:
> >>
> >> 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.
> >>
> > The text in Section 7.1 is added for TURN clients not supporting TURNbis
> specification to provide backward compatibility.
> 
> 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

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.  

> > I did not get the above comment. The attribute REQUESTED-TRANSPORT is
> originally defined in TURN (see https://tools.ietf.org/html/rfc5766#section-6.2),
> and TURNbis does not update the use of the attribute.
> 
> What I mean with extension above is the case when the TURN server supports
> an TURN extension that define for example TCP as server to peer protocol.

Works for me, updated draft.

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

> (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.
> >> Are there anywhere written what one may or may not include of the
> >> TURN related messages in a single UDP datagram. Because it is
> >> technically feasible I belive to include two Send Indications in one UDP
> datagram to the server.
> > As per https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-11.2, one
> send indication in one UDP datagram to the server.
> 
> Okay, the procedure described indicates that only a single Indication per UDP
> datagram . I think that is good enough.
> 
> 
> >
> >> T. Section 13.1:
> >>
> >>    Flow Label
> >>
> >> Secondly, I think in the spirit of RFC 6473 the preferred behavior
> >> should be to set the IPv6 flow label if the implementation is
> >> capable, or leave it to the underlying network stack to actually set
> >> it. Compared to RFC 7915, the TURN server actually have an
> >> understanding of what are different flows without having examining
> additional protocol layers.
> > Updated text as follows:
> >
> > Preferred behavior:
> > The TURN server can use the relayed transport address, peer transport
> > address and UDP protocol number to generate and set the flow label
> > value in the IPv6 packet as discussed in Section 3 of [RFC6437]. If the TURN
> server is incapable of generating the flow label value from the IPv6 packet's 5-
> tuple, it sets the Flow label to 0.
> >
> > (Please note the proposed update deviates from the behavior defined
> > https://tools.ietf.org/html/rfc6156#section-8.1)
> 
> The TURN server can use the 5-tuple of relayed transport address, peer
> transport address and UDP protocol number to identify each flow, generate and
> set the flow label value in the IPv6 packet as discussed in Section 3 of
> [RFC6437]. If the TURN server is incapable of generating the flow label value
> from the IPv6 packet's 5-tuple, it sets the Flow label to 0.

Thanks, Updated draft.

> 
> (Please note the proposed update deviates from the behavior defined
> https://tools.ietf.org/html/rfc6156#section-8.1)
> 
> 
> 
> >
> >
> >
> >> This as it is either setting it to 0, or classifying things as flow
> >> and then provide it with a random flow label. I think the right alternative
> behavior is to set it 0.
> > Updated text to say:
> >
> >> 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.
> > [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.
> 
> 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. 

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

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

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

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

> >> Is really the intention here to refragment the packet without
> >> providing any indication that the practical MTU is smaller than what
> >> the peer or client thinks it is?
> > Yes, TURNbis is following the existing behavior already defined in
> https://tools.ietf.org/html/rfc6156#section-8.1.
> Okay.
> >
> >> W. Section 14:
> >>
> >> Secondly, I don't know how wise it is to have partial definitions of
> >> what the ECN behavior is. Maybe simpler to say that that the relay is
> >> performing AQM it can support the ECN marking behavior as defined in RFC
> 3168.
> I think the sentence could be formulated so that it is easier to understand that
> the text after "... active queue managmenet, ..." is in case on does AQM. Also I
> think it is worth clarifying that the TURN server can operate as defined by RFC
> 3168. In addition the use of ECT(1) experiments has been changed so that also
> needs a reference. So perhaps:
> 
>       Preferred Behavior: Set the outgoing value to the incoming value. The
> server may perform Active Queue Management, in which case it SHOULD
> behave as a ECN aware router [RFC3168] and can mark traffic with Congestion
> Experienced (CE) instead of dropping the packet. The use of ECT(1) is subject to
> experimental usage [RFC8311].

Looks good, updated draft.

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

> >> 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.
> >> Note, I only want you to clarify what is actually included. I would
> >> assume using the UDP length field makes sense in this case.
> 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. 

> 
> AC. Section 16.12:
> >> Reason Phrase (variable). This field is under defined. First of all
> >> the format of the text string is not defined, which it is in Stunbis
> >> Error-Code attribute is defined as.
> >>
> >> Secondly, I think it might be worth pointing out the padding here. It
> >> is not clear if there is any form of string termination and how the
> >> padding which will be interpreted as NULL characters 0-3 depending on
> >> the alignment. I note this later issue appears to be existing in STUNBis also.
> > Padding is discussed in STUN for variable length attributes, please see
> https://tools.ietf.org/html/draft-ietf-tram-stunbis-18#section-14.
> 
> >> Why isn't the text here say that this attribute may also be used to
> >> indicate the desired lifetime in allocation requests?
> > https://tools.ietf.org/html/rfc5766#section-14.2 did not discuss desired
> lifetime. Anyways, added the following line:
> >> I think it would be good to indicate the use of the attribute in
> >> Allocate Requests also.
> And there the is additional usage of it. When a minor change would indicate
> that alternative use also.
> 
>    application data onward to the peer, and for determining the capability in
> Allocate requests.

Okay, updated.

> >> I notice that this part nor the text before appears to discuss the
> >> permission lifetime that will expire after 5 minutes. Thus, it needs
> >> to be refreshed prior to the Allocation.
> > I have added text to discuss refreshing the channel binding,
> https://tools.ietf.org/html/rfc5766#section-16 did not discuss refreshing the
> permissions and channel bindings.
> Ok.
> >
> >> AH. Section 18.
> >>
> > There was no ask from the WG members to add an example and even
> https://tools.ietf.org/html/rfc6156 did not have an translation example.
> Ok, let skip this for now. But, it will be commented on again most likely by
> other reviewers.
> >
> >> 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.
> 
> >> 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

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.

Cheers,
-Tiru

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Apr 2019 11:37:04 +0000

Hi,

Cutting away what appear settled.

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

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:

address?

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:

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.

Ok.

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

updated the text as follows:

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

A TURN server MUST enable at least one of the transport protocols, UDP, TCP,
TLS- over-TCP or DTLS-over-UDP.

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

M. Section 7.1:

servers.

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

specification.

It is fine to say no.

Okay, then lets drop this point.

O. Section 7.1:

families.

Yes.

Thus, shouldn't a

Okay, then I think this issue can be closed.

Q. Section 8.3:

Good works for me.

R. Section 11.5:

Thanks, that clarification. Issue resolved.

U. Section 13. 1,2,3:

or

Thanks, that clarifies that aspect.

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

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

X. Section 14:

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

indicates ?

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

tsvwg-udp-options.

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

If (D)TLS transport is

   If (D)TLS transport is

Looks good to me.

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sun, 28 Apr 2019 09:46:27 +0000

Hi Magnus,

Please see inline [TR]

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

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

Othewise fine with me.

H. Section 5:

address?

choose the realm.

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

L. Section 7.1:

   discussion.

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.

Ok.

rewrite it to say:

M. Section 7.1:

servers.

specification.

It is fine to say no.

O. Section 7.1:

families.

Yes.

Thus, shouldn't a

Q. Section 8.3:

   succeeded.

Good works for me.

R. Section 11.5:

   dropped.

Problem are for ICMPv4?

U. Section 13. 1,2,3:

or

translation

addressed:

fragmentation.

X. Section 14:

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

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

[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:

[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:

[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:

 [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

      options.

 [TR] I will add IPv4 options.

IPv6 Extensions Headers:

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

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

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

[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:

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

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

Y. Section 16.4.  DATA

indicates ?

tsvwg-udp-options.

                             IP transport payload

                           UDP Length

[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

If (D)TLS transport is

   If (D)TLS transport is

Looks good to me.

Cheers

Magnus Westerlund