Subject: Re: [BEHAVE] NAT Control STUN Usage

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Feb 2007 10:05:11 +0200

Hi,

On 2007-1-12, at 20:09, ext Dan Wing wrote:
> At the San Diego meeting there were positive comments around this  
> approach.
> Is there interest in moving this work forward?

this document takes STUN in a whole new direction (middlebox control)  
that would probably require a recharter.

Also, the draft says:
>    Unlike some other
>    techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour  
> [Bonjour]),
>    STUN does not interact directly with the NAT.  Because STUN doesn't
>    interact directly with the NAT, STUN cannot request additional
>    services from the NAT such as longer lifetimes (which would reduce
>    keepalive messages).
>
>    This paper describes a mechanism for the STUN client to interact
>    directly with the NAT and request additional services, by using the
>    STUN protocol itself.

For a convincing rechartering argument, it'd be very useful to see a  
discussion on why adding this to STUN is significantly better than  
the myriad of exiting approaches to control middleboxes. In addition  
to the ones mentioned in the draft, at least NSIS and SIMCO also exist.

Lars

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Feb 2007 14:00:53 -0800

> this document takes STUN in a whole new direction (middlebox 
> control) that would probably require a recharter.

I asked Magnus that question offline, and he concurs it doesn't
fit within BEHAVE's existing charter.  

> >    services from the NAT such as longer lifetimes (which 
> >    would reduce keepalive messages).
> >

-01 added a little more information showing advantages of the NAT
Control STUN Usage.  We can add a point-by-point comparison of this
approach versus NSIS, SIMCO (an implementation of MIDCOM), UPnP,
and Bonjour, and ask the community again if there seems to be 
sufficient merit to this approach versus the other protocols for
NAT traversal and NAT control.

-d

---

From: "Eric Cooper" <[email-masked]>
Date: Tue, 27 Feb 2007 15:04:14 -0500

I think there's a lot of value in this draft simply because it allows discovery of multiple levels of NATs.  

I'm specifically interested in knowing the 'public' IP addresses and keep-alive times associated with each NAT.  I think that could be accomplished without attempting to control the keep-alive times in the NATs.

So, it might be possible to skirt charter issues by limiting this draft to 'discovery' functions and not including 'control' functions.

Best Regards,

Eric.

---

From: "David Barrett" <[email-masked]>
Date: Tue, 27 Feb 2007 13:59:32 -0800

I agree this would be great.  I just think it's not what BEHAVE is doing.

BEHAVE is (largely) just specifying what the default configuration should be
for NATs as they come "out of the box".  This is much different than
mandating all NAT vendors build in support for a new control interface.

Despite my massive reservations with UPnP, that seems like a much more
appropriate place to add control functionality (because it already has it),
rather than reinventing an incompatible subset of UPnP under a different
name.

-david

> -----Original Message-----
> From: Eric Cooper [mailto:[email-masked]]
> Sent: Tuesday, February 27, 2007 12:04 PM
> To: Dan Wing; 'Lars Eggert'
> Cc: [email-masked]
> Subject: Re: [BEHAVE] NAT Control STUN Usage
> 
> I'm specifically interested in knowing the 'public' IP addresses and keep-
> alive times associated with each NAT.  I think that could be accomplished
> without attempting to control the keep-alive times in the NATs.
> 
> So, it might be possible to skirt charter issues by limiting this draft to
> 'discovery' functions and not including 'control' functions.
> 
> Best Regards,
> 
> Eric.
>