Subject: [BEHAVE] STUN comments part 1

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 6 Dec 2006 12:30:41 -0800

Hi,

Below are the first part of my STUN comments through the end of Section 8.3.1.

thanks,
-rohan

Substantive Comments

0) We have no statement about what level of backwards compatibility we
are trying to maintain with this spec.  The way the spec is written
now a bis client will work with old or new servers, but not vice-versa
(the server is required by the previous spec to include the historical
attributes in several cases).  I think this is potentially OK, but at
least should be explicitly mentioned.

1) Use names of the usages consistently.  I like the following:
  Binding Discovery
  Keepalive
  Shared Secret
The Keepalive usage does not need to be used with a NAT, so 'NAT
Keepalive' is not a great term for the usage. I really hate the term
"Binding Keepalive" because it makes folks confused.  Many think we
are talking about the Binding Discovery usage, and others merge the
two usages in their mental model.

2) In Section 7.1 paras 2 through 4 are less clear than the
corresponding text in -03.  I would be happy to take a stab at this.
Is the final timer 1.6 seconds exactly or 16x RTO?

3) Section 7.2 para 2 (resending indications) is a bad idea for TURN
and as far as I am aware, not useful for any other usage.  I strongly
recommend simply deleting this paragraph.  If a new usage or extension
needs this behavior in the future, it can add appropriate language
then.

4a) IMO, the SRV discovery procedures in 8.1 should not contain any
service names.  The service name, if any, should be specified in each
usage. The way this is worded now is actually self-contradictory.

4b) SRV transport protocols:  I think we want to switch to _tls-tcp
going forward and allow _tls for backwards compatibility.  I am also
fine if we just leave _tls, but we should be explicit that a new
transport token should use _tls-foo.

5) Authentication is one of the most confusing aspects of this
specification.  I think a new subsection should be inserted before
8.3.1 called 'Including Credentials in Requests' which contains para 2
through 6 ("The NONCE...").  I would also add a non-normative table
summarizing which authentication attributes are included when.

                               credentials
                       none    short-term    long-term
In Requests
MESSAGE-INTEGRITY       -          X             X
USERNAME                -          X             X
REALM                   -          -             X
NONCE (first req)       -          -             -
NONCE (subsequent)      -          O             X

In Responses
MESSAGE-INTEGRITY       -          X             X
USERNAME                -          X             X
REALM                   -          -             X
NONCE                   -          O             X

In Indications
MESSAGE-INTEGRITY       -          X             -
USERNAME                -          X             -
REALM                   -          -             -
NONCE                   -          -             -

6) When the magic-cookie is sufficient for demuxing, what will we
recommend is done with the FINGERPRINT?  SHOULD send, MAY send, SHOULD
NOT send?

NITS

Sect 2, para 2
BEFORE
ALGs have serious limitations, including scalability,
   reliability, and speed of deploying new applications.
PROPOSED
ALGs have serious limitations, including scalability,
   reliability, incompatibility with message integrity and
encryption techniques, and speed of deploying new applications.

Sect 4, STUN Server, last sentence
s/Servers also send/Servers can also send/

Sect 4, Long Term Credential
s/enrolles/enrolls/

Sect 5, 1st para
add a period to the end of the last sentence

 para 3
s/in which client/in which a client/

 para 4
s/outermost NAT towards the/outermost NAT with respect to the/

 para 6
s/out-of-bands/out-of-band/

 para 8
s\Binding requests\Binding and/or other requests\

 para 9
s/Real Time Transport Protocol/Real-time Transport Protocol/

 para 10
s/binding keepalive/Keepalive/  (see comment #1)
delete sentence "In the case of SIP, this would typically...."
s/and also inform/and over UDP, also inform/

 para 11
s/These two usages all/These two usages both/

Sect 6, para 3
TCP/TLS  --> TLS over TCP

 para 4
s/TCP or UDP/UDP, TCP, or TLS over TCP/

 Figure 3
I think this diagram would be a bit clearer:
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|M|M|M|M|M|C|M|M|M|C|M|M|M|M|
| | |1|1|9|8|7|1|6|5|4|0|3|2|2|0|
| | |1|0| | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 para 11 (begins "The transaction ID...")
OLD
The transaction ID is a 96 bit identifier.  STUN transactions are
   identified by their unique 96-bit transaction ID.  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.  The transaction ID MUST be uniformly and randomly
   distributed between 0 and 2**96 - 1.  The large range is needed
   because the transaction ID serves as a form of randomization, helping
   to prevent replays of previously signed responses from the server.  A
   reponse to the STUN request, whether it be a success or error
   response, carries the same transaction ID as the request.
   Indications are also identified by their transaction ID.  The
   transaction ID there MUST also be uniformly and randomly distributed
   between 0 and 2**96 - 1.As with requests, the value is chosen by the
   server and MUST be unique for each unique indication generated by the
   server.  Unless a request or indication is bit-wise identical to a
   previous request, and was sent to the same server from the same
   transport address, a client MUST choose a new transaction ID for it.
NEW
The transaction ID is a 96 bit identifier.  STUN transactions are
   identified by their unique 96-bit transaction ID.  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.  The transaction ID MUST be uniformly and randomly
   distributed between 0 and 2**96 - 1.  The large range is needed
   because the transaction ID serves as a form of randomization, helping
   to prevent replays of previously signed responses from the server.  A
   reponse to the STUN request, whether it is a success or error
   response, carries the same transaction ID as the request. Unless a request
   is bit-wise identical to a
   previous request, and was sent to the same server from the same
   transport address, a client MUST choose a new transaction ID for it.
<new para>
   Indications are also identified by their transaction ID.  The
   transaction ID there MUST also be uniformly and randomly distributed
   between 0 and 2**96 - 1. The value is chosen by the
   sender of the indication, and MUST be unique for each unique indication
   generated by the sender.

 para 12 (begins "The Length...")
s/attributes whose content is not a
   multiple of 4 bytes are padded with 1, 2 or 3 bytes of padding so
   that they are a multiple of 4 bytes.
/any attribute whose content is not a
   multiple of 4 bytes is padded with 1, 2 or 3 bytes of padding so
   that its value contains a multiple of 4 bytes./

Sect 8 para 1 is really wrong.  You only obtain a shared secret for
some usages and obtaining the shared secret involves its own discovery
step (never mentioned).  I propose just deleting this whole paragraph.

Sect 8.1 para 5
s/is set up is a/is set up, is a/

 para 6
s/The application usage/Each application usage/

 last para.  replace with:
Each STUN usage describes if shared secrets are employed by that usage
and any additional rules for obtaining those shared secrets.

Sect 8.3.1 para 5 (begins "3. If a long...")
s/were/is/g

 para 10 (begins "For TCP and TLS...")
s/to send further requests/to send or receive further data over this
connection.  The STUN usage may provide additional guidance about
connection lifetime management./

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