[MMUSIC] BOF request under consideration: SAFE
Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 08 October 2007 15:09 UTC
Return-path: <mmusic-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeuEB-0001BV-Uf; Mon, 08 Oct 2007 11:09:03 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeuEA-0001Ae-3T; Mon, 08 Oct 2007 11:09:02 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeuE9-0003La-DF; Mon, 08 Oct 2007 11:09:02 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E0FAF2045E; Mon, 8 Oct 2007 17:09:00 +0200 (CEST)
X-AuditID: c1b4fb3e-ae831bb0000007e1-b6-470a480c4ad7
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C898D21778; Mon, 8 Oct 2007 17:09:00 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 17:09:00 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 17:09:00 +0200
Message-ID: <470A480C.4040506@ericsson.com>
Date: Mon, 08 Oct 2007 17:09:00 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: TSV Area <tsv-area@ietf.org>, Behave WG <behave@ietf.org>, "mmusic (E-mail)" <mmusic@ietf.org>
X-Enigmail-Version: 0.95.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Oct 2007 15:09:00.0265 (UTC) FILETIME=[27E1FD90:01C809BD]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc:
Subject: [MMUSIC] BOF request under consideration: SAFE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org
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-control-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 ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] BOF request under consideration: SAFE Magnus Westerlund