Re: [tram] Fwd: I-D Action: draft-johnston-tram-stun-origin-02.txt

[Brandon Williams <[e-mail]>]

Hi Justin,

Let me backtrack on my use of the word "frequently", which suggests that 
small MTUs are more common than I believe them to be. Let me say instead 
that small MTUs are not unheard of. I am unfortunately not in a position 
to give numbers, because we no longer forward the DF bit on outgoing 
packets (for this reason). I agree that it is uncommon, but when it 
occurs, it can cause session failure if you don't help the packets get 
through.

So, despite my poor choice of words, I really just meant to indicate 
that it does happen sometimes, and that it would be good for a spec that 
allows such a large attribute value to provide some guidance on how to 
handle the attribute if the resulting message will violate the message 
size constraints required by the existing RFCs.

--Brandon

PS: I will do some more investigation and see if I can come up with a 
number after all, though I'm not too confident.

On 04/04/2014 08:05 PM, Justin Uberti wrote:
>
>
>
> On Fri, Apr 4, 2014 at 2:20 PM, Brandon Williams
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi Alan,
>
>     Has attribute number 0x802F been assigned? I don't see it in the
>     official registry. If not, then I suggest you follow the common
>     practice of using a placeholder (e.g. TBD) in place of the option
>     number throughout the document with a note to the editor about the
>     search-and-replace operation to be done before publishing. I know
>     there's a related editor's note in the document, but the referenced
>     rfc4020 specifically indicates that you should not include an
>     unallocated value in an I.D.
>
>     On a separate note, RFC5389 requires a maximum message size of 548
>     bytes when the sender is using IPv4 and the MTU is not known. Even
>     for cases where the MTU is known, we frequently see mobile clients
>     with very small MTUs at or close to the IPv4 minimum,
>
>
> This question has come up in the past and the consensus (and empirical
> data from Chrome) indicated that nowadays MTUs < 1280 are quite
> uncommon. Can you provide some more detailed stats and examples?
>
>     which would require this small message size even after MTU
>     discovery. I'm concerned about an attribute with a max value size
>     that uses up nearly 50% of that space. I think it would be good for
>     the draft to discuss this issue and provide some related guidance on
>     usage. For example, how much of the 548 bytes are used in a typical
>     STUN Bind request? or a TURN Allocate request? Does use of this
>     attribute conflict with similar size constraints imposed by any
>     other current drafts? If there isn't enough space, how should the
>     client handle it?
>
>     In addition to that, I would appreciate a bit more detail about
>     where this option is expected to show up in the message exchanges. I
>     think I know, but I'm not sure. Am I correct that you expect its use
>     for authentication to only require it in the initial unauthenticated
>     TURN Allocate request? And that any later use would be primarily for
>     diagnostics? If that's the case, then it might be worth pointing
>     this out in the Security Considerations section (i.e. that the
>     primary security related use is the one case where auth doesn't apply).
>
>     --Brandon
>
>
>     On 03/31/2014 05:41 PM, Alan Johnston wrote:
>
>         All,
>
>         We have revised the STUN Origin draft based on feedback on the
>         list and
>         from London.
>
>         Comments most welcome.
>
>         - Alan -
>
>         ---------- Forwarded message ----------
>         From: ** <[e-mail]
>         <mailto:[e-mail]>
>         <mailto:internet-drafts@ietf.__org
>         <mailto:[e-mail]>>>
>         Date: Mon, Mar 31, 2014 at 4:40 PM
>         Subject: I-D Action: draft-johnston-tram-stun-__origin-02.txt
>         To: [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>
>
>
>         A New Internet-Draft is available from the on-line Internet-Drafts
>         directories.
>
>
>                   Title           : An Origin Attribute for the STUN
>         Protocol
>                   Authors         : Alan Johnston
>                                     Justin Uberti
>                                     John Yoakum
>                                     Kundan Singh
>                   Filename        : draft-johnston-tram-stun-__origin-02.txt
>                   Pages           : 10
>                   Date            : 2014-03-31
>
>         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.
>
>
>         The IETF datatracker status page for this draft is:
>         https://datatracker.ietf.org/__doc/draft-johnston-tram-stun-__origin/
>         <https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/>
>
>         There's also a htmlized version available at:
>         http://tools.ietf.org/html/__draft-johnston-tram-stun-__origin-02 <http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02>
>
>         A diff from the previous version is available at:
>         http://www.ietf.org/rfcdiff?__url2=draft-johnston-tram-stun-__origin-02
>         <http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-02>
>
>
>         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>
>         <http://tools.ietf.org>.
>
>
>         Internet-Drafts are also available by anonymous FTP at:
>         ftp://ftp.ietf.org/internet-__drafts/
>         <ftp://ftp.ietf.org/internet-drafts/>
>
>         _________________________________________________
>         I-D-Announce mailing list
>         [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/__listinfo/i-d-announce
>         <https://www.ietf.org/mailman/listinfo/i-d-announce>
>         Internet-Draft
>         <https://www.ietf.org/mailman/__listinfo/i-d-announce
>         <https://www.ietf.org/mailman/listinfo/i-d-announce>
>
>         Internet-Draft> directories: http://www.ietf.org/shadow.__html
>         <http://www.ietf.org/shadow.html>
>         or ftp://ftp.ietf.org/ietf/__1shadow-sites.txt
>         <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>
>
>     --
>     Brandon Williams; Senior Principal Software Engineer
>     Emerging Products Engineering; Akamai Technologies Inc.
>
>     _________________________________________________
>     tram mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/tram
>     <https://www.ietf.org/mailman/listinfo/tram>
>
>