Re: [tram] Review of draft-johnston-tram-stun-origin-02

Marc,

Thanks for the review.  See my comments below.

- Alan -

On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin <marcph@getjive.com>wrote:

> A1. Intended Status: Informational
>
> Shouldn't this be Standard Track?
>
>
Yes.

> A2. Section 1, 2nd paragraph, last sentence: "as generating the
> response..."
>
> I do not think that the reason for no authentication for the NAT
> Discovery Usage is because it is less work, but because there is no
> resource to protect so adding more work does not make sense.
>
>
I disagree that there is *no* resource to protect.  A STUN server might be
minimal resources, but not none.  If a simple authentication scheme were
available, I'm sure some people would use it so they could minimize the
cost of their server footprint by ensuring that only authenticated users
were utilizing it.  I will add some text pointing out that the minimal
resources.

> A3. Section 1, 8th paragraph
>
> I do not think that the ORIGIN should be used to select the certificate
> when (D)TLS is used.  First it does not work with DANE, as when an SRV
> (and probably NAPTR too, but that's undefined yet) RR redirects to a
> different domain, the domain to be checked with is the host name, not
> the service domain (see draft-ietf-dane-srv).  For non-DANE cases, I
> think that the correct way to select the certificate is to use SNI.
>

The draft does not suggest that ORIGIN be used to select certificates - as
Oleg pointed out it isn't possible.  This paragraph was describing how RFC
6066 does not solve the problem, as had been suggested on the list.

>
> So I would suggest to restrict the normative use of ORIGIN only to
> select realms.
>
> A4. Section 2.2. ORIGIN attribute usage
>
> The text does not say if the ORIGIN attribute should/can be provided
> after the authentication (i.e. refresh, data packets, etc...)
>

Currently, the text says SHOULD include, for a conformant client.  For
logging, it has value even after the initial authentication.

>
> A5. Section 2.2.  Mandatory support for server
>
> How a TURN server that requires the usage of ORIGIN can signal this?
>
>
Right now there is no way to do this.  I agree with Oleg that it is up to
the server what to do if ORIGIN is no present.

> A6. Section 2. Other Usages
>
> I think that other STUN Usages should be listed after section 2.3:
>
> - Media Keep-Alive Usage (Section 20 of RFC5245)
> - SIP Keep-Alive Usage (RFC 5626)
> - NAT Behavior Discovery Usage (RFC 5780)
>
>
I'll take a look at these scenarios.  I suspect that it would be a
reasonable usage for client-to-server usages, but not for peer-to-peer
usages.

> A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute
> is present, the contents of the ORIGIN attribute are integrity protected."
>
> Which never happen in the usages listed in the document:  for section
> 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is
> needed to select the realm, so the ORIGIN is sent before it can be
> protected.  Perhaps 2.2 should say that if ORIGIN was sent to select the
> realm, it MUST be repeated at identical on the second Allocate (the one
> that has an M-I) and that the server MUST reject it if it is not
> identical to the first one.  Not sure it matters though.
>
>
I agree that there is no integrity protection of the ORIGIN attribute (or
any other attribute) until after authentication.  However, ORIGIN can be
used both before and after authentication.  I'll review this text and make
sure this is clear.  I don't believe we need any special rules, as this
applies to any STUN attribute.

> Nits
> ----
>
> - Section 2, 2nd paragraph: "The number used for the this in the ..."
>
> Does not parse.
>

The middle "the" shouldn't be there.

>
> --
> Marc Petit-Huguenin
> Developer  |  Jive Communications, Inc.
> Jive.com  |  marcph@getjive.com
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>