Subject: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request under consideration: SAFE

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Oct 2007 15:33:31 +0200

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

---

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

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 12 Oct 2007 11:59:41 +0300

> such a reduction in keepalive traffic.

The Outside-In method would work, though the client would run a Teredo 
qualification procedure rather than a STUN Binding transaction with its 
server. When concluded, the the client can send a STUN Binding Request to its 
NAT.

The tagging approach fails terribly since Teredo qualification packet format 
is incompatible with STUN.

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Oct 2007 10:15:48 -0700

Rémi Denis-Courmont wrote:
> The Outside-In method would work, though the client would run 
> a Teredo qualification procedure rather than a STUN Binding 
> transaction with its server. When concluded, the the client can 
> send a STUN Binding Request to its NAT.

Agreed.  Here is what I am planning to add to -05:

   Endpoints that implement Teredo [RFC4380] learn their outer-most NATs
   address as their Teredo Mapped Address.  Once learned, the Teredo
   client can utilize STUN Control to query and control that NAT's UDP
   keepalive timeout, and thus reduce the Teredo refresh interval.
   Controlling the NAT's refresh interval explicitly is less brittle
   than Teredo's "interval determination procedure".  Nested NATs can be
   similarly discovered, queried, and controlled.

> The tagging approach fails terribly since Teredo 
> qualification packet format is incompatible with STUN.

Agreed.

But, thinking aloud:  after Teredo qualification the Teredo client 
could send a STUN packet to a STUN server (running on the same host 
it ran its Teredo qualification against), and get that STUN packet 
tagged.  So long as the UDP packets to those different UDP ports 
were routed the same, the same firewalls would be traversed.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 15 Oct 2007 16:38:28 +0300

> were routed the same, the same firewalls would be traversed.

Yes, but that adds a dependency on an otherwise not needed server only for the 
sake of STUN control.

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 15 Oct 2007 08:30:46 -0700

> Yes, but that adds a dependency on an otherwise not needed 
> server only for the sake of STUN control.

Right; but I don't know if that's harder than multiplexing the same 
code on UDP/500 or UDP/4500, though.  My worry about IKE is that
the IP address hashing was done on purpose, and I don't know what
that purpose was.  Learning your public IP address (and UDP port)
must have been considered sensitive information to some; of course 
the various tell-me-my-address services on the Internet makes that 
a moot argument.  

I agree putting the STUN server on the same port as IKE would be 
best.

-d

---

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