Subject: [BEHAVE] Comments on rfc3489bis-05

From: "Derek MacDonald" <[email-masked]>
Date: Sun, 10 Dec 2006 14:34:34 -0800

I tried not to have too much overlap with other reviewers, but there will be
some.

General Comments

I don't think the NONCE attribute should be optional.  As every client
implementation will need to support it, unless they only in deployment s
where only short term credentials without a NONCE are used. Having  NONCE be
mandatory for short-lived and long-lived credentials would:

1. Simplify the implementation of clients that implement the full
specification
2. Allow short-term credentials to be longer lived, as the NONCE would
provide temporal scoping. For example, having a short-term credential could
last a day or multiple days would greatly reduce the TLS load on the STUN
server.

Specific Substantive Comments

7.1

   Retransmissions continue until a response is received, or a total of
   7 requests have been sent.  If no response is received by 1.6 seconds
   after the last request has been sent, the client SHOULD consider the
   transaction to have failed.

I don't really understand the 1.6 second value; the retransmission interval
is RTT based, shouldn't the time that a client waits after the last request
also be RTT based?  What is the motivation for 1.6 seconds?

Similarly in:

   When running STUN over TCP, TCP is responsible for ensuring delivery.
   The STUN application SHOULD NOT retransmit STUN requests when running
   over TCP.  If the client has not received a response after 7900ms, it
   considers the transaction to have timed out.

where does the value of 7900ms  for TCP come from? It may be correct, but it
is not motivated.

8.3.2

    Unknown optional attributes in a response (greater than 0x7FFF) MUST
    be ignored by the STUN client.  Responses containing unknown
    mandatory attributions (less than or equal to 0x7FFF) MUST be
    discarded and considered immediately as a failed transaction.

/s/attributions/attributes

This paragraph contradicts the decision we made at the ietf to have servers
which are implementing the Nat discovery usage always return OTHER-ADDRESS
in a binding response.  One solution is to add OTHER-ADDRESS as a known
attribute to 3489bis.  We could also move OTHER-ADDRESS into the optional
attribute range, but this will break backwards compatibility with existing
3489 servers used for discovery(OTHER-ADDRESS is CHANGED-ADDRESS renamed,
the value is still 0x0005).

Editorial Comments

5.

   Some usages (such as the binding keepalive) require STUN messages to
   be sent on the same transport address as some application protocol,
   such as RTP or SIP.  To facilitate the demultiplexing of the two,
   STUN defines a special field in the message called the magic cookie,
   which is a fixed 32 bit value that identifies STUN traffic.  STUN
   requests also contain a fingerprint, which is a cryptographic hash of
   the message, that allow for validation that the message was a STUN
   request and not a data packet that happened to have the same 32 bit
   value in the right place in the message.

The motivation of having both the fingerprint attribute and the magic cookie
should be summarized; it is explained several times later on in the
document(ex 8.3.1). Suggested paragraph:

   Some usages (such as the binding keepalive) require STUN messages to
   be sent on the same transport address as some application protocol,
   such as RTP or SIP.  To facilitate the demultiplexing of the two,
   STUN defines a special field in the message called the magic cookie,
   which is a fixed 32 bit value that identifies STUN traffic.  STUN also
defines an
   optional fingerprint attribute, which can be used when application
protocol messages may contain a
   binary value which is equal to the magic cookie. The fingerprint is a
cryptographic hash of
   the message, that allow for validation that the message was a STUN
   request and not a data packet that happened to have the same 32 bit
   value in the right place in the message.

6. The sentence:

   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.

could be reworded to:

  Unless a request is a retransmission a client MUST choose a new
transaction ID for it. A different transaction id MUST be used for
  each indication.

AFAIK, indications are never retransmitted, and retransmissions are the only
reason to re-send a request with the same tid.

7.2 Indication failures should only be retried if it is appropriate for the
usage; it would not be appropriate for the relay usage, which is the only
usage that defines indications so far.  Maybe the onus should be on a usage
to define whether indications should be retransmitted to alternate servers?

8.3.1
   When STUN is being multiplexed on the same transport address as
   application data, and there are valid application layer data packets
   which could be confused with STUN packets (because, for example, bits
   32 through 63 can contain an arbitrary binary value which might be
   equal to 0x2112A442), the FINGERPRINT attribute MUST be present.
   Otherwise, its inclusion is RECOMMENDED.

Contradicts section 10, specifically the sentence:

   If this probability is deemed sufficiently small for the application at
hand (for
   example, it is considered adequate for Voice over IP applications),
   then any packet with this value in its second 32 bit word is
   processed as a STUN packet.

Possibly reword to:
  the FINGERPRINT attribute MUST be present if one in 2^32 application
protocol packets being interpreted as STUN is not acceptable.
  Otherwise, its inclusion is RECOMMENDED.

8.3.2

   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.  If the client receives a 432
   (Missing Username) but had included both MESSAGE-INTEGRITY and
   USERNAME in the request, there has been an unrecoverable error.  This
   shouldn't ever happen, but if it does, the client SHOULD NOT retry
   the request.

A client missing the username but including message is an implementation
error in the client.  We should not describe recovery behaviour for this
situation, just state that the client is not to spec.

I'm not sure if we need separate error codes for this type of implementation
error, or just an illegal message error code where the text string describes
the error, but I don't feel strongly about this.

11.7 Having a value which is always a quoted string seems odd as the quotes
have no semantics.  Don't really care.

11.10

   This attribute MUST always be present in a Binding Response and may
   be used in other responses as well.  Usages defining new requests and
   responses should specify if XOR-MAPPED-ADDRESS is applicable to their
   responses.

This MUST only holds if the client supports 3489bis; other wise
MAPPED-ADDRESS must be used. Maybe:

   This attribute MUST always be present in a Binding Response when the
client supports this specification and may...

12.2.3

The server would know it is running the keepalive usage because of its
implementation of configuration; inspection of its own uri to determine this
is unlikely. I suggest removing 12.2.3 completely.

12.3.6.

   This usage defines the 433 error response.  Only the MESSAGE-
   INTEGRITY, ERROR-CODE and SERVER attributes are applicable to this
   response.

/s/the 433/the 433(UseTLS)

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