Subject: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03

From: Fredrik Thulin <[email-masked]>
Date: Fri, 10 Mar 2006 06:34:51 -0800 (PST)

Hi

I have some comments on draft-ietf-behave-rfc3489bis-03. For me, who 
don't know RFC3489, some of these comments are on stuff that 
seems to be just plain errors where I have no idea what the correct 
text would be.

  7.1.  Request Transaction Reliability

        "If a failure occurs and the SRV query
         indicated other STUN servers are available,"

DNS SRV querying for STUN servers haven't been defined/explained at this 
point in the document.

  15.1.  STUN Message Type Registry

        0x0002  :  Shared Secret Request
        0x0102  :  Shared Secret Response
        0x0112  :  Shared Secret Error Response
        0x0002  :  Shared Secret Request
        0x0102  :  Shared Secret Responsed
        0x0112  :  Shared Secret Error Response

three duplicate types

  15.2.  STUN Attribute Registry

        0X0005: CHANGED-ADDRESS
         ^ nit: capital X in this one

        0x000E: ALTERNATE-SERVER
        0x8023: ALTERNATE-SERVER

which one is erroneous? If they are actually just two values for the 
same thing, then I have missed the text explaining that.

  11.  STUN Attributes

               XOR-ONLY             O        -         -

What is XOR-ONLY? This is the only occurance of XOR-ONLY in the whole 
document.

  11.8.  MESSAGE-INTEGRITY
        However, STUN
   clients MUST be able to successfully parse and process STUN messages
   which have additional attributes after the MESSAGE-INTEGRITY
   attribute.  STUN clients that are compliant with this specification
   SHOULD ignore attributes that are after the MESSAGE-INTEGRITY
   attribute.

Isn't it contradictory to say that clients should a) parse and process, 
and b) ignore attributes after the MESSAGE-INTEGRITY attribute?

  11.11.  ALTERNATE-SERVER

   The alternate server represents an alternate IP address and port for
   a different TURN server to try.  It is encoded in the same way as
   MAPPED-ADDRESS.

TURN server? What TURN server? Is this perhaps related to my question 
above about the duplicate ALTERNATE-SERVER attributes?

  12.5.3.  Server Determination of Usage

        ...
   For example, the server could advertise

The example is missing.

  13.2.3.  Approach III: Rogue Router or NAT

      Todo:  RESPONSE-ADDRESS has been removed from this version of the
      specification.  Reword or remove above paragraph accordingly.

It might be true that none of the usage describing paragraph includes 
the RESPONSE-ADDRESS, but section 11.12 is still there so someone might 
implement it by mistake.

/Fredrik

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 10 Mar 2006 09:17:33 -0800 (PST)

> seems to be just plain errors where I have no idea what the correct 

Thanks for your review.  Comments inline.

> DNS SRV querying for STUN servers haven't been 
> defined/explained at this point in the document.

I can add a forward reference.  I'll fix that in -04.

>         0x0112  :  Shared Secret Error Response

Editing error, thanks for catching that.  I'll fix this in -04.

> same thing, then I have missed the text explaining that.

0x000e is correct.  I'll fix this in -04.

> What is XOR-ONLY? This is the only occurance of XOR-ONLY in the whole 

XOR-ONLY was in rfc3489bis-02 (and earlier version), and was how a STUN
client asked to _not_ get a MAPPED-ADDRESS.  In -03, we changed how the STUN
client and STUN server determine if a MAPPED-ADDRESS or an
XOR-MAPPED-ADDRESS is returned so that XOR-ONLY is no longer necessary.

This latent XOR-ONLY is a mistake and will be removed in -04.  Thanks.

> and b) ignore attributes after the MESSAGE-INTEGRITY attribute?

The text should be more clear; the intent is that STUN clients (and servers,
actually) be able to parse and process the portion of the message protected
by MESSAGE-INTEGRITY, but also to not get upset if there happens to be
additional STUN attributes after the MESSAGE-INTEGRITY attribute.  Any
attributes which appear after MESSAGE-INTEGRITY are ignored.  We want this
for extensibility.

I will clarify that sentence in -04.  Thanks.

> above about the duplicate ALTERNATE-SERVER attributes?

Sorry, I pulled that text from the TURN document and neglected to generalize
it.  Please note that the ALTERNATE-SERVER attribute isn't used in any of
the usages defined in RFC3489bis; the only usage that currently uses that
attribute is TURN (draft-ietf-behave-turn-00.txt).  

I will generalize that text so that instead of saying TURN it says "for a
different STUN server to try."

>    For example, the server could advertise

Thanks for catching that.  I will add an example in -04.

> the RESPONSE-ADDRESS, but section 11.12 is still there so 
> someone might implement it by mistake.

Yes, that's true.  That's why we have an Issue raised in the document:

      Issue:  should this attribute be made specific to Binding
      Discovery or moved to another document entirely.

for the RESPONSE-ADDRESS, CHANGED-ADDRESS, CHANGE-REQUEST, SOURCE-ADDRESS,
and REFLECTED-FROM attributes.  Those five attributes are only useful if a
STUN client is attempting to determine the 'type' of NAT it is behind.  In
RFC3489 four types of NATs were defined (see section 5 of RFC3489).  This
was known at the time to be brittle.  Since then we have found it not useful
to know what kind of NAT you're behind.

The authors haven't reached consensus about what to do with these five
attributes.  We will be asking the BEHAVE WG to help decide if those five
attributes stay in the document somehow (perhaps with strict warnings to not
implement them) or are removed from the document entirely (and maybe placed
into another document or just allowed to exist in RFC3489).  There are
issues with backwards compatibility with removing them outright, and the
issue you raised with leaving them in (such as someone inadvertantly and
unnecessarily implementing support for these attributes).

Thanks again for your detailed review of this document.
-d

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 15 Mar 2006 04:45:17 -0800 (PST)

Hi

Thank you very much for your response. I have one clarifying question, 
and two additional comments =) (see below).

On Friday 10 March 2006 18:17, Dan Wing wrote:
...
> >    a different TURN server to try.  It is encoded in the same way
> > as MAPPED-ADDRESS.
> >
> > TURN server? What TURN server? Is this perhaps related to my
> > question above about the duplicate ALTERNATE-SERVER attributes?
>
> Sorry, I pulled that text from the TURN document and neglected to
> generalize it.  Please note that the ALTERNATE-SERVER attribute isn't
> used in any of the usages defined in RFC3489bis; the only usage that
> currently uses that attribute is TURN
> (draft-ietf-behave-turn-00.txt).
>
> I will generalize that text so that instead of saying TURN it says
> "for a different STUN server to try."

I'm still a bit confused about this. There are two sub-sections to 
section 11 that describe ALTERNATE-SERVER attributes (11.11 and 11.17).

Are you saying that 11.11 should really read ALTERNATE-TURN-SERVER or 
something? From an extremely brief look at draft-ietf-behave-turn-00, I 
don't find any such attribute there.

New comments :

  11.15.  XOR-MAPPED-ADDRESS

The example results for IPv4 is really helpfull. I think it would be 
very valuable to have such examples for IPv6 as well, to make sure 
everyone gets this right as well. By the way, I haven't been able to 
find a IPv6 capable STUN client to try my server with, does anyone know 
of one?

Section 11 says that attributes MUST be aligned to word boundaries, and 
for example section 11.9 (ERROR-CODE) describes how pad with spaces to 
accomplish this with the reason phrase in errors.

I can't find anything in the following sections that describe how to 
align those attributes :

        11.6.  USERNAME
        11.7.  PASSWORD
        11.12.  REALM
        11.13.  NONCE
        
Sections 11.6 and 11.7 even says the value is of variable length. Surely 
they must be encoded aligned to word boundries in some way?

/Fredrik

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 15 Mar 2006 16:30:49 -0800 (PST)

> something?

No, just ALTERNATE-SERVER.

There is no reason for a STUN server, using any of the usages defined
in RFC3489bis, to send back an ALTERNATE-SERVER.  And there is no reason
for a STUN client to expect it.  That's why I'm saying the 
ALTERNATE-SERVER attribute isn't used by any usages defined in 
RFC3489bis -- very much like the other latent attributes from RFC3489
that are no longer used by usages defined in RFC3489bis 
(REFLECTED-FROM, SOURCE-ADDRESS, CHANGE-REQUEST, CHANGED-ADDRESS,
RESPONSE-ADDRESS).

> From an extremely brief look at draft-ietf-behave-turn-00, I 

Right; it is no longer defined in TURN.  ALTERNATE-SERVER was in the
immediately-preceeding version of TURN
<http://www.watersprings.org/pub/id/draft-rosenberg-midcom-turn-08.txt>.  

Jonathan and I wanted all of the general stuff, which is applicable to a
variety of usages, to be in the base STUN specification (RFC3489bis).
ALTERNATE-SERVER seems like it could very much be useful for other usages,
not just TURN.  So we pulled it out of TURN and put it into RFC3489bis.

As both RFC3489bis and TURN are documents of the BEHAVE working group, we
are seeking consensus on this change.  We will be presenting these changes
at the WG meeting.  Feedback regarding this change (and our other changes)
on the mailing list (or at meeting) is helpful.

> everyone gets this right as well. 

Alright.

> By the way, I haven't been able to 
> find a IPv6 capable STUN client to try my server with, does 
> anyone know of one?

Gonzalo co-authored draft-camarillo-midcom-turn-ipv6-00.txt so he may know
of one, <Gonzalo.Camarillo@xxxxxxxxxxxx>.

> they must be encoded aligned to word boundries in some way?

RFC3489 defined USERNAME and PASSWORD but also failed to describe this
situation.

Hm.  My first reaction is that the USERNAME, PASSWORD, and NONCE are all
computer generated -- that is, they have no relationship to the username or
password you use for authentication (by typing a username into a keyboard,
for example).  Thus, those can all reasonably be required to just be a
multiple of 32 bits long.  I can add text to that effect in -04 if folks
concur.

The REALM might reasonably be a string such as "cisco.com", though, and I
agree it needs a standard for aligning it.  Perhaps use should use spaces
like with the error codes just for consistency, or maybe pad with 0x00.

-d

---

From: Justin Uberti <[email-masked]>
Date: Wed, 15 Mar 2006 17:24:24 -0800 (PST)

I thought that with the new support for long-term passwords in TURN,
this might not be the case for USERNAME.

I was thinking we would use spaces for REALM and USERNAME, for
consistency.

Thanks,
--justin

---

From: Aki Niemi <[email-masked]>
Date: Sun, 19 Mar 2006 14:44:09 -0800 (PST)

> find a IPv6 capable STUN client to try my server with, does anyone know 

Hmm... Why would you need to get an IPv6 address in MAPPED-ADDRESS
anyway? This makes me feel very uneasy; is the purpose to be able to
traverse a NAT-PT that maps private IPv4 to IPv6? That's not cool.

Cheers,
Aki

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 19 Mar 2006 20:33:49 -0800 (PST)

> traverse a NAT-PT that maps private IPv4 to IPv6? That's not cool.

STUN has many uses, and only one of them (Binding Discovery) is is 
useful for learning your NATted IP address.  One of its other 
significant uses is the connectivity check which is now defined 
in rfc3489bis-03.  The connectivity check is used by ICE 
(draft-ietf-mmusic-ice).  Another significant use is TURN
(media relaying) where the media might be relayed between v4 
and v6.

See also draft-ietf-sipping-v6-transition-02.txt which describes
how ICE is useful in a mixed v6/v4 environment.

-d