From safe-bounces@ietf.org Thu Jun 14 14:26:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu23-0006Mx-Q8; Thu, 14 Jun 2007 14:26:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu21-0006Mc-B9; Thu, 14 Jun 2007 14:26:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyu21-0003t1-0o; Thu, 14 Jun 2007 14:26:53 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2007 11:26:52 -0700 X-IronPort-AV: i="4.16,421,1175497200"; d="scan'208"; a="162578647:sNHT42311988" 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 l5EIQq4o030252; Thu, 14 Jun 2007 11:26:52 -0700 Received: from dwingwxp (dhcp-128-107-163-66.cisco.com [128.107.163.66]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5EIQpaI011492; Thu, 14 Jun 2007 18:26:51 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , Date: Thu, 14 Jun 2007 11:26:52 -0700 Message-ID: <018201c7aeb1$947a0ea0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46710FA6.40407@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceuaaXPQ4y/HNUJRsam/N046TRQXwARsNtA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1105; t=1181845612; x=1182709612; 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:=20announcing=20SAFE=20mailing=20list=20[was=3A=20RE=3A=20[BEHAV E]=20BoF=20request=3A=20STUN=20Control=20Usage] |Sender:=20; bh=CeeBE8JuZ9r7pEPXGxyk4vFVwrxm+q16HnuSFQSZWG4=; b=IuRgUrlEBbg9B+U0rf98vqIbBNvbtpOerraPk+Nvd4aWAtiPvKMVAAr/0m3U5WL5YmRlKp5J tjenasnBusfqi98O0vWZyIBfmvOXgIHaROo+kB41F/6wip9PCS2hwTRv; 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: ea4ac80f790299f943f0a53be7e1a21a Cc: safe@ietf.org, behave@ietf.org Subject: [SAFE] announcing SAFE mailing list [was: RE: [BEHAVE] BoF request: STUN Control Usage] 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 Magnus Westerlund wrote: > Markus.Isomaki@nokia.com skrev: ... > > Instead of a BoF, I think it would still be useful to have slot in > > BEHAVE to discuss the proposal. A bar BoF should definitely be > > held, at least ;) > > No, not a slot in BEHAVE. As I said, lets focus BEHAVE on the WG's > current issues. We also have requested a new mailing list to move > the STUN control discussion too. It will be announced as soon it is > working. The new mailing list has been created, "Self-Address Fixing Evolution" (SAFE): Evolution of the protocol and procedures of RFC3489 and draft-ietf-behave-rfc3489bis, so that middleboxes can be discovered, queried, and controlled. Subscribe at: https://www1.ietf.org/mailman/listinfo/safe Please join the SAFE mailing list if you are interested in this topic. > A Bar BOF is fine and in fact encouraged. I'll schedule that in a few days on the SAFE mailing list. I am leaning towards Monday or Thursday for that, after dinner (Tuesday is the social and a SPIT bar BoF has been called for Wednesday). -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Jun 26 11:25:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CvV-0000Pg-I3; Tue, 26 Jun 2007 11:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CvU-0000OF-FZ for safe@ietf.org; Tue, 26 Jun 2007 11:25:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3CvQ-0003lv-6P for safe@ietf.org; Tue, 26 Jun 2007 11:25:56 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 26 Jun 2007 08:25:51 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMvKgEarR7PDh2dsb2JhbACPJQEBAQgOLA X-IronPort-AV: i="4.16,464,1175497200"; d="scan'208"; a="164276832:sNHT68499873" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5QFPph4000797 for ; Tue, 26 Jun 2007 08:25:51 -0700 Received: from dwingwxp (sjc-vpn6-185.cisco.com [10.21.120.185]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5QFPkGb023958 for ; Tue, 26 Jun 2007 15:25:50 GMT From: "Dan Wing" To: Date: Tue, 26 Jun 2007 08:25:45 -0700 Message-ID: <00cf01c7b806$4721a3d0$b978150a@amer.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: Thread-Index: AceuaaXPQ4y/HNUJRsam/N046TRQXwARsNtAAkCBrtA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=60; t=1182871551; x=1183735551; 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:=20SAFE=20bar=20BoF |Sender:=20; bh=mujk2NOnGRAVqFe+S5iFPgAP4EDEac9tMvB3M4qaqtM=; b=IyUcE8H2t/wiFPup7lw8a8XkyxqkdQNzb68hFKcHexLKiJGnCnbLw95hX/bn/qhan9zseFtj PhqHMbjVITmpkEAgJOqMhRLqNCuJgIYzpW241UjM7uMmoBvxYOFbup08; 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: 01485d64dfa90b45a74269b3ca9d5574 Subject: [SAFE] SAFE bar BoF 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 How does a Thursday, 10pm bar BoF work for everyone? -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Jun 26 11:29:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Cya-0006f8-RZ; Tue, 26 Jun 2007 11:29:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CyN-00063c-3n for safe@ietf.org; Tue, 26 Jun 2007 11:28:55 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3CvO-00024l-MV for safe@ietf.org; Tue, 26 Jun 2007 11:25:50 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Jun 2007 08:25:49 -0700 X-IronPort-AV: i="4.16,464,1175497200"; d="scan'208"; a="172325804:sNHT317565846" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5QFPnRj004055 for ; Tue, 26 Jun 2007 08:25:49 -0700 Received: from dwingwxp (sjc-vpn6-185.cisco.com [10.21.120.185]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5QFPkGa023958 for ; Tue, 26 Jun 2007 15:25:49 GMT From: "Dan Wing" To: Date: Tue, 26 Jun 2007 08:25:45 -0700 Message-ID: <00ce01c7b806$463aed50$b978150a@amer.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 Thread-Index: Ace3s+BZu9uG2bMESTO7HIqi9q6q3A== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1509; t=1182871549; x=1183735549; c=relaxed/simple; s=sjdkim1004; 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:=20eliminating=20TLS=20from=20STUN=20Control |Sender:=20; bh=COlS5o1koM2YeNPEzVOFL8gspzMZNVpGGbfD6voIUxs=; b=Tdgxg6+BColaIyhMxYQPpFroKSxVtApsqKOjaDeg1XBb5z9f3oUJ7hYl+XFxUJYOaJgcXORg JevO1KoGh/K4gywsD8LE5r44yL+st/lPiXT7BvNMofKmc+Ut+LXJAVh7WwbG89tl7Ece4kdtqs SqZh53aVsgCeuKj1oAtAy+dwU=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [SAFE] eliminating TLS from STUN Control 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 have been bothered by the need for TLS in STUN Control. This is present to protect against one particular attack: a malicious party acquires your NAT's public IP address and then starts their own STUN server which lies to you (that is, it provides inaccurate addresses in XOR-MAPPED-ADDRESS). I believe I have a solution to removing the need for TLS: when the STUN Client first talks to the STUN server built into the NAT, the STUN server returns XOR-INTERNAL-ADDRESS (as it does in the current specification) and also returns a 64-bit value in a new attribute called BOOTSTAMP. This value is generated randomly by the NAT device each time it initializes. The STUN client expects to see this same BOOTSTAMP value in each response from that NAT; if it sees a different value, the STUN client discards all of the information it has learned about that NAT (and all NATs inside of it). This protects against the attack that TLS protected against. However, this new technique is vulnerable to a malicious party learning the BOOTSTAMP value. The rogue party could connect to your 'inside' network and communicate with your NAT and learn the BOOTSTAMP value. This might be done via 802.11. If the NAT used unique BOOTSTAMP values for each client IP address, the malicious party would have to be on-path to see the BOOTSTAMP value associated with your IP address. Thoughts? (I also don't like the name 'BOOTSTAMP', but that is the best I have come up with so far.) -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Jun 26 16:28:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3HeT-0005Ia-SC; Tue, 26 Jun 2007 16:28:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3HeT-0005Hp-1z for safe@ietf.org; Tue, 26 Jun 2007 16:28:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3HeE-0000pu-Ez for safe@ietf.org; Tue, 26 Jun 2007 16:28:41 -0400 Received: (qmail invoked by alias); 26 Jun 2007 20:28:24 -0000 Received: from p54987914.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.121.20] by mail.gmx.net (mp038) with SMTP; 26 Jun 2007 22:28:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18nN61s55kno0AwmmonfRi7qVrA7/b2bkx86ulnjb vscWfvqN8hyUUp Message-ID: <468176E9.9010809@gmx.net> Date: Tue, 26 Jun 2007 22:28:25 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dan Wing Subject: Re: [SAFE] eliminating TLS from STUN Control References: <00ce01c7b806$463aed50$b978150a@amer.cisco.com> In-Reply-To: <00ce01c7b806$463aed50$b978150a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: safe@ietf.org 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 Hi Dan, I have a few minor comments: Dan Wing wrote: > I have been bothered by the need for TLS in STUN Control. This is present > to protect against one particular attack: a malicious party acquires your > NAT's public IP address and then starts their own STUN server which lies to > you (that is, it provides inaccurate addresses in XOR-MAPPED-ADDRESS). > Could you elaborate this attack a bit more? TLS provides a number of functions, the most important (in this case) are entity authentication and confidentiality protection. > I believe I have a solution to removing the need for TLS: when the STUN > Client first talks to the STUN server built into the NAT, the STUN server > returns XOR-INTERNAL-ADDRESS (as it does in the current specification) and > also returns a 64-bit value in a new attribute called BOOTSTAMP. This value > is generated randomly by the NAT device each time it initializes. The STUN > client expects to see this same BOOTSTAMP value in each response from that > NAT; if it sees a different value, the STUN client discards all of the > information it has learned about that NAT (and all NATs inside of it). > > In some sense you would like to accomplish functionality, which is called "Sender Invariance": "A party is assured that the source of the communication has remained the same as the one that started the communication, although the actual identity of the source is not important to the recipient." In former versions of the NSIS NATFW NSLP draft we used a sender invariance property that used Purpose Built Keys. The sender initially set the key and then every new message could be associated with the subsequent sender. This is nice functionality and provides quite interesting security properties. (One can every extend it to cases where you use CGAs but that's for IPv6 only.) Later, we removed it from the spec since we used TLS already. When you a cryptographic mechanism then you have a big advantage: An adversary that shows up later does not have a chance to modify or delete allocated state. > This protects against the attack that TLS protected against. > > It is true that it protects against this type of attack. The downside, however, is that you need some form of protection for authorization tokens and client authentication (in case of firewall traversal). > However, this new technique is vulnerable to a malicious party learning the > BOOTSTAMP value. The rogue party could connect to your 'inside' network and > communicate with your NAT and learn the BOOTSTAMP value. This might be done > via 802.11. > That's always a problem with these mechanisms unless you use CGAs. > If the NAT used unique BOOTSTAMP values for each client IP address, the > malicious party would have to be on-path to see the BOOTSTAMP value > associated with your IP address. > > That's true. The adversary has to be on-path or on the same shared medium. > Thoughts? (I also don't like the name 'BOOTSTAMP', but that is the best I > have come up with so far.) > I like the concept of sender invariance. I am, however, not sure how this concept extends to firewall traversal. I still believe you need a bit more than just a random value since it does not protect against a couple of attacks. Particularly in a mobile environment you might get a annoying effects: A node that was once along the communication path will be able to damage your future connection and it would be difficult to figure out where the attack actually came from. Ciao Hannes > -d > > > _______________________________________________ > 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 From safe-bounces@ietf.org Tue Jun 26 19:53:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KqT-00080X-6k; Tue, 26 Jun 2007 19:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KqR-0007z7-MD for safe@ietf.org; Tue, 26 Jun 2007 19:53:15 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Kpd-0002bp-7M for safe@ietf.org; Tue, 26 Jun 2007 19:53:15 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 26 Jun 2007 16:42:59 -0700 X-IronPort-AV: i="4.16,465,1175497200"; d="scan'208"; a="497941237:sNHT2144490830" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5QNgxIR005240; Tue, 26 Jun 2007 16:42:59 -0700 Received: from dwingwxp ([10.21.87.141]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5QNgxGW029760; Tue, 26 Jun 2007 23:42:59 GMT From: "Dan Wing" To: "'Hannes Tschofenig'" Subject: RE: [SAFE] eliminating TLS from STUN Control Date: Tue, 26 Jun 2007 16:42:58 -0700 Message-ID: <06de01c7b84b$ba4f36c0$b978150a@amer.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: <468176E9.9010809@gmx.net> Thread-Index: Ace4MI0vVq9KZb+fSK6wr3eBnfuZtwAGdH4A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5487; t=1182901379; x=1183765379; 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]=20eliminating=20TLS=20from=20STUN=20Control |Sender:=20; bh=WhDrUnOW7xdNeqJPXvdZOYhYGTEXcBKyefrrs82k1Ks=; b=IYvo2wDCur+dtukV3hvZ2rrQhJO9eUSsHIzBg9YRDVzFBAVbx4Q1uZvwDSNyQsaJLff2fVJU XMY4E+U2JrSIiwlXP2TPS1ectNqVXinSicttP+2nTi94F4GPZbc63KLL; 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: 68ba2b07ef271dba6ee42a93832cfa4c Cc: safe@ietf.org 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 have a few minor comments: > > Dan Wing wrote: > > I have been bothered by the need for TLS in STUN Control. > > This is present > > to protect against one particular attack: a malicious > > party acquires your > > NAT's public IP address and then starts their own STUN > > server which lies to > > you (that is, it provides inaccurate addresses in > > XOR-MAPPED-ADDRESS). > > Could you elaborate this attack a bit more? It's described in section 9.3 of the spec, http://www.tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-02#s ection-9.3 > TLS provides a number of functions, the most important (in this case) > are entity authentication and confidentiality protection. To handle this attack, TLS is only used to provide a username and password that are used to authenticate subsequent UDP exchanges with the STUN server embedded in the NAT. > > I believe I have a solution to removing the need for TLS: > > when the STUN > > Client first talks to the STUN server built into the NAT, > > the STUN server > > returns XOR-INTERNAL-ADDRESS (as it does in the current > > specification) and > > also returns a 64-bit value in a new attribute called > > BOOTSTAMP. This value > > is generated randomly by the NAT device each time it > > initializes. The STUN > > client expects to see this same BOOTSTAMP value in each > > response from that > > NAT; if it sees a different value, the STUN client discards > > all of the > > information it has learned about that NAT (and all NATs > > inside of it). > > In some sense you would like to accomplish functionality, which is > called "Sender Invariance": > > "A party is assured that the source of the communication has remained > the same as the one that started the communication, although > the actual identity of the source is not important to the recipient." > > > In former versions of the NSIS NATFW NSLP draft we used a sender > invariance property that used Purpose Built Keys. > The sender initially set the key and then every new message could be > associated with the subsequent sender. This is nice functionality and > provides quite interesting security properties. (One can > every extend it to cases where you use CGAs but that's for > IPv6 only.) > > Later, we removed it from the spec since we used TLS already. > > When you a cryptographic mechanism then you have a big advantage: An > adversary that shows up later does not have a chance to > modify or delete allocated state. You're describing the security properties the middlebox wants, rather than what the host wants. STUN Control's security model is quite different from NSIS; you can only create a binding or adjust a binding's timeout from the exact same transport address (source IP address and source UDP port) as the binding itself. If an attacker can acquire, or spoof, your source IP address and source UDP port, the attacker can interfere with things more interesting than the NAT binding. > > This protects against the attack that TLS protected against. > > It is true that it protects against this type of attack. The > downside, however, is that you need some form of protection > for authorization tokens and client authentication (in case > of firewall traversal). Yes, firewall traversal may well require client authentication and client authorization, because the firewall's policies might require that. That's a different requirement than the threat described in http://www.tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-02#s ection-9.3 > > However, this new technique is vulnerable to a malicious > > party learning the > > BOOTSTAMP value. The rogue party could connect to your > > 'inside' network and > > communicate with your NAT and learn the BOOTSTAMP value. > > This might be done via 802.11. > > That's always a problem with these mechanisms unless you use CGAs. > > > If the NAT used unique BOOTSTAMP values for each client IP > > address, the > > malicious party would have to be on-path to see the BOOTSTAMP value > > associated with your IP address. > > That's true. The adversary has to be on-path or on the same > shared medium. > > > Thoughts? (I also don't like the name 'BOOTSTAMP', but > > that is the best I > > have come up with so far.) > > I like the concept of sender invariance. I am, however, not sure how > this concept extends to firewall traversal. I agree it does not extend to firewall traversal. > I still believe you need a bit more than just a random value since it > does not protect against a couple of attacks. Particularly in > a mobile environment you might get a annoying effects: A node > that was once along the communication path will be able to > damage your future connection and it would be difficult to > figure out where the attack actually came from. Well, I'm assuming whoever has an IP address is the owner of that IP address; whoever had it before can't do anything with STUN Control. This is different from NSIS, MIDCOM, and a slew of other protocols because the middlebox management is out-of- band (that is, it uses a protocol that needs a lot of machinery to tie itself to the connection it's describing; with STUN Control, we're using the connection itself (same source IP address and source UDP port) so can throw away much of that machinery.) -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Thu Jun 28 03:12:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3oBA-0001ci-II; Thu, 28 Jun 2007 03:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3oB9-0001Ze-11 for safe@ietf.org; Thu, 28 Jun 2007 03:12:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3oAo-0002Uk-5g for safe@ietf.org; Thu, 28 Jun 2007 03:12:35 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 28 Jun 2007 00:12:13 -0700 X-IronPort-AV: i="4.16,469,1175497200"; d="scan'208"; a="173536952:sNHT35926344" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l5S7CDi3005120 for ; Thu, 28 Jun 2007 00:12:13 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5S7CDka011009 for ; Thu, 28 Jun 2007 07:12:13 GMT From: "Dan Wing" To: Date: Thu, 28 Jun 2007 00:12:12 -0700 Message-ID: <060701c7b953$a6a95d90$dd93150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceuaaXPQ4y/HNUJRsam/N046TRQXwARsNtAAkCBrtAAaEd4QA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=154; t=1183014733; x=1183878733; c=relaxed/simple; s=sjdkim6002; 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=20SAFE=20bar=20BoF |Sender:=20; bh=yKLHni6IHh2nGbmp7/UyQ6+dzshVPcm6LjfnZ7M/RMw=; b=IgYfF1qnTzLDszs6yOMlrCnyGHnobthg+Q4ohnXHbV9sNpCUCzxPd0xYX7w3fIHL6YdzNTZO 5itO4ccq/oQYhFh3Wj4hEnKqwPTv1HtIaIFTBpueiDhgbrYdv1IUpuTO; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [SAFE] RE: SAFE bar BoF 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 > How does a Thursday, 10pm bar BoF work for everyone? Thursday conflicts with the "IPv6" party. How would Monday, 10pm work for everyone? -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Thu Jun 28 03:21:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3oJc-00056F-Dl; Thu, 28 Jun 2007 03:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3oJZ-0004ti-LK for safe@ietf.org; Thu, 28 Jun 2007 03:21:18 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3oJV-0005rF-Cb for safe@ietf.org; Thu, 28 Jun 2007 03:21:17 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2007 00:21:13 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAML9gkarR7MVh2dsb2JhbACPJgIJDiw X-IronPort-AV: i="4.16,469,1175497200"; d="scan'208"; a="382322699:sNHT40849584" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5S7LCeF027530; Thu, 28 Jun 2007 00:21:12 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5S7LCXH020369; Thu, 28 Jun 2007 07:21:12 GMT From: "Dan Wing" To: "'Dan Wing'" , Subject: RE: [SAFE] RE: SAFE bar BoF Date: Thu, 28 Jun 2007 00:21:11 -0700 Message-ID: <061701c7b954$e7ed79c0$dd93150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceuaaXPQ4y/HNUJRsam/N046TRQXwARsNtAAkCBrtAAaEd4QAAAS05g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <060701c7b953$a6a95d90$dd93150a@amer.cisco.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=131; t=1183015272; x=1183879272; c=relaxed/simple; s=sjdkim1004; 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]=20RE=3A=20SAFE=20bar=20BoF |Sender:=20; bh=Ev1zBLHX75tAc0vir286U2j33ERoGLl03SXvb8hiUGI=; b=KtTVWp/yPMu8px98VIPzt/de8aqWGPo+uCaMrazOJOfzCe3C1NlwU0F+CXpTmGw1pvEvzRJB 5BLOKNUCWDZJ1WDf8rrVA/AsXMtZOK1Zdz4T1Sv6yF/i62K+PISIGGASSLsWLZDWYtkW6bnDUM k0DJubnANa4eTVzzlk8BW18/Y=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: 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 > How would Monday, 10pm work for everyone? 10:30pm -- I was reminded of the TSV chairs/directorate dinner that evening. -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe