RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request underconsideration: SAFE

Pekka Savola wrote:
> Hi Dan,

Hi.

> Please forward this to the SAFE list as appropriate.

It's CC'd.

> On Thu, 11 Oct 2007, Dan Wing wrote:
> > The SAFE BoF isn't about comparing Teredo to STUN/ICE.
> >
> > Rather, it is about querying and controlling binding lifetimes of
> > NATs in order to reduce the frequency of keepalive messages across
> > those NATs.  This would benefit any UDP-based protocol that
> > traverses NATs and, today, needs to send keepalives every 20-30
> > seconds; such a protocol could reduce its keepalive traffic
> > substantially.  Teredo and IPsec-over-UDP would benefit from
> > such a reduction in keepalive traffic.
> 
> The list of drawbacks of existing solutions (that I clipped 
> off in the mail *) seemed to be written in a way that implied 
> that the BOF proposal wanted to express the superiority of 
> STUN/ICE compared to the other solutions.  I think you'll need to 
> include a complete list, reword to make the intent of the text 
> clearer or remove the drawback list completely.

I have tweaked the BoF request to clarify the intent of the
BoF.  It is now at http://www.employees.org/safe/bof-request.html

> FWIW, as it happens, Teredo already supports automatic adjustment to 
> NAT timeouts.

Yes, and this is effective to learn the NAT's default timeout and
to adjust keepalive traffic accordingly.  To be effective at reducing
keepalive traffic, the NAT's default timeout has to be increased 
for all UDP traffic (or, at a minimum, for all UDP traffic the NAT 
can identify as Teredo traffic).

However, Teredo doesn't have a way to request an _increase_ of the
NAT's timeout from the NAT's default.  That is what STUN Control can
do.  Thus, with STUN Control, the NAT could retain its default timeout 
(30, 60, 120 seconds, or whatever) for most UDP traffic, and have a 
much longer timeout (e.g., 5-10 minutes) for the UDP bindings that 
request a longer timeout.

-d

> *) 
> http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00116.html
> 
> >> -----Original Message-----
> >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> >> Sent: Thursday, October 11, 2007 6:34 AM
> >> To: safe@ietf.org
> >> Subject: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request
> >> underconsideration: SAFE
> >>
> >> Hi,
> >>
> >> This was sent to the V6OPS list by Pekka Savola. I forward 
> it to the
> >> SAFE list with his permission for commenting.
> >>
> >> Magnus Westerlund
> >>
> >>
> >> -----Original Message-----
> >> From: Pekka Savola [mailto:pekkas@netcore.fi]
> >> Sent: Monday, October 08, 2007 7:07 PM
> >> To: Romascanu, Dan (Dan)
> >> Cc: ops-area@ietf.org
> >> Subject: Re: [OPS-AREA] FW: [tsv-area] BOF request under
> >> consideration:
> >> SAFE
> >>
> >> On Mon, 8 Oct 2007, Romascanu, Dan (Dan) wrote:
> >>> ICE and its companion protocol STUN have been successfully
> >> deployed on
> >>
> >>> the Internet for NAT traversal.  ICE and STUN have several
> >>> characteristics which contribute to their success:
> >>>
> >>>  1. incremental deployment.  ICE and STUN are functional 
> without any
> >>>     modifications to existing NATs.
> >>>  2. nested NATs.  ICE and STUN work when there are multiple NATs
> >>>     between a host and the Internet.
> >>>  3. topology unaware.  ICE and STUN are not configured with
> >>>     information about NATs, firewalls, or their locations -- only
> >>>     with the IP address of a server on the Internet.
> >>>  4. simple security model.  If a host behind a NAT is
> >> allowed to send
> >>>     a packet across the NAT, it is allowed to receive a response.
> >>>  5. works on routed networks, which allows operation in both
> >>>     enterprise networks and home networks.
> >>
> >> Teredo also fulfills these characteristics (and has none of the
> >> drawbacks listed later).
> >>
> >> I'm confident that the BOF proposers will be able to invent new
> >> drawbacks to exclude Teredo from consideration, though.
> >>
> >> --
> >> Pekka Savola                 "You each name yourselves 
> king, yet the
> >> Netcore Oy                    kingdom bleeds."
> >> Systems. Networks. Security. -- George R.R. Martin: A 
> Clash of Kings
> >>
> >>
> >> _______________________________________________
> >> SAFE mailing list
> >> SAFE@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/safe
> >
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
SAFE mailing list
SAFE@ietf.org
https://www1.ietf.org/mailman/listinfo/safe