Subject: [BEHAVE] draft-ietf-behave-rfc3489bis-05 review comments (apologize for the delay)

From: "Mayank Dev Sondhi" <[email-masked]>
Date: Mon, 4 Dec 2006 12:18:01 +0530

Hi everyone,
       I guess I may be a little late with this, Here are some of the
comments on the draft from my side:

---------------------------------------------------------------------------------------------------------------------------------------------------------

*Section 1: Applicability statement:*

*Statement: "It will allow incoming UDP packets through NAT, but only
through a subset of existing NAT types."*

Comment: STUN does not allow by itself incoming UDP packets. Is this not a
property of the NAT?

*Statement: "Furthermore, the binding usage, when used by itself, does not
work when a client is communicating with a peer which happens to be behind
the same NAT."*

Comment: There are specific NATs that seem to have this loopback
characteristic. "Does Not" could be reworded to "May Not"

*Section 5:*

General Comment: The client server paradigm as outlined in the diagram,
could be 2 peers as well. In that case should the word "server" be outlined
in more detail as to what it means?

*Statement: "Shared secret requests are sent over TLS(5) over TCP"*

Comment: I believe this restriction on TLS over TCP should be relaxed a
little? TLS over UDP as in DTLS(rfc4347) though still in infancy is a
potential means as well. Also over mobile networks UDP has significant
performance gains over TCP and UDP gains more importance in such scenarios.

*Statement: "In the binding keepalive usage, a client sends an application
   protocol message (such as a SIP REGISTER message) to a server.  The
   server notes the source transport address of the request, and
   remembers it.  Later on, if it needs to reach the client, it sends a
   message to that transport address.  However, this message will only
   be received by the client if the binding in the NAT is still alive.
   Since bindings allocated by NAT expire unless refreshed, the client
   must generate keepalive messages toward the server to refresh the
   binding.  Rather than use expensive application layer messages, a
   STUN binding request is sent by the client to the server, and is sent
   to the exact same transport address used by the server for the
   application protocol.  In the case of SIP, this would typically mean
   port 5060 or 5061.  This has the effect of keeping the bindings in
   the NAT alive.  The STUN binding responses also inform the client
   that the server is still responsive, and also inform the client if
   its transport address towards the server have changed (its reflexive
   transport address), in which case it may need application layer
   protocol messaging to update its transport address as seen by the
   server.  The binding keepalive usage is used by the SIP outbound
   mechanism, for example [18]. "*

Comment: One should note here that this would be gauranteed to work in case
STUN functionality is in built in the SIP server(I assume the server
referred to in the first line is a SIP server).
If the 2 servers are different then certain NATs could cause problems in the
above scenario.

*Section 6:*

*Statement: "The transaction ID MUST be uniformly and randomly
   distributed between 0 and 2**96 - 1"*

Comment: Is 0 a special case scenario?

*Statement: "A reponse to the STUN request"*

Comment: typo, should be response.

*Section 7.1:*

*Statement: "If the client has not received a response after 7900ms, it
   considers the transaction to have timed out. "*

Comment: Why this value, 7900ms? Is this done for consistency with UDP? As
most TCP stacks have their own timeout right?

*Section 7.2:*

*Statement: "Indications are sent from the client to the server, or from the
   server to the client" *

Comment: Indications as mentioned here, although specified only for the
Relays, seem to convey the message that they are unidirectional. With UDP
NATs an inherent problem could be the closing of bindings and/or improper
usage of bindings.
For example say request X is made, indication A is sent by the server and
then response Y is sent by the server. Since ingress/egress semantics could
be used by the NAT, the indication A may be taken as a response to X by the
NAT and the binding could be closed BEFORE response Y is sent. Even with
Keepalives this can still happen, can this point be elaborated further here?

*Section 8.3.2:*

*Statement: "If the client receives a 401 (Unauthorized) response and had
not
   included a MESSAGE-INTEGRITY attribute in the request, it is an
   indication  from the server that credentials are required"*

Comment: Possible rewording as indications in STUN are used as something
different. Signal seems like a better word instead of indication

---------------------------------------------------------------------------------------------------------------------------------------------------------

My review has not been fully complete, and I apologize in advance if some of
these comments have already been covered.

Thanks

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