Subject: [BEHAVE] STUN comments part 2

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 6 Dec 2006 16:44:52 -0800

Hi,

Below are the rest of my STUN comments.

thanks,
-rohan

STUN comments part 2

Substantive Comments

6) Sect 9.1.1 paras 8 and 12.  Is a NONCE attribute required in a 438
response?  The spec should say explicitly either way.

7a) We never actually define the semantics of the requests. I think we
should insert a short section that defines the two methods and says
which method-specific attributes MUST and MUST NOT be in these
requests and responses. I consider MAPPED-ADDRESS, XOR-MAPPED-ADDRESS,
REFRESH-INTERVAL, and PASSWORD to be method-specific.  This doesn't
mean I can't use them in a new method, but just that they don't have
meaning automatically for all methods.

7b) I'd like to completely delete Figure 5 and the paragraph
immediately prior, and the 2nd para of 12.3.4 and its table.  We
always get these kind of tables wrong and many implementors hate
reading them.  The implementors that do implement to the table tend to
blindly implement our mistakes without considering context.  I think
this has been a disaster in the SIP spec and I do not want to repeat
that train wreck.

8) In Section 11, I think it would be useful to put the attribute
number in each subsection of 11.  Also, I propose putting
XOR-MAPPED-ADDRESS immediately after MAPPED-ADDRESS for improved flow.

9) Sect 11.1  para 5 and para 6.  Why are we still using X-Port?  No
known generic NAT rewrites bare port numbers. This serves no purpose.

NITS

Sect 8.3.2 paras 1 and 2 - reword
PROPOSED:
When the client receives a response, first the client verifies that
the transaction ID of the response matches a request sent by the
client. If the client cannot find a matching request, it discards the
response. Next the client checks if it already accepted a response for
the corresponding request.  Once the client has accepted a response to
a request, the client ignores any additional responses to that
request. This allows the client to discard retransmissions of
responses and other spurious responses.
<new para>
At this point the client SHOULD check the response for a
MESSAGE-INTEGRITY attribute.  etc...

 para 3 (just append this sentence to the previous para)

 para 5
s/and had not included a MESSAGE-INTEGRITY attribute in the request,
it is an indication from the server that credentials are required.
/and did not include a MESSAGE-INTEGRITY attribute in the request, the
server is indicating that credentials are required./

 para 7
s/had omitted/omitted/

 para 9
s/DNS procedures defined above/DNS discovery procedures defined in
Section 12.3.2/

 para 10
PROPOSED
For a 431 (Integrity Check Failure) response code, the client SHOULD
alert the user.  If a short term credential obtained from a Shared
Secret request was used previously, the client MAY obtain a new short
term username and password and retry the request again.

 para 12
s/REALMS were equal/REALM attributes are the same/

 para 14
PROPOSED
If an authentication-related error response contains a NONCE attribute
and the client retries the corresponding request, the client MUST
include the NONCE in the resulting subsequent request. Furthermore the
client SHOULD cache the NONCE, and continue using that nonce in
subsequent request to the same server (as identified by its transport
address).

Sect 8.4 para 5 (begins "Typically, indication messages...")
Delete the second sentence. We have no usage for the DNS discovery for
standalone indications. If we need this type of new behavior we can
introduce it in a new usage.

Sect 9
As with clients, server behavior depends on whether the server
receives a request or an indication.

Sect 9.1.1 para 2
s/If the request/If a received request/

 para 3
s/the server determines/the server optionally determines/

 para 8
OLD:
If the REALM attribute was present and the server is using a long
   term credential for authentication, the server checks for the
   existence of the NONCE attribute.  If the NONCE attribute is not
   present, the server MUST generate an error response.  That error
   response MUST include an ERROR-CODE attribute with a response code of
   435 (Missing Nonce).  That error response MUST include a REALM
   attribute.  If the NONCE was absent and the server is authenticating
   with short term credentials, the server MAY generate an error
   response with an ERROR-CODE attribute with a response code of 435
   (Missing Nonce).  This response MUST include a NONCE.  If the NONCE
   was present in the request, but the server has determined it is
   stale, the server MUST generate an error response with an ERROR-CODE
   attribute with a response code of 438 (Stale Nonce).
PROPOSED:
If the REALM attribute was present and the server is using a long
   term credential for authentication, the server checks for the
   existence of the NONCE attribute.  If the NONCE attribute is not
   present, the server MUST generate an error response.  That error
   response MUST include an ERROR-CODE attribute with a response code of
   435 (Missing Nonce).  That error response MUST include a REALM
   attribute.  This response MUST include a NONCE.
<new para>
If the NONCE was absent and the server is authenticating
   with short term credentials, the server MAY generate an error
   response with an ERROR-CODE attribute with a response code of 435
   (Missing Nonce).  This response MUST include a NONCE.
<new para>
If a NONCE attribute
   was present in the request, but the server has determined it is
   stale, the server MUST generate an error response with an ERROR-CODE
   attribute with a response code of 438 (Stale Nonce). This can apply
to authentication with either short-term or long-term credentials.

 para 11
s/from the one from the/from the HMAC in the/

Sect 9.1.2 para 3 and 4, move these to the Binding Discovery usage.
(The Keepalive usage will always use XOR-MAPPED-ADDRESS and the magic
cookie.)

Sect 9.1.3
s/TCP connections that the request arrived on/TCP connections over
which the corresponding request arrived/

Sect 9.2 1st para
1st sentence.  Indication messages don't necessarily change the state
of the server.  Certainly this is the case with TURN Data and Send
indications.   I propose just delete this sentence.

Sect 10, 1st para
s/In the binding refresh usage/In the Keepalive usage/

Sect 11.5
s/xor-d/XORed/

Sect 11.8
Append "Quotes are not included in the NONCE Value."

Sect 11.1 para 2 - replace 1st sentence with:
This attribute MUST always be present in a Binding Response
if the Binding Request contained the STUN magic cookie.  This
attribute can be used in other responses as well as specified in the
method definition.

Sect 11.13 1st para
s/provies/provides/

Sect 12 para 3
s/standards-track/IETF Consensus/

Sect 12.1
This sentence is completely wrong, and completely unhelpful. RFC 3489
also described the Shared Secret usage. Delete the entire sentence.

Sect 12.1.1 para 4
s/protocol data unit/application payload/

 para 5
s/Real Time Control Protocol/Real-time Transport Control Protocol/

 para 6
s/in the PDU/in the application payload/

Section 12.1.2
SRV service name strings 'stun' should be introduced here in Sections
12.1.2 instead of in 8.1

Sect 12.1.7 para 1
s/PDU/payload/
s/then using in/then used in/

 para 2
s/version of the server/version of the server reached by the client/

Sect 12.2.1 para 1
s/(for example, a SIP proxy server)//
[A proxy is not an example of a *protocol*]

 para 2
s/The client can also/For UDP, the client can also/

Sect 12.2.3
PROPOSED:
The server multiplexes both STUN and its application protocol on the
same port. The server knows to enable this usage because use of STUN
with this application protocol was negotiated or discovered.

Sect 12.3
s/In order to ensure interoperability, this usage/This usage/
[The whole point of this spec is to ensure interop]

Sect 12.3.6
PROPOSED:
No new error response codes are defined by this usage.
[433 is already defined with all the rest of the error codes]

Sect 12.3.7 para 3
s/If the response was a/If the response is a/

Sect 12.3.8 last para
s/SHOULD be better than/SHOULD be smaller than/

Sect 12.3.9 para 4
s/on an Least/on a Least/

 last para
s/with using/with, using/

Sect 13
s/However, all of the other usages/However, the other two usages/

Sect 15.2
FINGERPRINT and ALTERNATE-SERVER conflict.

Sect 16, 5th bullet
s/0b00/zero/

 insert into bulleted list "Introduced the concept of Indications."

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