Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04

I have reviewed this doc and have a number of comments.
A marked-up PDF with my full comments is at
http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-behave-turn-tcp-04.pdf

Summary of non-editorial-only comments:

1) Are data connections to be closed gracefully or abortively,
   and does this depend on how the corresponding (peer vs client)
   connection was closed?

2) When error 447 is returned, section 4.3 says the client MUST
   wait at least 10 seconds before retrying.  I think this is
   for the _same_ destination IP/port, right?  If the client
   has other destination IP/port pairs to try, they can be
   tried immediately, correct?

3) Section 4.6 notes that no keepalive mechanism is provided
   and an application can do this at a higher layer.  For
   NATs between a TURN client and a TURN server, why wouldn't
   TCP keepalives be a possibility?

4) If I understand the 3rd paragraph of section 5.2, correctly,
   there's an important limitation/constraint that should be
   called out early (e.g. in the overview).  Normally, TCP
   clients can open multiple parallel connections (e.g., to
   a web server) to the same destination address/port.  To
   accomplish this with TURN, it seems that the client needs
   multiple control connections so it can get multiple
   allocations, since it can only have one connection to a
   given peer address/port per allocation, correct?

5) The 5th paragraph of Section 5.2 also implies that it's
   illegal for a TURN server to refuse to initiate connections
   based on the XOR-PEER-ADDRESS value.  For example, if it
   refuses to initiate connections to 127.0.0.1 it would be
   violating a MUST.  I'd like to see this relaxed.

6) The draft talks about timing out a peer connection after
   30 seconds in section 5.3 if the client never does a
   ConnectionBind for a connection initiated by a peer.
   However, section 5.2 has no corresponding rule.  This
   means a client can send a Connect request, and then
   never open a data connection, and the server will never
   time out the peer connection.  The same rule needs to be
   added to 5.2 to address this.

7) Continuing on the same point, the security considerations
   section needs to add a discussion of a memory DoS attack
   due to the TURN server having to buffer data from a peer
   while waiting for a ConnectionBind (which may never happen).
   Currently it has references to docs that contain
   discussion of bandwidth DoS attacks, but not memory
   DoS attacks, as far as I can find.

-Dave

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Dan Wing
> Sent: Thursday, July 30, 2009 1:49 AM
> To: behave@ietf.org
> Cc: draft-ietf-behave-turn-tcp@tools.ietf.org; 'Behave Chairs'
> Subject: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04
>
> BEHAVE is starting a 3 week working group last call (WGLC), ending
> August 19,
> for
>
>   draft-ietf-behave-turn-tcp-04
>   "Traversal Using Relays around NAT (TURN) Extensions for TCP
> Allocations"
>
> Please send technical comments to the BEHAVE list, and editorial
> comments to
> the authors.
>
> Thanks,
> -d
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave