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

Hi Dan,

Please forward this to the SAFE list as appropriate.

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.

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

*) 
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