Subject: [Ietf-behave] minimal STUN server

From: Jon Ringle <[email-masked]>
Date: Thu, 21 Oct 2004 11:04:18 -0700 (PDT)

Hello,

It seems to me that the algorithm that STUN uses to discover the NAT type is 
not as useful and brittle especially when behind a non-deterministic NAT. 
This sentiment seems to be reflected in draft-rosenberg-rfc3489bis-00. As 
such, it also seems to me that some of the requirements needed for a STUN 
server can be made optional. In particular, the requirement that a Bind 
response MUST have a CHANGED-ADDRESS attribute doesn't make sense when a STUN 
server will only be used for it's reflective property to learn about a NAT 
binding. Could I suggest that the Bind response MAY or SHOULD have a 
CHANGED-ADDRESS attribute. A STUN client that wishes to use a STUN server for 
the purpose of NAT type classification could use the presence or absence of 
the CHANGED-ADDRESS attribute in the Bind response to determine if this STUN  
server is capable of being used for NAT classification.

This would reduce the resource requirements of a STUN server. It would also 
make ICE peer STUN server a compliant implementation.

Jon

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 8 Nov 2004 21:06:49 -0800 (PST)

inline.

Jon Ringle wrote:

Hello,

It seems to me that the algorithm that STUN uses to discover the NAT type is 
not as useful and brittle especially when behind a non-deterministic NAT. 
This sentiment seems to be reflected in draft-rosenberg-rfc3489bis-00.
Right.

As 
such, it also seems to me that some of the requirements needed for a STUN 
server can be made optional. In particular, the requirement that a Bind 
response MUST have a CHANGED-ADDRESS attribute doesn't make sense when a STUN 
server will only be used for it's reflective property to learn about a NAT 
binding. Could I suggest that the Bind response MAY or SHOULD have a 
CHANGED-ADDRESS attribute. A STUN client that wishes to use a STUN server for 
the purpose of NAT type classification could use the presence or absence of 
the CHANGED-ADDRESS attribute in the Bind response to determine if this STUN  
server is capable of being used for NAT classification.
I think something like this makes sense. I'm not sure I would do it this 
way, since I think it could lead to interop problems. How would we make 
sure that "regular" stun servers (as opposed to those listening on RTP 
or SIP ports as in ICE and the sipping outbound connection draft) 
include the CHANGED-ADDRESS attribute?

As such, I'd propose to flip it around. The client could include 
something in its request which says, "hey, I don't need to do the 
detection, so don't bother to include CHANGED-ADDDRESS in the response".

A server in a specialized environment where we have a way to say that 
clients which use it, would always say that they don't need 
CHANGED-ADDRESS, could not bother to use it.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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: Jon Ringle <[email-masked]>
Date: Tue, 9 Nov 2004 07:51:22 -0800 (PST)

Inline.

On Tuesday 09 November 2004 12:06 am, Jonathan Rosenberg wrote:
> Jon Ringle wrote:
> > it also seems to me that some of the requirements needed for a STUN
> > response MUST have a CHANGED-ADDRESS attribute doesn't make sense when a
> > STUN server will only be used for it's reflective property to learn about
> > a NAT binding. Could I suggest that the Bind response MAY or SHOULD have
> > a CHANGED-ADDRESS attribute. A STUN client that wishes to use a STUN
> > server for the purpose of NAT type classification could use the presence
> > or absence of the CHANGED-ADDRESS attribute in the Bind response to
> > determine if this STUN server is capable of being used for NAT
> > classification.
>

If a STUN server supports a set of alternate addresses A1:P1, A1:P2, A2:P1, 
A2:P2 (where A1 != A2 and P1 != P2) that server MUST advertised this fact by 
sending the CHANGED-ADDRESS attribute in the BindingResponse. This is how you 
make sure that "regular" stun servers will continue to work.

If a STUN server does not support alternate addresses it MUST not include a 
CHANGED-ADDRESS attribute in the BindingResponse. This should cause the 
desired failure of STUN clients that are expecting the CHANGED-ADDRESS 
attribute, since a STUN client that is doing NAT classification cannot do so 
without the information provided by CHANGED-ADDRESS.

> CHANGED-ADDRESS, could not bother to use it.

I think doing this is overkill, an unnecessary.

I also just noticed that the -03 ICE draft says: "The CHANGED-ADDRESS 
attribute in a BindingResponse is set to the transport address on which the 
server is running." I presume that you are suggesting in this draft that the 
STUN server running on an ICE endpoint should set A2:P2 such that A2==A1 and 
P2==P1. The problem I see with this approach is that if this behaviour is 
placed upon a "regular" STUN server, then a STUN client using this STUN 
server for NAT classification may not notice that A1==A2, P1==P2. This could 
result in the misclassification of a NAT. Most NATs would probably appear to 
this STUN client to look like Full Cone.

Jon