Subject: Re: [midcom] STUN update time proposals

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Aug 2002 05:20:39 -0400

[resending as I think this was lost due to ietf.org mail outage]

Sorry for the delayed response. "real work" swamped me for a couple
weeks. Trying to get my head back above water now.

inline.

Cullen Jennings wrote:
 > 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.

It sounds like what you are suggesting is that the stun server could
provide a hint to the client about what it thinks the nat binding
lifetime might be.

I still have concerns with this. Generally speaking, the model with STUN
is that STUN servers are decoupled from the NATs; they don't know where
they are, what they are, or what their configuration is. If you want to
change this model, it really leads to a different protocol and set of
features. After all, why stop at binding lifetimes? Why not "hint" to
the client about the type of nat as well? As a scope thing, I'd rather
stick with the current model where they are totally decoupled.

Related to this, the hints don't help that much since they are just
hints. They could easily be wrong, due to inconsistent configuration
between the stun server and nat. Also, the stun server can't know for
certain that the clients contacting it are coming through the NATs it
knows about. Correctness of the hint is therefore strongly coupled with
network topology. It seems like it will be very error prone. In any
case, there can always be other nats, so it can never be anything more
than a starting point in a binary search, not even really a hint about
what the overall binding lifetime is amongst all NATs. Thus, the value
in the information is actually low, and given the possibility of it
being error prone, I am inclined not to include it.

-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

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

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 22 Aug 2002 09:23:24 -0700

> stick with the current model where they are totally decoupled.

I agree with Jonathan. We must keep the STUN service simple. The primary
usage is to get a mapping shortly before a session, i.e. a period of
sustained traffic between two hosts. In that primary usage, the lifetime
of the mapping does not matter much: we know by experience that it is
always >= 1 minute, i.e. enough for session set-up; we also know that
sustained traffic effectively prevents the mapping from disappearing.

> being error prone, I am inclined not to include it.

Yes. If you want to go beyond the simple "map before a session" model,
then you must be concerned with the exact binding algorithm used in the
NAT. You have to consider corner cases, such as dial-up and ISDN
connections, in which the mapping itself can be maintained for a long
time, but the connection may be dropped if no traffic is observed for
some period, introducing a coupling between the mapping and the amount
of traffic in other sessions; when the node dials back, it may or may
not come back with the same address. 

In the case that Cullen mentions, a large cable ISP with a large NAT,
the ISP could just as well publish that it adheres to some recommended
lifetime guarantee, say 3 minutes.

-- Christian Huitema