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

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 4 Oct 2017 02:44:11 -0700

Thank you for the review.

Gonzalo and I will work on that next week and publish a new version.

Thanks.

On 09/30/2017 05:31 AM, Asveren, Tolga wrote:
> 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
> 
> 
> 

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug