Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.txt

[Alan Johnston <[e-mail]>]

Hi Tiru,

Thanks for the close reading - see my comments below.

- Alan -


On Mon, Jun 30, 2014 at 1:13 PM, Tirumaleswar Reddy (tireddy) <
[e-mail]> wrote:

>  Hi Alan,
>
>
>
> My comments:
>
>
>
> [1] Security Considerations:
>
>
>
> Comment> You may want to add that If (D)TLS is used then STURN ORIGIN
> attribute cannot be modified by an intermediary.
>
>
Right.  I'll point this out.


>
>
> [2] This information is often available in other messages sent by the
> browser, such as DNS or HTTP requests.
>
>
>
> Comment>  Yes, but all these problems will most likely be addressed in
> future.  DNSOP WG is discussing various mechanisms for DNS privacy like DNS
> over (D)TLS and HTTP/2.0 mandates TLS.  New TLS extensions are discussed in
> TLS WG to encrypt TLS handshake for privacy reasons
>
>
>

Right.  I can soften this a bit to say "This information can be available
in other messages sent by the browser, such as DNS or HTTP request, unless
those protocols are using encryption."



>  [3] Section 2.4 ICE usage
>
>
>
> Comment> You may also say that for consent checks (
> http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04),
> STUN ORIGIN attribute is not required.
>
>
>
Agreed.  This is an extension to ICE, so I think it still counts as an ICE
usage, but I think it is worth saying explicitly.


>  [4] 2.4. ICE Usage
>
>
>
> Comment> Any specific reason to say "NOT RECOMMENDED" ? why not say "MUST
> NOT use ORIGIN attribute" ?
>
>
I think NOT RECOMMENDED, effectively SHOULD NOT, is the right level here.
 There is no harm done (i.e. it doesn't cause any interop failures or
issues) if it is included, and we may come up with use cases in the future.
 I think ICE stacks should be prepared to receive an ORIGIN attribute, and
should just ignore it.

>
>
> [5] Senders MAY include multiple ORIGIN attributes in a request, and
> receivers MUST support parsing and receiving multiple ORIGIN attributes.
>
>
>
> Comment> If path MTU is unknown then STUN messages over IPv4 would need to
> be less than 548 bytes (Section 7.1 of [RFC5389]). Sender must use this
> length restriction to limit the number of ORIGIN attributes in the STUN
> request.
>
>
>

Good point.  I'll mention that including multiple Origin attributes
increases the size of STUN packets.

 [6]   STUN defines three authentication modes, depending on the STUN usage.
>
>
>
> Comment> There are only two authentication modes !
>
>
Well, there are three described in this paragraph: short term credential,
long term credential, and no credential (NULL).  I can make this clearer in
the text.

>
>
> [7] Suggest to split Introduction, have a separate section to discuss the
> problem.
>
>
>
Yes, it is a bit large.  Some of this text, I think, can probably be
dropped, as it discusses alternative approaches which aren't described in
the document.  I can reorganize or condense.


>  [8] In addition to explicitly provisioning the realm value in the java
> script the other problem is exposing the user credentials to the
> JavaScript.
> http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz-02
> addresses this problem.
>
>
>
Sure, this draft does nothing to solve that problem - it only addresses the
multi-realm issue.


>  Thanks and Regards,
>
> -Tiru
>
>
>
>
>
> *From:* tram [mailto:[e-mail]] *On Behalf Of *Alan Johnston
> *Sent:* Saturday, June 28, 2014 10:35 PM
> *To:* [e-mail]
> *Subject:* [tram] Fwd: New Version Notification for
> draft-johnston-tram-stun-origin-03.txt
>
>
>
> All,
>
>
>
> We have updated the STUN Origin draft.  The major changes relate to:
>
>
>
> 1. Adding sections on media keep-alive and SIP keep-alive usages
>
> 2. Adding a section on multiple origins
>
> 3. Adding a section on Implementation Status about the open source
> implementations of the browser and STUN/TURN server that support the ORIGIN
> attribute
>
> 4. Clarified integrity protection of the attribute in the Security
> Considerations section.
>
>
>
> These changes are based on all recent reviews and mailing list comments.
>
>
>
> As always, comments are most welcome!
>
>
>
> - Alan -
>
>
>
> ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: Sat, Jun 28, 2014 at 11:50 AM
> Subject: New Version Notification for
> draft-johnston-tram-stun-origin-03.txt
> To: Kundan Singh <[e-mail]>, Alan Johnston <
> [e-mail]>, John Yoakum <[e-mail]>, Justin Uberti
> <[e-mail]>
>
>
>
> A new version of I-D, draft-johnston-tram-stun-origin-03.txt
> has been successfully submitted by Alan Johnston and posted to the
> IETF repository.
>
> Name:           draft-johnston-tram-stun-origin
> Revision:       03
> Title:          An Origin Attribute for the STUN Protocol
> Document date:  2014-06-28
> Group:          Individual Submission
> Pages:          13
> URL:
> http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/
> Htmlized:
> http://tools.ietf.org/html/draft-johnston-tram-stun-origin-03
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-03
>
> Abstract:
>    STUN, or Session Traversal Utilities for NAT, is a protocol used to
>    assist other protocols traverse Network Address Translators or NATs.
>    STUN, and STUN extensions such as TURN, or Traversal Using Relays
>    around NAT, and ICE, Interactive Communications Establishment, have
>    been around for many years but with WebRTC, Web Real-Time
>    Communications, STUN and related extensions are about to see major
>    deployments and implementation due to these protocols being
>    implemented in browsers.  This specification defines an ORIGIN
>    attribute for STUN that can be used in similar ways to the HTTP
>    header field of the same name.  WebRTC browsers utilizing STUN and
>    TURN would include this attribute which would provide servers with
>    additional information about the STUN and TURN requests they receive.
>    This specification defines the usage of the STUN ORIGIN attribute for
>    web and SIP contexts.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>