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

[Alan Johnston <[e-mail]>]

Andy,

Thanks for your review and comments. 

When you mentioned multiple origins, I thought you were referring to a SIP origin and an HTTP origin, but it seems the HTTP origin has the concept of more than one. I wonder if browsers ever generate this?

I will add some discussion of this in the next version, including Oleg's useful set of issues below. 

- Alan -

> On Jun 5, 2014, at 2:55 PM, Oleg Moskalenko <[e-mail]> wrote:
> 
> If we do want to support multiple origins per request then we have to state, clearly, three things:
> 
>   1) Use cases.
>   2) How we use multiple origins when we process the request.
>   3) How we format multiple origins in the request - as comma-separated single field or multiple origin attributes. As STUN/TURN is a binary protocol, I think that the second option is better.
> 
> The usefulness of multiple origins in TURN is not very obvious to me. I implemented ORIGIN in a pilot implementation https://code.google.com/p/coturn/ but I assumed a single ORIGIN field per request.
> 
> Oleg
> 
> 
>  
> 
> 
>> On Thu, Jun 5, 2014 at 7:48 AM, Hutton, Andrew <[e-mail]> wrote:
>> Multiple Origins for HTTP Requests are covered in http://tools.ietf.org/html/rfc6454#section-7.2 I just assumed the same would apply to the usage in this context.
>> 
>> Andy
>> 
>> > -----Original Message-----
>> > From: Oleg Moskalenko [mailto:[e-mail]]
>> > Sent: 05 June 2014 15:26
>> > To: Hutton, Andrew
>> > Cc: Alan Johnston; [e-mail]
>> > Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02
>> >
>> > What would be the purpose of multiple origins ?
>> >
>> > Oleg
>> >
>> > On Jun 5, 2014, at 7:19 AM, "Hutton, Andrew" <[e-mail]>
>> > wrote:
>> > Hi,
>> >
>> > I had another read through this draft and hope we can move this forward
>> > and adopt the draft soon.
>> >
>> > I only have one additional comment at this time and that is that I
>> > assume it should be possible for the client to include more than one
>> > origin in the Origin header field and if so the procedures around this
>> > should explained in the draft.
>> >
>> > Regards
>> > Andy
>> >
>> >
>> >
>> >
>> > From: tram [mailto:[e-mail]] On Behalf Of Alan Johnston
>> > Sent: 07 May 2014 18:50
>> > To: Marc Petit-Huguenin
>> > Cc: [e-mail]
>> > Subject: 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
>> > <[e-mail]> 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  |  [e-mail]
>> >
>> >
>> > _______________________________________________
>> > tram mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/tram
>> >
>> > _______________________________________________
>> > tram mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/tram
>