Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Feb 2009 22:49:52 -0500

On Mon, 19-Jan-09, at 07:36 , Magnus Westerlund wrote:

> Hi,
>
> Here is my IETF last call comments.
>
> 1. Section 2.6:
>
> "   o  Path MTU Discovery does not work, except in the limited way
>      available using the DONT-FRAGMENT attribute (see below); and"
>
> I think it would be more correct to say: "ICMP based Path MTU DIsovery
> does not ..."

I think the non-ICMP version also needs some modification.
In the client-->peer direction, the client can ensure that the DF bit  
is set for the entire path by set the DF bit on the Send indication  
packet and including the DONT-FRAGMENT attribute.
However, in the peer-->client direction, the peer can set the DF bit  
in the UDP datagram, but there is no way for it to ask the server to  
set the DF bit on the Data indication packet.

That's why I worded the sentence the way it is.

>
>
> 2. Section 9.1 and 9.2:
>
> These two sections doesn't as clearly as the other request chapters
> discuss the issue of authentication of the request. I think that
> CreatePermission is equally important to protect to the other  
> management
> requests.

I have added the sentence:
    If the server is using the Long-Term Credential mechanism, the  
message is authenticated.
in section 9.2.
(Note that authentication for all requests is already covered in  
section 4, so we are just repeating ourselves here).

>
>
> 3. Section 11.2:
>
> "   The server MAY also impose restrictions on the range of IP  
> addresses
>   and ports allowed in the XOR-PEER-ADDRESS attribute."
>
> How does one learn that this is happening from the response? Shouldn't
> there be an error code for "Administratively Prohibited" that is
> indicated to be return in this case?

Good point. I previously felt that a 400 (Bad Request) response would  
be ok, but after further reflection I decided that a different error  
code would be better. So I have added a 403 (Forbidden) error code.

>
>
> 4. Regarding the Fragmentation Question.
>
> I have raised this before and we didn't come to a conclusion. Below  
> are
> a text proposal for including the thing I think is missing in the
> preferred behavior. I know this clearly requires OS level  
> implementation
> but that is why there is alternative behavior and this only  
> specified at
> should level. I do hope that we get some feedback on this proposal. I
> personally think it is important to indicate how it should be properly
> done, even if a number of implementation will not do it.
>
> My proposed text for the IPv4 Fragementation field:
>
> 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, MF,
>         Fragment Offset) as appropriate for a packet originating from
>         the server.
>
> For a packet that had the DF bit set on reception by the server, or  
> was
> delivered to the server with a Send Indication including a DONT- 
> FRAGMENT
> attribute and which require fragmentation when being sent from the
> server should result in a ICMP message (Type=3, Code=4 (Fragmentation
> needed and DF set)) towards the sender of the packet.
>
>      Alternate Behavior: As described in the Preferred Behavior,  
> except
>      always assume the incoming DF bit is 0 and that no ICMP messages
> needs to be sent.
>
>      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].

See my separate e-mail on this subject.

>
>
> NITS:
>
> Section 2.6: Missing space:
>   "still require this,TURN allows the client to request that the  
> server"

Fixed.

>
>
> Section 5: Extra space before "."
> The username, realm, and nonce
>   values are initially those used in the authenticated Allocate  
> request
>   that creates the allocation, though the server can change the nonce
>   value during the lifetime of the allocation using a 438 (Stale  
> Nonce)
>   reply .
>
Fixed.

>
> -- 
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
>
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 5 Feb 2009 18:16:34 -0600

Sinji:

Thanks for your comment. This is now fixed.

- Philip

On Tue, 20-Jan-09, at 01:16 , OKUMURA Shinji wrote:

> Hi.
>
> I have one comment.
>
> Page 51
> "alerted or forged", it would be "altered or forged".
>
> Regards,
> Shinji
>