Subject: [midcom] STUN update time proposals

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 30 Jul 2002 16:01:32 -0700

I waited until after last call to mention this because I do not think they
should hold up the current stuff but it might be a reasonable extension.

Add an optional tag that the STUN server can return that indicates an upper
bound on how long the NAT binding is valid without an update. This will be
useful for the clients trying to discover the length of time the binding in
the NAT stay valid.

The STUN server never knows all the NATs in the path but it may know one of
the NATs and how it is configured. From this it may know how long that
particular NAT will keep in the binding open without an update. Other NATs
in the path may have shorter times. This is why the client must consider
this an upper bound on the time not the actual time.

Cullen

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 Jul 2002 22:26:39 -0400

This came up during the Minneapolis IETF, as I recall.

I feel its not a good thing to do. The reason is that its fundamental to 
the model that STUN is not processed by NAT. What you are proposing only 
makes sense in the model where STUN *is* understood and processed by 
NAT. I am worried about the potential for abuse, security problems, and 
so on, since the protocol is not designed for that. I would rather 
pursue such avenues in the tist/nsis framework, as thats what its meant for.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 30 Jul 2002 21:56:05 -0700

I was not thinking of the NAT modifying the STUN message. The option would
be protected by the signature in the STUN response so it would fail if the
NAT modified it.

I was imagining a scenario more along the following lines. A large cable ISP
has a large NAT that NATs all of it's customers. It also is very nice and
runs a SMTP server and STUN server for all of it's (and only it's)
customers. Additionally, each customer might run a second NAT at their home
so they can connect multiple computers for the price of one. The ISP knows
that their large NAT keeps binding up for 5 minutes. They configure this
into their STUN server. This stun server is guaranteed by ACL to only accept
responses from customers of the ISP that are behind this NAT.

This helps the client short circuit the times that they need to search
because they can start at 5 minutes and binary divide from there. The client
can't just blindly use 5 minutes because it has no idea what the NAT in the
home is and might be less than this.

If the STUN server served the internet as a whole it would not be possible
to add this option because the server would not know anything about the NAT
that might in the path.

I only have vague recollection of why we discarded it in Minneapolis. I
completely agree that moving to a point were the NAT needs to some how
understand STUN completely defeats the purpose of doing STUN in the first
place - I'm not advocating that at all. TIST seems like a far more
interesting way of discovering the minimal time of any middle box in the
path.

Cullen

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2002 7:27 PM
> To: Cullen Jennings
> Cc: Midcom
> Subject: Re: [midcom] STUN update time proposals
>
>