Subject: [BEHAVE] Comments and nits on rfc3489bis-05

From: Hisham Khartabil <[email-masked]>
Date: Fri, 1 Dec 2006 14:36:47 +0100

Apologies if there comments or nits already addressed.

General
--------
- Should TLS over TCP be TCP over TLS (there is also TLS-over-TCP)?

Section 2
----------
- ALGs have serious limitations. The security drawback is not 
mentioned. It might be worthwhile mentioning that integrity and 
confidentiality is compromised because any signed or encrypted parts of 
the application protocol message would cause failure

Section 4
---------
- Add definition for STUN Indication
- Add definition for short term credentials

Section 5
-----------
- para 3: I think more text is needed explaining the purpose of the 
Indication transaction. Text needs to talk about why Indication 
transaction is defined in this document when there are no Indications 
defined.
- para 12 and 15 (2nd last para) talk about repeats info about some 
stun usages require stun messages to be sent on the same transport 
address as the application protocol. That fine, but its kind of 
confusing since para 15 sounds like its talking about something new. 
Perhaps para 15 should say "... as mentioned above..."

Section 6
---------
- "Indication messages can be sent over TCP or UDP" Why not TCP over 
TLS?
- Fig 3: there are two M 2s :)
- There are 2 bits for class. This makes the limitation of 4 classes. 
Are we ok with that? Will there ever be more than 4 classes? I think 
there might be.
- s/ 1.As / 1. As (space missing)
- "For request/response transactions, the transaction ID is chosen by 
the STUN client and MUST be unique for each new STUN transaction 
generated by that STUN client... ... As with requests, the value is 
chosen by the server and MUST be unique for each new STUN transaction 
generated by the server". There is a discrepancy here in who generates 
the transaction ID. Also, transaction IDs can be created by servers, if 
the server initiates it.

Section 7.1
------------
- Expand RTO
- 100ms for initial RTO sounds a little high. Thats 5 pending STUN 
requests. maybe 80ms? or just explain why that number was chosen.
- Karn's algorithm needs a reference
- RTO cache of 10 mins requires explanation. Seems too short for me. My 
gut feeling tells me 1 hour is good enough.
- fatal ICMP errors to TCP are not mentioned

Section 8.3.1
-------------
- This section talks only about formulating the request message in the 
request/response transaction, but in point 2 of the text, STUN 
indications are mentioned. This reference to STUN indication should be 
removed and text should be repeated in the appropriate section for 
Indications.
-
"   For TCP and TLS over TCP, the client MAY send multiple requests on
    the connection.  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.
"
should that last word here be "STUN requests or application protocol 
messages"? The client might want keep the connection open to send 
application protocol messages. Same for indications.

Section 8.3.2
-------------
- There are a lot of "the request SHOULD NOT be retried" or "the client 
SHOULD NOT retry the request". Ok, but what should the client do in 
those cases? try the next SRV record? or what?
- "However, the if the retries are repeatedly rejected with 436". How 
many rejected are considered a repeated rejections so the client can 
cease retrying?
- "For error responses which can" -> "For error response that can"
- "Furthermore, the client SHOULD cache the nonce, and continue
    using it in subsequent requests sent to the same server, identified
    by transport address.
"

Should you add that the client SHOULD cache the nonce if the 
authentication was successful.

- The above quoted text is repeated in the last paragraph of this 
section

Section 8.4
-----------
- section 8 is for client behaviour, but 8.4 talks about Indication 
transactions that apply for both client and server behaviour. Perhaps 
this section needs to be referenced from section 9.2.
- The section does not talk about what a client does if it receives an 
Indication transaction. Should it ever receive those kinds of 
transactions? If no, then this should be mentioned earlier in the 
draft, but still explain how the client should behave.

Section 9.1.1
-------------
- The server should remember responses it sent for 10 seconds, but the 
client is only waiting for 7.9 seconds. What's the logic here?

Section 9.1.2
-------------
-
"If the response is a type which can carry either MAPPED-ADDRESS or
    XOR-MAPPED-ADDRESS (the Binding Response as defined in this
    specification meets that criteria), the server examines the magic
    cookie in the STUN header.
"

what header? I assume the STUN request header. Right?

Section 9.2
-----------
- Section does not mention sending indications by the server. Can it 
reference section 8.4? (at least section 4 days servers can send 
indications).
- Text as to why a server would send indications would be good.

Section 11.6
------------
- what are those 0's there for?

Section 11.7
-------------
- Why including the quotes?

Section 11.9
------------
- Why repeat an attribute for odd number of attributes instead of 
putting 0's or some sort of padding?

Section 11.12
--------------
- Does encoding same way as MAPPED-ADDRESS mean that ALTERNATE-ADDRESS 
has a family, port and IP address? what if it was a FQDN?

Section 12.1.1
--------------
- s/ an an / an (an repeated)

Section 12.1.7
---------------
- "... is then using in..." -> "... is then used in..."
- last para: might be a stupid question, but how does the client know 
if the response contains XORed address or not?

Section 12.2.3
---------------
- "it is has" -> "it has"?

Section 12.2.8
--------------
- how does the server know if it is getting a Binding request or a 
keepalive request? The text indicates that the latter does not need 
message integrity.

Section 12.2.9
--------------
- Isn't there a DoS vulnerability. For SIP, the IP address and port in 
the stun response might end up in the contact of a REGISTER.

Section 12.3.1
---------------
- 9 mins. Should it say at least 9 mins but no longer than 30?

Section 12.3.4
-------------
- all other figures have a caption and number, except the figure in 
this section

Section 12.3.7
-------------
- No mention of how long credentials are valid for. Server can have 
them valid for 9 to 30 mins. How would the client know that?

Thanks,
Hisham

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