RE: [SAFE] Bar BoF

"Dan Wing" <dwing@cisco.com> Wed, 26 September 2007 23:22 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 1IagD3-0000qF-84; Wed, 26 Sep 2007 19:22:25 -0400
Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IagD2-0000my-4t for safe-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 19:22:24 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagCx-0000Uf-HZ for safe@ietf.org; Wed, 26 Sep 2007 19:22:19 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IagCx-0002wk-1o for safe@ietf.org; Wed, 26 Sep 2007 19:22:19 -0400
X-IronPort-AV: E=Sophos;i="4.21,199,1188802800"; d="scan'208";a="528544014"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 26 Sep 2007 16:22:18 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8QNMIcO025507 for <safe@ietf.org>; Wed, 26 Sep 2007 16:22:18 -0700
Received: from dwingwxp01 ([10.32.240.198]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8QNMHDL011664 for <safe@ietf.org>; Wed, 26 Sep 2007 23:22:17 GMT
From: Dan Wing <dwing@cisco.com>
To: safe@ietf.org
References: <001501c7cd5b$d4c1b0d0$be91150a@amer.cisco.com>
Subject: RE: [SAFE] Bar BoF
Date: Wed, 26 Sep 2007 16:22:17 -0700
Message-ID: <029801c80094$149c5a50$c6f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
In-Reply-To: <001501c7cd5b$d4c1b0d0$be91150a@amer.cisco.com>
Thread-Index: AcfNW9RKpffQRt9GTNKYGM3RUezrnwzOC0OA
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3180; t=1190848938; x=1191712938; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[SAFE]=20Bar=20BoF |Sender:=20; bh=hPDrpKVfnD3IENayl7aHA7hiIbqV8qrMNnxu1hWGlZg=; b=VBhGvoJVkwP73nRqwO7N/lEq/rEd5YYy1laVvRS6t1+8AUVw1jHRIAqAWNnXRNL2/rBah0Os mV7wgk6a4OaWIpp4Umz1TbAPPJDYkWPSG2it60mvtTRzle5ARw51ZaNw;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
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

> Thanks to everyone that attended.  I was surprised at the large
> turnout (24 people) and the level of interest -- this gives me the
> encouragement to continue pushing this work forward.  Major action
> items I took from the bar BoF were:
>
>   1. "why will SAFE succeed where other IETF NAT 
>      protocols not succeeded"
>   2. charter text for Vancouver

I integrated (1) and (2) into the BoF request for the Vancouver meeting,
below.  

Comments welcome; it is perhaps a bit aggressive and I would like assistance
in adjusting the tone.

-d

-----

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


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