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

From: Alan Johnston <[email-masked]>
Date: Fri, 7 Feb 2014 07:10:49 -0600

All,

We have updated the STUN Origin draft.  We have tried to incorporate all
the feedback we have received to date.

Comments most welcome.

- Alan -

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Feb 6, 2014 at 2:21 PM
Subject: New Version Notification for draft-johnston-tram-stun-origin-01.txt
To: Kundan Singh <[email-masked]>, Alan Johnston <
[email-masked]>, John Yoakum <[email-masked]>, Justin Uberti <
[email-masked]>

A new version of I-D, draft-johnston-tram-stun-origin-01.txt
has been successfully submitted by Alan Johnston and posted to the
IETF repository.

Name:           draft-johnston-tram-stun-origin
Revision:       01
Title:          An Origin Attribute for the STUN Protocol
Document date:  2014-02-04
Group:          Individual Submission
Pages:          9
URL:
http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-01.txt
Status:
https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/
Htmlized:
http://tools.ietf.org/html/draft-johnston-tram-stun-origin-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-01

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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 07 Feb 2014 09:04:42 -0500

> the feedback we have received to date.

I'm a fan of the new text. Very well written.

A nit: please s/URL/URI/g

Thanks,
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: John Selbie <[email-masked]>
Date: Fri, 7 Feb 2014 09:08:17 -0800

One minor nit to add.  Be deliberate on distinguishing between "type" vs.
"value" fields when explaining the new attribute.  The text below
references section 15 of RFC 5389. That section shows the STUN attribute
format with specified fields labeled "type" and "value".  The draft tends
to use the words "type" and "value" interchangeably in the paragraph below.
 It can be inferred by context, but I suggest being more explicit and
consistent with the other attribute definitions in section 15 of 5389. That
is, make sure that "0x802F" is for the "type" field and that the "value"
field is understood to be a string.

Change this text:

   This specification defines a new Attribute to the STUN protocol
   [RFC5389].  The attribute is called ORIGIN and uses the syntax
   defined in Section 15 of [RFC5389].  A STUN Attribute type is a hex
   number in the range 0x0000 - 0xFFFF.  The ORIGIN attribute value is
   0x802F, chosen in the comprehension optional range.

To this:
   This specification defines a new Attribute to the STUN protocol
   [RFC5389].  The attribute is called ORIGIN and uses the syntax
   defined in Section 15 of [RFC5389].  The number used for the this
   in the type field is 0x802F, chosen in the comprehension optional range.
   The value of ORIGIN is a variable-length value.  It MUST contain a
   UTF-8 [RFC3629] encoded sequence of characters less than N bytes.

Where "N" is some reasonable number between up 65535.

jrs

On Fri, Feb 7, 2014 at 6:04 AM, Simon Perreault <[email-masked]
> wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: John Selbie <[email-masked]>
Date: Fri, 7 Feb 2014 12:35:08 -0800

Additionally, one other thing as an implementation note.

STUN attributes are expected to align on 4-byte boundaries.  The way
padding applies to the LENGTH field of each STUN attribute differs between
RFC 3489 and RFC 5389. Explicit attribute padding in RFC 3489 vs implicit
padding between attributes in RFC 5389.

If the length of the ORIGIN value is not a multiple of 4, this may break
compatibility with RFC 3489.  STUN servers written for RFC 3489 may
encounter a parsing error when servicing a binding request from such a
client that includes an ORIGIN attribute with a length not divisible by 4.
(Can't recall what Vovida stund.097 does, but I remember hitting this issue
during the development of stuntman).

This is not a new issue for STUN. Implementers should take note of this
legacy requirement if the server responding to binding requests can not be
assumed to be RFC 5389 compliant. The workaround is to explicitly pad the
string attribute with zero's and have it's length field adjusted
accordingly. There's a presumption with this workaround that the server
treats the attribute bytes as a "C" string and ignores the extra zero bytes
when processing it.

jrs

On Fri, Feb 7, 2014 at 9:08 AM, John Selbie <[email-masked]> wrote:

> On Fri, Feb 7, 2014 at 6:04 AM, Simon Perreault <
> [email-masked]> wrote:
>

---

From: Alan Johnston <[email-masked]>
Date: Fri, 7 Feb 2014 15:51:26 -0500

John,

Appreciate the detailed feedback. We will make sure to clarify and highlight these issues in the next version. 

- Alan -

> On Feb 7, 2014, at 3:35 PM, John Selbie <[email-masked]> wrote:
> 
> STUN attributes are expected to align on 4-byte boundaries.  The way padding applies to the LENGTH field of each STUN attribute differs between RFC 3489 and RFC 5389. Explicit attribute padding in RFC 3489 vs implicit padding between attributes in RFC 5389.
> 
> If the length of the ORIGIN value is not a multiple of 4, this may break compatibility with RFC 3489.  STUN servers written for RFC 3489 may encounter a parsing error when servicing a binding request from such a client that includes an ORIGIN attribute with a length not divisible by 4.  (Can't recall what Vovida stund.097 does, but I remember hitting this issue during the development of stuntman).
> 
> This is not a new issue for STUN. Implementers should take note of this legacy requirement if the server responding to binding requests can not be assumed to be RFC 5389 compliant. The workaround is to explicitly pad the string attribute with zero's and have it's length field adjusted accordingly. There's a presumption with this workaround that the server treats the attribute bytes as a "C" string and ignores the extra zero bytes when processing it.
> 
> jrs
> 
> 
> 
> 
>> One minor nit to add.  Be deliberate on distinguishing between "type" vs. "value" fields when explaining the new attribute.  The text below references section 15 of RFC 5389. That section shows the STUN attribute format with specified fields labeled "type" and "value".  The draft tends to use the words "type" and "value" interchangeably in the paragraph below.  It can be inferred by context, but I suggest being more explicit and consistent with the other attribute definitions in section 15 of 5389. That is, make sure that "0x802F" is for the "type" field and that the "value" field is understood to be a string.
>> 
>> Change this text:
>> 
>>> On Fri, Feb 7, 2014 at 6:04 AM, Simon Perreault <[email-masked]> wrote: