From safe-bounces@ietf.org Wed Sep 26 19:22:44 2007 Return-path: 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 ; 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 ; Wed, 26 Sep 2007 23:22:17 GMT From: "Dan Wing" To: 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 |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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From safe-bounces@ietf.org Wed Sep 26 19:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagEY-0007qx-CV; Wed, 26 Sep 2007 19:23:58 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IagEW-0007qo-VR for safe-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 19:23:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagEW-0007qb-L9 for safe@ietf.org; Wed, 26 Sep 2007 19:23:56 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IagEW-0002zE-Bg for safe@ietf.org; Wed, 26 Sep 2007 19:23:56 -0400 X-IronPort-AV: E=Sophos;i="4.21,199,1188802800"; d="scan'208";a="20247748" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2007 16:23:55 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8QNNtgO003298 for ; Wed, 26 Sep 2007 16:23:55 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8QNNt1l026774 for ; Wed, 26 Sep 2007 23:23:55 GMT From: "Dan Wing" To: References: <001501c7cd5b$d4c1b0d0$be91150a@amer.cisco.com> <002801c7cd5c$9446ed30$be91150a@amer.cisco.com> Subject: RE: [SAFE] Bar BoF Date: Wed, 26 Sep 2007 16:23:54 -0700 Message-ID: <029901c80094$4e82bd90$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: <002801c7cd5c$9446ed30$be91150a@amer.cisco.com> Thread-Index: AcfNW9RKpffQRt9GTNKYGM3RUezrnwAAJW8QDM3sAoA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=407; t=1190849035; x=1191713035; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[SAFE]=20Bar=20BoF |Sender:=20; bh=EbIpMRyXBZmSbHtP0ZEtxBCYeqJ3CFBHRTQ4ZFJsJIk=; b=JqQTh4McqGSX8eToojZea1/eV1OHwK4lTAICD/+EpnrMQc9cMgD3AwThQ2pUhYkE00gj4bzK DnkJez9EG2t1utxlUE5VsD9bsjt95kkKYco/sAUw8iasPUX8uspfQCDD; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org ... > I was reminded of another: > > 4. Implementation statements from NAT vendors. I haven't been able to get contacts into Netgear; if someone has a contact at Netgear they are willing to share, in order to move STUN Control forward, I would appreciate the help. I have sent mail to a contact in Juniper (still awaiting a reply) and expect to soon make some headway into Checkpoint. -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Wed Sep 26 19:37:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagRb-0008Ag-5j; Wed, 26 Sep 2007 19:37:27 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IagRa-0008AK-CA for safe-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 19:37:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagRa-0008AC-1Q for safe@ietf.org; Wed, 26 Sep 2007 19:37:26 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IagRZ-0003Ia-LP for safe@ietf.org; Wed, 26 Sep 2007 19:37:25 -0400 X-IronPort-AV: E=Sophos;i="4.21,199,1188802800"; d="scan'208";a="20249057" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2007 16:37:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8QNbPpu014002 for ; Wed, 26 Sep 2007 16:37:25 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8QNbO1l009002 for ; Wed, 26 Sep 2007 23:37:24 GMT From: "Dan Wing" To: References: <001501c7cd5b$d4c1b0d0$be91150a@amer.cisco.com> Date: Wed, 26 Sep 2007 16:37:24 -0700 Message-ID: <02c001c80096$31045100$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: AcfNW9RKpffQRt9GTNKYGM3RUezrnwzOECJg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1858; t=1190849845; x=1191713845; 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 |Subject:=20BOOTNONCE=20 |Sender:=20; bh=zCfhHLINADsiLISn3q/1kR670KaKlBzF2KRZIWyQSUQ=; b=oZ6X1jzZ4djYMFDWUt5CFNFCHIq1KwPGV41QOU1V/8SIlbnBL36k63Tu+A3TpILCk3cXNWkD weq54T4epZaPeV3V0oWD3rsVepPRnXdwQpUTQy/24/9IVLDAf+Od0dl8; 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: 21c69d3cfc2dd19218717dbe1d974352 Subject: [SAFE] BOOTNONCE X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org > 3. Dan needs to describe the security attack > that is avoided with BOOTNONCE This had caused some confusion in Chicago. Let me explain the attack and see how the I-D could be improved. The attack is this: 1. A host uses STUN normally and uses STUN-Control normally and successfully to communicate with their NAT. The end host learns their NAT's BOOTNONCE value. 2. An attacker manages to acquire their NAT's public IP address. This could occur due to DHCP lease expiration, or some malicious action by the attacker. 3. The attacker installs a STUN server on that public IP address. 4. The host needs a new NAT binding for a new phone call. The host sends a STUN request to the STUN server embedded in its outer-most NAT's IP address. However, this IP address is now owned by the attacker. 5. The attacker's STUN server replies with a STUN response. This STUN response points to an IP address that the attacker also owns. 6. The host uses the STUN response (provided by the attacker) in its SDP. 7. The attacker can view traffic traversing the IP address owned by the attacker. The BOOTNONCE attribute prevents this specific attack because in step (1), a unique value is returned to the host in the BOOTNONCE attribute. The attacker would need to return that same value in step (5). However, the attacker had no way to know that value. As described in draft-wing-behave-nat-control-stun-usage-03, the client IP address is included in this hash. By including the client IP address in the hash, for an attacker to be successful with this attack, the attacker would have to first connect to the network behind the NAT (using 802.11, for example), acquire the same NATted IP address as the victim's host and then acquire the same public IP address as the victim's NAT. Thoughts? -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe