Subject: [BEHAVE] Comments on draft-ietf-behave-3489bis-05

From: Philip Matthews <[email-masked]>
Date: Mon, 27 Nov 2006 09:25:26 -0500

Jonathan:

Here are some comments on draft-ietf-behave-3489bis-05.

Overall, I found this to be a very clear and well-written document.
With a few exceptions (as noted below), I found everything to be
very understandable.

Below are a few comments that might be of general interest
to the working group. These are a bit more  significant that the
more minor and editorial comments which I have placed in
a separate e-mail. None of my comments, however,
are particularly earth-shattering -- a reflection probably of how
well-written and mature the document is.

- Philip

1)   Much of the document is written with the viewpoint that one  
endpoint
      is always the client and sends requests and indications, and  
the other
      endpoint is always the server and sends responses; furthermore,  
the
      client is behind a NAT while the server typically is not (cf.  
figure 2).
      However, it seems to me that the real protocol has evolved  
beyond this view.
      Both ends can now send and receive requests and indications
      (e.g., ICE with the keepalive usage and connectivity-check usage,
      and TURN with the relay usage),
      and both ends can be behind NATs (ICE again).
      So perhaps the document should either:
      a) Drop the terms "client" and "server" and just talk about  
"endpoints", OR
      b) Use the terms "client" and "server" only with respect to a
         particular transaction.
      If (b) is selected, then I suggest being careful to distinguish  
this usage
      from the concept of "using DNS to find a STUN server".

2)   Much of sections 8 "Client Behavior" and 9 "Server Behavior"  
deals with authentication.
      There is very little discussion of the basic processing of a  
received STUN message,
      and what little there is is scattered throughout the document.  
In particular,
      there is very little discussion about checking the message  
type, checking the magic cookie,
      the proper processing of transaction IDs, checking for  
mandatory-to-include attributes
      (other than those associated with authentication, which is well  
covered!),
      and how to handle situations like repeated attributes.

3)   The document is split into client behavior in section 8 and server
      behavior in section 9. However, given that at least two usages
      require an endpoint to both send and receive requests and  
indications,
      I suggest that a better organization might be:
      a) Sending a request
      b) Sending an indication
      c) Receiving a message which, after some common initial  
processing, leads to:
           i) Receiving a request and sending a response
          ii) Receiving a response
         iii) Receiving an indication
      d) Locating a STUN endpoint using DNS
      This organization is much closer to the way an implementation  
of STUN
      needs to be organized these days. It would also provide a  
logical spot to discuss
      all the points mentioned in (2).

4)  Given the recent discussion on the mailing list, I suggest it  
would be especially good
      if the document said a bit more about choosing transaction ids,  
and when they are
      required to be unique.
      For example, what determines a unique transaction: can one  
simultaneously send
      a binding request to two different servers using the same  
transaction id?
      (I think not, but the text is not clear).

6)  It seems to me that the figure 5, which shows which attributes  
appear in which message types,
      really needs to depend on the usage. Perhaps  there should be a  
separate table for each usage?
      For example, for the connectivity-check usage, the
      ALTERNATE-SERVER attribute makes no sense, and Binding Requests  
must contain the
      PRIORITY attribute (as described in ICE).

7)   It might be helpful if the document was a bit clearer on the  
distinction in usage for "mandatory"
      and "optional" when discussing "mandatory/optional-to- 
comprehend-when-received" vs. discussing
      "mandatory/optional-to-include-when-sending".
      For example, MESSAGE-INTEGRITY is always "mandatory-to- 
comprehend-when-received", but is
      "optional-to-include-when-sending" in some usages.

8)   As currently written, the document seems to suggest that the  
backwards compatibility rules apply
       to all usages; specifically the rules for including the MAPPED- 
ADDRESS attribute. However, I believe
       these rules only make sense for the binding-discovery usage.
       Perhaps a better organization would be to move all the  
backward compatibility discussion out of the
       main text and place it under the usage where it applies?

9)   I think it would be helpful if the introduction provided a high- 
level description of the various authentication
       schemes and how they work. Not being familiar with these  
schemes, I found the details in later sections
       very confusing, especially wrt. long-term authentication.

10) In section 5 and section 12.2, the document assumes that in the  
NAT keepalive usage,
        the "server" learns a transport address of a "client" from  
the source transport address
        of a application protocol message sent by the "client".  This  
is one way
        to do it, but ICE (for example) uses a different scheme.  
Suggest generalizing the discussion.

11) "The value for RTO SHOULD be cached by an agent after the completion
          of the transaction, and used as the starting value for RTO  
for the
          next transaction to the same host (based on equality of IP  
address)."
     Could this give a problem with ICE? For example, say X and Y are  
endpoints that both
    use the same (large) service provider, and that service provider  
has a NAT N in front of
    its entire network. Then X and Y may appear to have the same IP  
address to remote endpoint Z.
    Say Z first calls X and say some of the links between X and N are  
slow. Then Z will learn and
    remember a large RTO to N's address. Shortly afterwards, Z calls  
Y. Z will now use the large RTO,
    and this may have an affect on the set-up time for this second call.
    Could say that we don't care about this case. Alternatively,  
could say that Z remembers the RTO
    or a transport address, not just an IP address.

12) What are the retransmission timers for TCP and how do they  
compare with those
        STUN uses for UDP?  Am I correct in saying that the STUN UDP  
retransmissions intervals are
        shorter than those that TCP uses?

13) Are we going to get push-back from the security folk because we  
are specifying MD5 for authentication?
        I have heard that the security folk want the IETF to  
transition away from MD5 to more secure algorithms,
        due to recent cryptographic attacks on MD5.

14) The document states that usage of the FINGERPRINT attribute is  
RECOMMENDED even
        when the initial two zero bits and the magic cookie are  
sufficient for demultiplexing.
        Why is it RECOMMENDED? Why not just make this a MAY?  (This  
is repeated in various sections)

15)    "When using TCP or TLS over TCP, the client SHOULD
             close the connection as soon as it has received the STUN  
Response, if
            it has no plans to send further requests."
        As discussed on a different thread, I think the client   
should keep this connection open until
        it has set up at least one other TCP connection that uses  
this mapping. Otherwise, the mapping
        might be discarded immediately by the NAT.  (Section 8.3.1  
and 8.4)

16)   In section 8.3.2 Processing Responses, it says
              "Once the client has received a response to its request  
that it did
               not discard, it MUST discard any further responses for  
the same request."
          This could be read to imply that a client must remember all  
the transaction ids it has ever used
          so that it can discard duplicate responses. Is this really  
what is meant?

17)   Section 8.3.2. says
               "For a 420 (Unknown Attribute) response code, the client
                SHOULD retry the request, this time omitting any  
attributes listed in
                the UNKNOWN-ATTRIBUTES attribute of the response."
          and a bit later says
               "If the client receives a 432 (Missing Username)  
response, and the
               client had omitted the USERNAME from the request but  
included a
               MESSAGE-INTEGRITY, the client SHOULD retry the request  
and include
               both MESSAGE-INTEGRITY and USERNAME."
          and later says
              "If the client receives a 433 (Use TLS) response, and  
the request was
               a Shared Secret request which was not sent over TLS,  
the client
               SHOULD retry the request, and MUST send it using TLS."
          How can any of these situations occur with properly  
functioning clients and servers?
          The actions that lead to these errors all seem to violate  
this specification.

18) Section 8.3.2 also says:
            "If the response is an Error Response, the client checks  
the response
             code from the ERROR-CODE attribute of the response.  For  
a 400 (Bad
             Request) response code, the client SHOULD display the  
reason phrase
             to the user.
        Why is this a "SHOULD"? Though it may be good  advice, it  
don't see how
         it is needed for interoperability.

19)  Section 8.4 says
              "Indication messages cannot be challenged or rejected.   
Consequently,
                they cannot be authenticated using long term  
credentials."
        I don’t understand this. If a client knows the USERNAME,  
REALM, and password,
       why can’t the long term credentials be used? (I suspect that I  
don't understand
       how long-term credentials work).

20)  Section 9.1.1 says
             "Any attributes that are known, but are not supposed
              to be present in a message (MAPPED-ADDRESS in a  
request, for example)
              MUST be ignored."
     This is interesting. Unknown mandatory  attributes cause an  
error, but known
     but unexpected attributes are ignored. Shouldn't it be that  
mandatory attributes must
     be expected, but optional attributes can be unexpected?

21)  Section 9.1.2 says
          "Insertion of
           either XOR-MAPPED-ADDRESS or MAPPED-ADDRESS happens  
regardless of the
           transport protocol used for the request."
       Why??     3489 only ran over UDP.

22)  UNKNOWN-ATTRIBUTES is the only attribute that doesn't use  
padding, but rather says
       to repeat an attribute to pad to a 32 bit boundary. Could we  
change this to be consistent?
       (Bruce Lowecamp already mentioned this, so I am seconding his  
request).
       I don't think there are any backward compatibility concerns  
with this,
       since properly implemented 3489 clients should never receive  
this attribute,
       since a 3489bis server will always recognize all the  
attributes they include.

23)  As much as I like the proposal in draft-wing-behave-nat-control- 
stun-usage,
         I'd like to suggest that the REFRESH-INTERVAL attribute NOT  
be defined in this document,
         but  be defined in draft-wing-....  There is no real  
motivation in 3489bis
         for why this attribute exists, and I am concerned that  
people will read this document and either
         be very confused or use this attribute in unexpected ways.

24) The section on the Binding Discovery usage says that the lookup  
of the STUN server
        should be done using the DNS lookup procedure. This is  
certainly one way to find a server,
        but I can think of others. Do you consider the DNS lookup  
procedure to be an integral part
        of this usage, or is it still the Binding Discovery usage  if  
I use a different method to find the
        STUN server?  (For example, a P2PSIP lookup mechanism that  
finds peers willing to act
        as STUN servers).
        My suggestion is to remove the finding of the server from the  
usage, and simply say that
        DNS lookup is one way to find a server.

25) Should we make provisions for private and experimental extensions  
to STUN, as is often
        done with other protocols? This seems to be especially  
important to do for attributes,
        since inventing new attributes seems to be fairly common.
        One possibility, based on what I have seen done for other  
IETF protocols, is to allocate
        say 0x7fc0 – 0x7fff for private mandatory attributes and  
0xffc0 – 0xffff for private optional attributes.
        This reserves 64 attributes for private use. To prevent  
possible collisions, the first three bytes
        of an attribute in these ranges MUST contain an OUI.
        For messages, state that message type of the form  
0b1111c11xcxxxx,  where “x” is 0 or 1,
        and “c” is a class bit, are a private messages. Again, to   
prevent  collision, define a new attribute
        that holds an OUI, and state that this MUST be the first  
attribute of a message whose type is in
        this range. This reserves 32 messages of each class for  
private use.

26) Perhaps state that message type 0x000 and attribute type 0x0000
        are reserved for an extension mechanism if ever required?

27) Section 16 states that this specification "updates" 3489.
        But don't we want this specification to "replace" or  
"obsolete" 3489?
        "Updates" implies that someone needs to read both  
specifications to implement the protocol.
        Is there something in 3489 that an an implementor still needs  
to know?
        Can we not add a few extra sentences to make this document a  
complete specification?

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