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

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 14 Dec 2017 07:09:54 +0000

Hi Marc,

I am fine with not modifying the document for any item you marked as "New work" although I would prefer them to be addressed as at least some of them are really confusing, e.g. what a "basic server" is.

Regarding vii- below;
The change I am suggesting is:
Alternatively, a client MAY be configured with a set of domains or IP addresses that are trusted;
==>
Alternatively, a client MAY be configured with a set of IP addresses that are trusted;

The reason being that RFC6125 already covering "trusted set of domains". I am not feeling strongly about this change through; your call.

Could you submit a new version, at least with the changes you agreed below, so that we can get closer to concluding the WGLC?

Thanks,
Tolga

-----Original Message-----
From: tram [mailto:[email-masked]] On Behalf Of Marc Petit-Huguenin
Sent: Friday, November 10, 2017 5:41 AM
To: Asveren, Tolga <[email-masked]>; [email-masked]
Subject: Re: [tram] WGLC comments for draft-ietf-tram-stunbis-12

Hi Tolga,

Thanks for the review.

My main concern about most of your comments is that they are not relevant to -stunbis, but to RFC 5389, i.e. that they want to revisit text that was already approved by the IESG back when RFC 5389 was published.

Now there is nothing wrong about this, as the purpose of stunbis was to revisit the parts of RFC 5389 that needed an update.  But what you are asking is expanding the scope of stunbis, which means another round of reviews for the Working Group.  The WG activity is very low, so I would like first to ask the WG if they want us to take on these modifications.

I annotated the comments below with "New work" to signal when this is the case.  I'll publish a new version of stunbis as soon the submission tool reopen.

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

Done.  Note that this is an informative reference, so it is not blocking the document.  Also there is no place to signal that to the RFC Editor, by they know how to do that.

> 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>.”

New work.

> 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?

New work.

> 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.

New work.

> 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.

New work.

> 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?

New work.

> 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.

What modification are you suggesting?

> 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?

New work.

> 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?

New work.

> 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?

New work.

> 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.
The first sentence could state that it is only for "stun" URI.  I modified that.

I do not think that there is a conflict.  The former states that if the STUN URI was received from an HTTPS request, then the IP address can be trusted.  The latter states that there can be a configured list of IP addresses that are trusted.

Now I agree that for the former, the text is not very good.  I fixed that.

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

New work.

> 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?

No, one packet can get discarded because of a transmission error that was not detected by a checksum.  If all were modified, then it is an attack.

> 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?

New work.

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

New work.

> 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.

New work.

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

Same than RFC 5389.

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

Same than RFC 5389.

>    ** Obsolete normative reference: RFC 2460

Updated.

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

Updated.

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

Updated.

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

Updated.

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

Intensional.

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

Updated.

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 15 Dec 2017 07:18:41 -0800

> I am fine with not modifying the document for any item you marked as "New work" although I would prefer them to be addressed as at least some of them are really confusing, e.g. what a "basic server…

All right, I replaced the first paragraph with this:

"This section defines the behavior of a basic, stand-alone STUN
 server.

 Historically Classic STUN [RFC3489] only defined the behavior of a
 server that was providing clients with server reflexive transport
 addresses by receiving and replying to STUN Binding requests.
 [RFC5389] redefined the protocol as an extensible framework and the
 server functionality became the sole STUN Usage defined in that
 document.  This STUN Usage is also known as Basic STUN Server."

> The reason being that RFC6125 already covering "trusted set of domains". I am not feeling strongly about this change through; your call.

Done.

> Could you submit a new version, at least with the changes you agreed below, so that we can get closer to concluding the WGLC?

I have a call scheduled with my co-author Monday afternoon to do some cleanup on the text, so I'll publish the new version after that.

Thanks.