Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE

Philip Matthews <philip_matthews@magma.ca> Fri, 12 October 2007 12:06 UTC

Return-path: <safe-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJHb-0007gZ-Bz; Fri, 12 Oct 2007 08:06:23 -0400
Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IgJHZ-0007gT-QK for safe-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 08:06:21 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJHZ-0007db-FC for safe@ietf.org; Fri, 12 Oct 2007 08:06:21 -0400
Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgJHT-0001py-A6 for safe@ietf.org; Fri, 12 Oct 2007 08:06:16 -0400
Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from <philip_matthews@magma.ca>) id 1IgJHR-0001d1-36; Fri, 12 Oct 2007 08:06:14 -0400
In-Reply-To: <C84E0A4ABA6DD74DA5221E0833A35DF30A069164@esebe101.NOE.Nokia.com>
References: <470A480C.4040506@ericsson.com> <C84E0A4ABA6DD74DA5221E0833A35DF30A069164@esebe101.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <2E64FBC4-2ACD-4707-A17F-72A964105BB6@magma.ca>
Content-Transfer-Encoding: 7bit
From: Philip Matthews <philip_matthews@magma.ca>
Subject: Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE
Date: Fri, 12 Oct 2007 08:06:12 -0400
To: Markus.Isomaki@nokia.com
X-Mailer: Apple Mail (2.752.2)
X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 995b2e24d23b953c94bac5288c432399
Cc: safe@ietf.org
X-BeenThere: safe@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Self-Address Fixing Evolution <safe.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/safe>, <mailto:safe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/safe>
List-Post: <mailto:safe@ietf.org>
List-Help: <mailto:safe-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/safe>, <mailto:safe-request@ietf.org?subject=subscribe>
Errors-To: safe-bounces@ietf.org

I would like to second Markus comments: I also support the goals of  
the BOF, but I share his two technical concerns. The second concern  
was raised at the "informal BOF" in Chicago, but the first concern I  
have not hear discussed before.

Regarding the first concern, I think this might actually go beyond  
just STUN Control to be a general STUN/ICE issue. Even without STUN  
Control, it seems important for an endpoint to know if its keep-alive  
rate is sufficient to keep the bindings in intermediate NATs alive.  
The way I see this might be done is for the STUN server (or perhaps  
the remote endpoint) to send data at regular intervals while the  
client sends keep-alives at some rate. If the client continues to  
receive data after one or two keep-alive intervals have passed, the  
client knows its keep-alive rate is sufficient. A client may choose  
to test a lower keep-alive rate in this manner to see if that is also  
sufficient.

- Philip

On 11-Oct-07, at 08:53 , <Markus.Isomaki@nokia.com>  
<Markus.Isomaki@nokia.com> wrote:

> Hi,
>
> I support the goals of this BOF and I believe in the reasoning  
> provided
> by the charter. I have two concerns that should be addressed before I
> think STUN NAT control could become successfully deployed:
>
> 1. Technical issue: STUN control allows a host/application to discover
> NATs and disover/set NAT binding timers for UDP (typically to higher
> values than what the defaults, perhaps around 30-300 s, would be).
> However, BEFORE the application can start using the increased  
> keepalive
> period, it needs to have a some sort of assurance that there aren't
> OTHER middleboxes on its path with lower keepalive values.  
> Otherwise it
> would be impossible to rely on the increased timer values, and thus  
> the
> whole mechanism might fail in practice. So, I would like to include in
> the charter a goal where such discovery mechanisms and their
> applicability are considered. The actual mechanism might be based on
> STUN or something else. I know this is a hard problem in general,  
> but in
> many access network topologies the problem can be solved by
> configuration + discovery. I'd be happy to contribute in this area.
> Actually I believe this discovery part to be the real issue with this
> whole work, rather than the details of STUN itself.
>
> 2. Deployment issue: We do have several protocols in this area, for
> instance NSIS. Their deployment does not look to be happening. For  
> STUN
> control to be useful, we would need real interest from some real  
> NAT/FW
> vendors. It's of course difficult to say how to verify this in a BOF
> beyond matching people's e-mail addresses to NAT/FW product brands :-)
> Personally I can speak for a single client/host/device vendor only.
>
> Markus
>
>
>> -----Original Message-----
>> From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
>> Sent: 08 October, 2007 18:09
>> To: TSV Area; Behave WG; mmusic (E-mail)
>> Subject: [BEHAVE] BOF request under consideration: SAFE
>>
>> Hi,
>>
>> We ADs have received a request for a BOF in Vancouver: SAFE -
>> Self-Address Fixing Evolution. See description below. I would
>> appreciate any feedback on this. For public discussion please
>> use the SAFE mailing list.
>>
>> Post: safe@ietf.org
>> Subscribe: https://www1.ietf.org/mailman/listinfo/safe
>>
>> Draft:
>> http://www.ietf.org/internet-drafts/draft-wing-behave-nat-contr
> ol-stun-usage-03.txt
>>
>>
>> SAFE - Self-Address Fixing Evolution
>> ------------------------------------
>>
>> Chairs:
>>  TBD
>>
>>
>> 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.
>>
>> Other NAT traversal protocols do not share these
>> characteristics, which hinders their widespread deployment.
>> Specifically,
>>
>>  * incremental deployment is not possible with MIDCOM, NSIS-NSLP,
>>    UPnP, or Bonjour.  With all of these protocols, both the NAT
>>    and the endpoint have to support the same protocol.
>>  * nested NATs are not possible with UPnP or Bonjour.
>>  * topology awareness is required of MIDCOM.
>>  * security must be established between the controlling entity
>>    and the NAT for MIDCOM and NSIS-NSLP.
>>  * Both UPnP and Bonjour use broadcast packets which don't work
>>    well on routed networks.
>>
>> However, a drawback of ICE/STUN is its chatty keepalive
>> traffic, which is a result of STUN not knowing the binding
>> lifetime of its on-path NATs.  This chattiness causes a burden
>> on servers and consumes network bandwidth, which is especially
>> critical on wireless networks.  It is desirable to reduce this
>> chattiness while still retaining the important characteristics
>> of STUN and ICE.
>>
>> This BoF is intended to discuss one proposed technique,
>> draft-wing-behave-nat-control-stun-usage, which nearly
>> eliminates STUN's keepalive chatter and still preserves the
>> desirable characteristics of STUN/ICE.
>>
>> The purpose of this BoF is to create a working group for this effort.
>>
>>
>> Agenda:
>>  Introduction, Agenda ....................................  5
>>  Summary of existing NAT traversal techniques ............ 40
>>   (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE)
>>  draft-wing-behave-nat-control-stun-usage ................ 40
>>  Q&A ..................................................... 25
>>                                                    ----------
>>                                                    total: 110
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> IETF Transport Area Director & TSVWG Chair
>> --------------------------------------------------------------------- 
>> -
>> Multimedia Technologies, Ericsson Research EAB/TVM/M
>> --------------------------------------------------------------------- 
>> -
>> Ericsson AB                | Phone +46 8 4048287
>> Torshamsgatan 23           | Fax   +46 8 7575550
>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> --------------------------------------------------------------------- 
>> -
>>
>>
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www1.ietf.org/mailman/listinfo/behave
>>
>
>
> _______________________________________________
> SAFE mailing list
> SAFE@ietf.org
> https://www1.ietf.org/mailman/listinfo/safe
>



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