Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt

From: [email-masked]
Date: Thu, 08 Mar 2007 15:50:03 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title		: Session Traversal Utilities for (NAT) (STUN)
	Author(s)	: J. Rosenberg, et al.
	Filename	: draft-ietf-behave-rfc3489bis-06.txt
	Pages		: 61
	Date		: 2007-3-8
	
Session Traversal Utilities for NAT (STUN) is a lightweight protocol
   that serves as a tool for application protocols in dealing with NAT
   traversal.  It allows a client to determine the IP address and port
   allocated to them by a NAT and to keep NAT bindings open.  It can
   also serve as a check for connectivity between a client and a server
   in the presence of NAT, and for the client to detect failure of the
   server.  STUN works with many existing NATs, and does not require any
   special behavior from them.  As a result, it allows a wide variety of
   applications to work through existing NAT infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-behave-rfc3489bis-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-behave-rfc3489bis-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 08 Mar 2007 22:52:31 +0100

Hi

thanks for this update. I noticed that this version of the draft
is almost identical to bis05?

my major comment is:

    The initial STUN Attributes are:

     0x8023: FINGERPRINT
     0x8022: SERVER
     0x8023: ALTERNATE-SERVER
     0x8024: REFRESH-INTERVAL

FINGERPRINT and ALTERNATE-SERVER values are conflicting.

additional comments from bis05 review attached.

/alfred

[email-masked] wrote:
> ------------------------------------------------------------------------
> 

Comments on draft-ietf-behave-rfc3489bis-06

> Section 11.13 REFRESH-INTERVAL
>
>    that are being used for keepalives.  The REFRESH-INTERVAL provies a
>                                                              ^^^^^^^

typo - should be "provides"

> Section 11.13 REFRESH-INTERVAL
>
>   represents an interval measured in millseconds.  It can be present in
>                                      ^^^^^^^^^^^

typo - should be "milliseconds"

> Section 9.1.1.  Receive Request Message
>
>    generate an error response which includes an ERROR-CORE attribute
>                                                 ^^^^^^^^^^

typo? I think this should be "ERROR-CODE"..

> Section 15.2.  STUN Attribute Registry
>
>     0x8023: FINGERPRINT
>     0x8022: SERVER
>     0x8023: ALTERNATE-SERVER
>     0x8024: REFRESH-INTERVAL

it seems like the FINGERPRINT and ALTERNATE-SERVER have got
the same value (0x8023) ?
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 09 Mar 2007 16:49:51 -0500

inline.

> is almost identical to bis05?

Yes, unfortunately. See my other note to behave on this.

> FINGERPRINT and ALTERNATE-SERVER values are conflicting.

Right. I've moved FINGERPRINT to 0x8028. I think this happened because 
fingerprint used to be in the mandatory range and we had to move it into 
the optional one in -05. Looks like 0x8026 and 27 were taken by the 
discovery usage, so I grabbed 0x8028.

> additional comments from bis05 review attached.

I've now addressed them in my working -07.

Thanks for your patience,
Jonathan R.

>> the message. You can also visit 
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
>> subscription settings.
>>
>> logging in, type "cd internet-drafts" and then "get 
>> draft-ietf-behave-rfc3489bis-06.txt".
>>
>> http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 9 Mar 2007 16:55:12 -0800

Jonathan,

http://www.employees.org/behave/stun-attributes.html has been updated
accordingly.

-d

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Friday, March 09, 2007 1:50 PM
> To: Alfred E. Heggestad
> Cc: [email-masked]
> Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt
> 
> inline.
> 
> >> This draft is a work item of the Behavior Engineering for 
> Hindrance 
> >> Avoidance Working Group of the IETF.
> >>

---

From: "Gentry, Mark" <[email-masked]>
Date: Mon, 12 Mar 2007 12:52:39 -0400

Jonathan,

Possible inconsistency:

Should XOR-MAPPED-ADDRESS be in the mandatory range?  I probably
wouldn't ask except that v0.96 of the Vovida STUN server uses 8020h
instead of 0020h for XOR-MAPPED-ADDRESS and Wireshark "recognizes" 8020h
(not sure about 0020h) as XOR-MAPPED-ADDRESS. 

-Mark Gentry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Friday, March 09, 2007 7:55 PM
To: 'Jonathan Rosenberg'; 'Alfred E. Heggestad'
Cc: [email-masked]
Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt

Jonathan,

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Mar 2007 12:07:18 -0700

Regarding Wireshark, 0x8020 was used for XOR-MAPPED-ADDRESS in -02 of
rfc3489bis:

  > grep 8020 draft-ietf-behave-rfc3489bis-*.txt
  draft-ietf-behave-rfc3489bis-02.txt:   0x8020: XOR-MAPPED-ADDRESS
  draft-ietf-behave-rfc3489bis-03.txt:      Note:  Version -02 of this
Internet Dr
aft used 0x8020 for this

The XOR-MAPPED-ADDRESS is in the optional range (above 0x7FFF) so that if an
RFC3489bis-compliant server sends it to an old client (that is, a client
compatible with only RFC3489), the old client will accept the response.

Perhaps we could, instead, use the MAGIC-COOKIE to control the server's
behavior and have XOR-MAPPED-ADDRESS be in the mandatory range (which does
seem to make sense, except for how we achieve backwards compatability).

-d

> From: Gentry, Mark [mailto:[email-masked]] 
> Sent: Monday, March 12, 2007 9:53 AM
> To: [email-masked]

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 12 Mar 2007 19:07:15 -0700

> (not sure about 0020h) as XOR-MAPPED-ADDRESS. 

There is two dissectors for STUN in wireshark 0.99.5.  The "STUN"
dissector is for RFC 3489, augmented with
draft-ietf-behave-rfc3489bis-02 and draft-rosenberg-midcom-turn-08.  In
this dissector, XOR-MAPPED-ADDRESS is defined as 0x8020.

The second dissector, named "STUN2", is for
draft-ietf-behave-rfc3489bis-05 and defines XOR-MAPPED-ADDRESS as 0x0020.

More explanations about the reasons for supporting two dissectors for
STUN here:

http://www.wireshark.org/lists/wireshark-dev/200612/msg01633.html

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 13 Mar 2007 20:21:06 -0400

inline:

Actually, that is exactly how it works:

>   If the response is a type which can carry either MAPPED-ADDRESS or
>    XOR-MAPPED-ADDRESS (the Binding Response as defined in this
>    specification meets that criteria), the server examines the magic
>    cookie in the STUN header.  If it has the value 0x2112A442, it
>    indicates that the client supports this version of the specification.
>    The server MUST insert a XOR-MAPPED-ADDRESS into the response,
>    carrying the exclusive-or of the source transport address and magic
>    cookie.  If the magic cookie did not have this value, it indicates
>    that the client supports the previous version of this specification.
>    The server MUST insert a MAPPED-ADDRESS attribute into the response,
>    carrying the souce transport address from the request.  Insertion of
>    either XOR-MAPPED-ADDRESS or MAPPED-ADDRESS happens regardless of the
>    transport protocol used for the request.

So we could put it into the mandatory range I suppose. I can't recall 
why we moved it out of that range in the first place, as I think the 
above text has been there for a while.

Nonetheless, I think its fine as is. I'd rather keep it optional, just 
in case a server does the wrong thing and sends it (or sends both 
MAPPED-ADDRESS and XOR-MAPPED-ADDRESS).

-Jonathan R.