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

From: "Dan Wing" <[email-masked]>
Date: Thu, 11 Oct 2007 09:45:10 -0700

Pekka,

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.

-d

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Thursday, October 11, 2007 6:34 AM
> To: [email-masked]
> 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:[email-masked]]
> Sent: Monday, October 08, 2007 7:07 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/safe

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Oct 2007 08:45:11 +0300 (EEST)

Hi Dan,

Please forward this to the SAFE list as appropriate.

> 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.

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

*) 
http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00116.html

---

From: <[email-masked]>
Date: Tue, 16 Oct 2007 16:36:26 +0300

Hi,

The NAT timeout adjustment specified in Teredo would indeed a useful
practice not only to Teredo but any other UDP-based protocols that need
connectivity through NATs (or firewalls, so even with native IPv6 or
public IPv4). Perhaps we should generalize it so that it could be used
also with e.g. IPSec ESP UDP encapslulation, DSMIPv6 and SIP-outbound
(if people keep insisting running SIP over UDP). I wonder if STUN could
be a good baseline for such a generalization. Something would be needed
on the "public side" of NAT to respond to the UDP packets creating the
"secondary" bindings which are used to determine the timeout period. 

I suppose the caveat is that the determination algorithm does not always
give correct results with non-BEHAVE compliant NATs, as different
bindings will behave differently. The benefit of STUN control
(implemented within the NAT itself) would be to make the determination
more explicit, even in cases where there are multiple layers of NAT. And
it would even be possible to increase the NAT timer from the default
value. But even if we could communicate to all NATs with STUN control, I
believe the application SHOULD use something like the procedure
described in Teredo and gradually increase the keepalive period towards
the one it configured/queried with STUN. This would alleviate the
problem of connectivity breaks caused by "invisible" firewalls etc.

Markus 

>From: ext Pekka Savola [mailto:[email-masked]] 
>Sent: 15 October, 2007 08:45
>To: Dan Wing
>Cc: [email-masked]; [email-masked]
>Subject: RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF 
>requestunderconsideration: SAFE
>
>Hi Dan,
>
>> 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.
>
>FWIW, as it happens, Teredo already supports automatic 
>adjustment to NAT timeouts.
>
>*)

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Oct 2007 09:29:09 -0700

> Hi Dan,

Hi.

> Please forward this to the SAFE list as appropriate.

It's CC'd.

> 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 

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