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

[Oleg Moskalenko <[e-mail]>]

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
>