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

From: Brandon Williams <[email-masked]>
Date: Fri, 04 Apr 2014 17:20:52 -0400

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, 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: ** <[email-masked] <mailto:[email-masked]>>
> Date: Mon, Mar 31, 2014 at 4:40 PM
> Subject: I-D Action: draft-johnston-tram-stun-origin-02.txt
> To: [email-masked] <mailto:[email-masked]>
>
>
>
> 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/
>
> There's also a htmlized version available at:
> 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
>
>
> 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>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft <https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft> directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 4 Apr 2014 16:03:03 -0700

On Apr 4, 2014, at 2:20 PM, Brandon Williams <[email-masked]> wrote:

> 
> 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?

I guess that’s true, this is how it was discussed.

Oleg

---

From: Justin Uberti <[email-masked]>
Date: Fri, 4 Apr 2014 17:05:04 -0700

On Fri, Apr 4, 2014 at 2:20 PM, Brandon Williams <
[email-masked]> 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.
>
> 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
>
>
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Brandon Williams <[email-masked]>
Date: Sun, 06 Apr 2014 19:03:09 -0400

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
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Alan,
>
>     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
>     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
>
>
>         From: ** <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         Subject: I-D Action: draft-johnston-tram-stun-__origin-02.txt
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>
>
>                   Filename        : draft-johnston-tram-stun-__origin-02.txt
>                   Pages           : 10
>                   Date            : 2014-03-31
>
>         Abstract:
>         https://datatracker.ietf.org/__doc/draft-johnston-tram-stun-__origin/
>         <https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/>
>
>         http://tools.ietf.org/html/__draft-johnston-tram-stun-__origin-02 <http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02>
>
>         http://www.ietf.org/rfcdiff?__url2=draft-johnston-tram-stun-__origin-02
>         <http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-02>
>
>
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>
>         <http://tools.ietf.org>.
>
>
>         ftp://ftp.ietf.org/internet-__drafts/
>         <ftp://ftp.ietf.org/internet-drafts/>
>
>         _________________________________________________
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         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>
>
>
>     --
>     _________________________________________________
>     tram mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/tram
>     <https://www.ietf.org/mailman/listinfo/tram>
>
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Apr 2014 10:00:07 -0400

> unallocated value in an I.D.

+1

This is more important than it may seem.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Alan Johnston <[email-masked]>
Date: Mon, 7 Apr 2014 09:17:48 -0500

As we say in the draft, if it is adopted as a WG item, we will do whatever
the chairs think is best.  I suspect we could finish the draft in the same
amount of time as an RFC 4020 action.

I would also point out that we did use a TBD value in the first version of
the draft to make sure that that was interest.  We put in the value in the
next revision after we had interest in having running code.

- Alan -

On Mon, Apr 7, 2014 at 9:00 AM, Simon Perreault <[email-masked]
> wrote: