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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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.



[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



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



[4] 2.4. ICE Usage



Comment> Any specific reason to say "NOT RECOMMENDED" ? why not say "MUST NOT use ORIGIN attribute" ?



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



[6]   STUN defines three authentication modes, depending on the STUN usage.



Comment> There are only two authentication modes !



[7] Suggest to split Introduction, have a separate section to discuss the problem.



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



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]<mailto:[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]<mailto:[e-mail]>>, Alan Johnston <[e-mail]<mailto:[e-mail]>>, John Yoakum <[e-mail]<mailto:[e-mail]>>, Justin Uberti <[e-mail]<mailto:[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<http://tools.ietf.org>.

The IETF Secretariat