Subject: [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: The IESG <[email-masked]>
Date: Tue, 13 Jan 2009 07:52:37 -0800 (PST)

The IESG has received a request from the Behavior Engineering for 
Hindrance Avoidance WG (behave) to consider the following document:

- 'Traversal Using Relays around NAT (TURN): Relay Extensions to 
   Session Traversal Utilities for NAT (STUN) '
   <draft-ietf-behave-turn-12.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-01-27. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-12.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14443&rfc_flag=0

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Scott Godin <[email-masked]>
Date: Tue, 13 Jan 2009 11:31:31 -0500

FYI - I've submitted the following comments last week sometime, but I
think they may be held up in the moderator queue:

I'm in the process updating reTurn (opensource Turn server in
resiprocate project) to the latest turn-12, and have the following
comments/typos after reviewing the draft.

1.  section 1, 4th paragraph, "When the client send...." - should be
"...sends..."

2.  section 2.1, last paragraph, ".., the client may send and received
packets..." - should be "...receive..."

3.  section 2.6, list "The ECN field is may be reset..." - remove "is"

4.  section 5, 3rd last paragraph indicates that username, password,
realm and nonce are used to verify subsequent requests - but according
to section 4 paragraph 6 the only information authentication
information used to verify subsequent requests is the username.  I
think one of these sections needs to be re-worded to avoid confusion.
Perhaps section 4 should indicate that username, realm and password
should be stored and verified across all requests for an allocation -
this will cover cases where the same username exists in two different
realms.  However note that if password hash is stored instead of the
plain password, then we don't really need to store and compare realm,
since it is hashed into the password.

5.  section 6.2 - step 5 "... request contains a EVEN-PORT
attribute..." - should be "...contains an EVEN-PORT attribute..."

6.  section 7.2 - first step indicates that "the additional username
check of section 4" should be complete.  This comment needs to be
brought inline with the wording decided for comment 4.

7.  section 9, 2nd paragraph - missing space "... inSection..."

8.  section 9.2 is missing the steps/checks to process similar to
Allocate and Refresh requests - it would be good to add these for
consistency.  It should also include: Long Term Cred check, existing
allocation check,  and the required auth (username, etc.) checks.

9.  section 10, 1st paragraph - "...for sending and receive data
from..." - should read "...for sending and receiving data..."

10.  section 10.2 - should include a step to ensure that an allocation
exists for the 5-tuple, else message is dropped

11.  section 10.2, 4th paragraph, last sentence - "...the server MUST
NOT refresh the permission due to the receipt of the Send
indication..." - should be removed since Send Indication never refresh
permissions now

12.  section 10 indicates that Data attribute is mandatory in a Send
Indication - should we allow no data attribute to indicate that a 0
length UDP packet?  Note the ChannelBinding section discusses sending
a 0 length packet (section 11.6 last paragraph).  Perhaps this could
also be accomplished using a Data attribute containing a data length
of 0 - but I think there should be some mention of this in section 10.

13. section 11, paragraph 5 - "...or may choose never to bind a
channel it." - should be "...channel to it."

14. section 11.2 - check list should be numeric to be consistent with
Allocate and Refresh requests.  Should also contain Long Term Cred
check, existing allocation check,  and the required auth (username,
etc.) checks

15. section 11.5 - I'm not sure I understand the need to pad the
ChannelData message to a multiple of four bytes.  TCP implementations
are capable of reading in the exact right number of bytes from the
stream.  Can this requirement be removed?

16.  Is there are reason we don't just make the default permission and
channel binding lifetime the same, to facilitate use of the
ChannelBind refresh to accomplish both refreshes without worrying
about the difference?

My apologies if my questions/suggestions have already been discussed.

Thanks,
Scott Godin

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Jan 2009 13:36:04 +0100

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

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.

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?

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

NITS:

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

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 .

-- 

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: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 19 Jan 2009 14:49:45 +0200

> done, even if a number of implementation will not do it.

Side note:

It does require OS-specific support. As far as this is UDP-only TURN, I 
believe it could be done in (unprivileged) userland with very limited changes 
to the IP stack. We just an option to pass DF via ancilliary data. This would 
very similar to what IETF/POSIX have defined for TTL and DSCP in the 
*Advanced* IPv6 socket API.

On Linux, you can already set the DF bit (per UDP socket). However, at the 
time of writing this email, you cannot "get" it from incoming packet.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 20 Jan 2009 16:16:32 +0900

Hi.

I have one comment.

Page 51
"alerted or forged", it would be "altered or forged".

Regards,
Shinji

The IESG <[email-masked]>