Subject: [tram] WGLC comments for draft-ietf-tram-stunbis-12

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 30 Sep 2017 12:31:59 +0000

Here are my comments for draft-ietf-tram-stunbis-12 WGLC:
(It could be easier for tracking purposes if authors reply in separate threads/bundle relevant ones into separate threads)

i- Please reference latest version of [I-D.ietf-ice-rfc5245bis], and indicate that it should be updated by RFC Editor with the latest version/RFC number (if present) before publication of this document

ii-
STUN is intended to be used in context of one or more NAT traversal
   solutions.  These solutions are known as STUN usages.  Each usage
   describes how STUN is utilized to achieve the NAT traversal solution.
I think there are use cases for non-NAT environments as well, e.g. RFC5626 keep-alive for flows without NAT to detect Edge Proxy crash. Maybe adding a sentence along the following lines could be good:
"STUN may also be used for cases where a NAT is not present, e.g., to detect crash of an Edge Proxy based on procedures defined in RFC5626 <reference RFC5626>."

iii-
Both types of transactions include a transaction ID, which
   is a randomly selected 96-bit number.
It may be useful to provide some guidance how this could be made (close to) globally unique?

iv-
The server also uses
   the transaction ID as a key to identify each transaction uniquely
   across all clients.  As such, the transaction ID MUST be uniformly
   and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be
   cryptographically random.
There still is the possibility of a clash. What are the implications if that happens? A short clarification could be useful.

v- Structurally, it would be better to specify "binding" as a "method" in its own/separate section rather than in the sections pertaining to general message processing.

vi-
Absent other limits to
   the rate of new transactions (such as those specified by ICE for
   connectivity checks or when STUN is run over TCP), a client SHOULD
   limit itself to ten outstanding transactions to the same server.
What is the justification for this?

vii-
Alternatively, a
   client MAY be configured with a set of domains or IP addresses that
   are trusted; if a certificate is received that identifies one of
   those domains or IP addresses, the client considers the identity of
   the server to be verified.

Isn't this already covered by following from RFC6125 (at least the "domain")
1.  The client constructs a list of acceptable reference identifiers
       based on the source domain and, optionally, the type of service
       to which the client is connecting.
...
As previously mentioned, this document specifies that
      a URI-ID always contains a "host" component (or its equivalent)
      containing a "reg-name".  (Matching only the "reg-name" rule from
      [URI<https://tools.ietf.org/html/rfc6125>] limits verification to DNS domain names, thereby
      differentiating a URI-ID from a uniformResourceIdentifier entry
      that contains an IP address or a mere host name, or that does not
      contain a "host" component at all.)

It seems only "IP" is excluded.

viii-
It checks that the first two
   bits are 0, that the magic cookie field has the correct value, that
   the message length is sensible, and that the method value is a
   supported method.
What does "sensible" mean in this context?

ix-
If the success response contains unknown comprehension-required
   attributes, the response is discarded and the transaction is
   considered to have failed.
When would such a response be generated?

x-
If the error code is 500 through 599, the client MAY resend the
      request; clients that do so MUST limit the number of times they do
      this.
It may be useful to provide some guidance/recommended values?

xi-
If the <host> part contains an IP address, then this IP address is
   used directly to contact the server.  A "stuns" URI containing an IP
   address MUST be rejected, unless the domain name is provided by the
   same mechanism that provided the STUN URI, and that domain name can
   be passed to the verification code.
Isn't this in conflict with the statement
Alternatively, a
   client MAY be configured with a set of domains or IP addresses that
   are trusted; if a certificate is received that identifies one of
   those domains or IP addresses, the client considers the identity of
   the server to be verified.

xii- Would it be useful to define a DHCP option for STUN Servers similar to SIP in RFC3361?

xiii-
If the request was sent over an unreliable transport, the response
   MUST be discarded, as if it was never received.  This means that
   retransmits, if applicable, will continue.  If all the reponses
   received are discarded then instead of signalling a timeout after
   ending the transaction the layer MUST signal that an attack took
   place.
Why signal attack only if all retransmissions are problematic? Shouldn't this happen even if only one is discarded?

xiv- "Basic Server", what does it really refer to? What are alternatives? Was the goal here to describe behavior of a "STUN Binding Server"? If so, shouldn't it be renamed as such rather than as "Basic Server"? Or are there procedures which pertain to "Basic Servers in general" (again whatever a Basic Server is)? Is defining behavior for a "backward compatible server" the real goal here?

xv-
10.  ALTERNATE-SERVER Mechanism
What is raison d'etre for defining such a mechanism? Is there an already known use case?

xvi-
It SHOULD NOT
   utilize the short-term or long-term credential mechanism.  This is
   because the work involved in authenticating the request is more than
   the work in simply processing it.  It SHOULD NOT utilize the
   ALTERNATE-SERVER mechanism for the same reason.
Isn't backward compatibility the real reason for not using credentials and ALTERTNATE-SERVER? Otherwise there could be reasons other than processing cost which could make them applicable, e.g. for credentials, not wanting to serve illegitimate users, and for ALTERNATE-SERVER getting ready for an upgrade.

xvii- From idnits:
** Downref: Normative reference to an Informational RFC: RFC 1321

  ** Downref: Normative reference to an Informational RFC: RFC 2104

  ** Obsolete normative reference: RFC 2460

  ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
     RFC 7616, RFC 7617)

  == Outdated reference: A later version (-12) exists of
     draft-ietf-ice-rfc5245bis-01

  -- Obsolete informational reference (is this intentional?): RFC 2616
     (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)

  -- Obsolete informational reference (is this intentional?): RFC 3489
     (Obsoleted by RFC 5389)

  -- Obsolete informational reference (is this intentional?): RFC 5226

Thanks,
Tolga