Subject: [Ietf-behave] rfc3489bis-04 available

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Jul 2006 15:07:28 -0700 (PDT)

A few folks commented to me that they never saw rfc3489bis-04 appear in 
the I-D announcements. Thats because I missed the deadline :(

However, I did finally finish -04, and I've posted it on my website. 
I'll submit it during IETF week once the blackout period ends. You can 
pick it up right now at:

http://www.jdrosen.net/papers/draft-ietf-behave-rfc3489bis-04.txt

Mostly this revision was about completing the concept of a base 
specification and the various usages. However, there is some new stuff 
in here. The full set of changes is:

* changed protocol name to Simple Traversal Underneath NAT - same
acronym, but reflects fact that even binding requests now run over tcp
* fixed the major bug on attribute lengths not being byte aligned. The
solution in the document is that, if an attribute value is not a
multiple of four bytes, you pad to a multiple of four, and then the
length refers to the length *prior* to padding. This IS backwards
compatible with rfc3489, since it required attributes to be 32 bit
aligned. However it is not forward compatible, but nothing would be
for values that are not 32 bit aligned.
* massive cleanup on introduction

* added notion of tcp transactions failing if there is no response
whatsoever after 9500ms.
* added notion of indications failing due to icmp errors, allowed to
retry on a different server just like requests
* removed redundant message number allocations for shared secret
requests/responses/error
* SRV processing is now per my proposal in Dallas. There is an SRV
usage for the binding discovery with the service name "stun" and one
for password determination called "stun-pass" (previously
stun-tls). The transport protocol can be udp, tcp or tls for the
binding discovery, and only tls for stun-pass. There is no NAPTR
defined. Recommending that other stun usages that require dns service
names have them start with "stun". Default port is 3478 for ALL usages
if there is no SRV record, but only for tcp/udp. No default for
TLS. This will require STUN server to have separate ports in DNS for
tcp and tcp/tls. Note however that the tcp/tls port can be shared
across different application usages (i.e., shared secret and binding
discovery both of which can run over tls).
* added more detailed procedures for TLS, on verifying certificates
and baseline ciphersuite
* lots more details on the authentication procedures, including detailed
client behaviors for each response code, specific nonce handling
procedures, linkages into the stun usage, clear handling for the two
different types of credentials. A fallout of this update is the
indications can be authenticated using short-term credentials, since
those don't require challenges. This might come in handy in the
future.
* added Adam's proposed text on computation of the key for the HMAC,
and clarified that the binary output of the md5 hash is used
* removed XOR-ONLY remnants, removed REALM from table of attributes
applicable to success responses. Add indication messages to table of
attributes
* removed RESPONSE-ADDRESS, CHANGED-ADDRESS, CHANGE-REQUEST,
SOURCE-ADDRESS, REFLECTED-FROM
* 500 response can trigger client to try request on a different server
if the server was found through DNS SRV. 600 responses should never
trigger a retry on another server
* removed open issue about XOR-MAPPED-ADDR including the port: better
safe than sorry
* renamed BINDING-LIFETIME to REFRESH-INTERVAL and better defined its
usage and motivation
* for binding discovery usage, spceify that if a client isn't
explicitly configured with the hostname of a stun server, it justs the
domain portion of the AOR in the SRV processing. This allows for
discovery of stun servers with sip as long as the client knows its
AOR.
* for short-term password usage, authentication of Shared Secret
request is possible using long-term password now. Added in needed
details on server processing, construction of username and password,
and security considerations.
* ALTERNATE-SERVER code is 0x8023 (was listed twice before)

* updated security considerations and IAB considerations to reflect
split into usages
* changed stale nonce error code from 437 to 438 to avoid conflict
with turn
* added FINGERPRINT attribute to facilitiate in STUn demux. It is a
SHA-1 hash of the STUN message, without any kind of shared secret.

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 6 Jul 2006 03:51:36 -0700 (PDT)

Hello,

> retry on a different server just like requests

If IPv6 is to be retained, ICMPv6 should be added.

There is however, IMHO, one big open issue with allowing STUN over IPv6: in 
case involving DNS SRV queries, the document defines no guidelines as to how 
the STUN servers should be deployed wrt the two IP versions, and/or how 
dual-stack STUN clients should handle a STUN server that would have both AAAA 
and A record.

it is my understanding that applying standard RFC 3493-ish getaddrinfo() 
iteration would be highly suboptimal: in the (more and more common nowadays) 
case of a dual-stack host with a public IPv6 address and a private NATed IPv4 
address, we'd most likely end up with STUN returning the public IPv6 mapping. 
That mapping would be the same as the internal transport socket address on 
the client. That means not only that STUN would be quite redundant, but that 
it would fail to return useful informations if the client later tries to 
contact an IPv4 only node.

An obvious solution would be to query either AAAA or A records only based on 
the address family that the clients wishes to use. Unfortunately, this does 
not work because of the NAT-PT-style support that is now explicitly added 
into STUN.

So the only (slow and complicated) solution seems to be to perform STUN 
binding allocation for both IPv4 and IPv6 in any case, whenever both the 
client and the server are operating dual-stack. Because this is far from 
obvious, I think it should definitely be discussed and referred to in the new 
STUN spec (regardless of what ICE does/does not do - that's separated).

> * (...) other stun usages that require dns service
> names have them start with "stun".

It should probably be "stun-" for the sake of readability and consistency 
with "stun-pass".

On page 18, "8.1as" should be "8.1 as".

Unless it breaks backward compatibility, the first byte of MAPPED-ADDRESS 
might rather have to be zeroed when sending, and ignored on receival, the 
same way most other IETF protocols defines undefined bits. Same remarks wrt 
XOR-MAPPED-ADDRESS (which has no backward compat. consideration).

-- 
Rémi Denis-Courmont <Remi.Denis-Courmont@xxxxxxxxx>
Assistant Research Engineer

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 6 Jul 2006 05:46:41 -0700 (PDT)

Hi Jonathan,

Some comments on this draft:

o Section 8.3.1:

The 2nd procedure says about short term credential that "The message
would not contain the NONCE attribute." But paragraph 7 says that "The
NONCE is included in the request only if a short or long term credential
is being used..."

o Section 12.1.1.11.9, paragraph 10:

"That allows the server to meet the requirements specified in section
8.1 for constructing the REFLECTED-FROM attribute."

As this attribute no longer exist, I thing this sentence should be removed.

o Section 15.2:

The RESPONSE-ADDRESS attribute is no longer used and should be removed.

The INTEGRITY and BINDING-LIFETIME attributes are missing.

Some nits:

o Section 6, paragraph 12:

"...that they are a multiple of 4 btyes."

o Section 8.3.2, paragraph 4:

"If the REALM attribute was absent in the resposne..."

o Section 9.1.1, paragraph 9:

"...an error response with an ERROR-CDE..."

o Section 9.1.2, paragraph 3:

"...carrying the souce IP address..."

o Section 11.12, paragraph 2:

"This attribute is MUST only appear..."

o Section 11.13, paragraph 1:

"The REFRESH-INTERVAL provies..."

o Section 12.1.1.9.1, paragraph 1:

"...are viable for direct communciations."

o 12.1.1.9.3, paragraph 1:

"...because it signalsed..."

-- 
Marc Petit-Huguenin
Home: marc@xxxxxxxxxxxxxxxxxx
Work: marc@xxxxxxx

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 6 Jul 2006 07:48:51 -0700 (PDT)

Folks,

I have taken the liberty of numbering this as issue #1 for TCP, purely for the
sake of tracking. That is not to say, there are no prior issues. We just have
to start somewhere for tracking by number. Thanks. Anyways, below is the issue
with the latest rev of the TCP draft. 

A new requirement (Req-9) was added to the latest TCP draft
(draft-ietf-behave-tcp-01.txt) that overlaps ICMP requirement(s). The
requirement was pretty much lifted from the UDP draft (REQ-12 and Req-12. For
some reason, REQ-12b was dropped). I raised the issue with regard to repeating
ICMP requirements in the protocol drafts during the IESG review of the UDP
draft. But, UDP draft was an exception because it was the first draft and folks
wanted to get the UDP RFC out soon.  I believe, it would be a bad precedent to
repeat ICMP requirements in the TCP draft. ICMP draft is a WG draft now. I
donot see why the ICMP requirements should be repeated in the TCP draft, and
other future protocol drafts. I believe, protocol drafts (TCP and onwards)
ought to simply refer the ICMP draft for ICMP requirements unless there is a
specific exception.

Below is REQ-9 from the TCP draft.

      REQ-9: Receipt of any sort of ICMP message MUST NOT terminate the NAT
      mapping or TCP connection for which the ICMP was generated.
      a) The NAT's default configuration SHOULD NOT filter ICMP messages
         based on their source IP address.

REQ-4 and REQ-5 of the ICMP draft state the requirements for forwarding ICMP
error messages. These ICMP reeuirements overlap with REQ-9a above from the TCP
draft. REQ-6  of the ICMP draft directly overlaps with the first sentence of
REQ-9 from the TCP draft. Below is REQ-6 from the ICMP draft.

   REQ-6: While processing an ICMP error packet, a NAT device MUST NOT 
   refresh or delete the NAT Session that pertains to the embedded
   payload within the ICMP error packet.

cheers,
suresh