From behave-bounces@ietf.org Wed Aug 01 01:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6OY-0004pq-6w; Wed, 01 Aug 2007 01:05:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IG6OW-0004pk-Is for behave-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 01:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6OW-0004pb-99 for behave@ietf.org; Wed, 01 Aug 2007 01:05:12 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG6OV-0007Vo-Hc for behave@ietf.org; Wed, 01 Aug 2007 01:05:12 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l7154xQv012940; Wed, 1 Aug 2007 08:04:59 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l7154xTd012937; Wed, 1 Aug 2007 08:04:59 +0300 Date: Wed, 1 Aug 2007 08:04:59 +0300 (EEST) From: Pekka Savola To: Dan Wing Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters In-Reply-To: <07cc01c7d39a$c084c720$c5f0200a@amer.cisco.com> Message-ID: References: <07cc01c7d39a$c084c720$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3837/Wed Aug 1 02:48:51 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on otso.netcore.fi X-Spam-Score: -1.4 (-) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tue, 31 Jul 2007, Dan Wing wrote: >> Neither of these two >> forms of traffic could reasonably be described as "unsolicited" in >> this case. > > We have different definitions of 'solicited traffic' and > 'unsolicited traffic'. Other than opening a listener on UDP/500 > for IKE (and telling the upstream firewall to please open a > permission for incoming traffic), the host didn't do anything to > solicit an incoming IKE packet. I call that incoming traffic > 'unsolicited', because the host (and its firewall) are unaware > of when a client will send a packet to establish a connection. > An HTTP server or SMTP server fall into this category, for > example. > > This differs from the SIP model and the RTSP 2.0 model. In > both SIP and RTSP 2.0, an offer/answer exchange allows the > server to learn the client desires a new session. With that > knowledge, the server can communicate more specific information > to its firewall about the client's IP address; in this way, the > firewall doens't need to necessarily permit incoming IKE packets > from arbitrary remote addresses, unless those are first signaled > with SIP or RTSP. This model is also used by HIP and EME, two > working groups in the IRTF (www.irtf.org). This is what I would > consider 'solicited traffic'. I'm not sure if this distinction matters that much from the security perspective. IMHO the main point is the attack vector and effect. Even though SIP and RTSP 2.0 were offer/answer protocols, the main point is that there needs to be a service listening (to the whole world) on some ports, the same as with IKE. You're just shifting the attack vector from IKE to SIP/RTSP 2.0 which in and of itself doesn't help anything; in fact it could make the situation worse, given that (AFAIK) the SIP/RTSP 2.0 protocol suite is more complicated than IKE. The critical question then is, how much (and how complex) code in the listening service is required to make a decision whether to drop the new session or allow it to be established. In other words, if a vulnerability is found in the listening service software, can it be exploited by unauthenticated/unauthorized attackers and can it be used for compromise (e.g., remote code execution)? (I exclude DoS vulnerabilities from the interesting ones in this context.) This also affects protocol design, i.e., the protocols should be designed so that the amount and complexity of code needed to drop uninteresting connection requests can be minimal. There have been security vulnerabilities in both IKE and SIP protocol suites, but I do not recall outright whether such have enabled unauthenticated remote code execution exploits. If such were to be the case, or such vulnerabilities would have a high likelihood of succeeding, I'd think that most security administrators would want to filter out both IKE and SIP/RTSP 2.0. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 01 01:33:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6qA-0006EG-9e; Wed, 01 Aug 2007 01:33:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IG6q7-0006E9-W5 for behave-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 01:33:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6q7-0006E1-KO for behave@ietf.org; Wed, 01 Aug 2007 01:33:43 -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 1IG6q6-0007tM-U0 for behave@ietf.org; Wed, 01 Aug 2007 01:33:43 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2007 22:33:42 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAK63r0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,206,1183359600"; d="scan'208"; a="389484818:sNHT30273654" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l715XgRR028080; Tue, 31 Jul 2007 22:33:42 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l715XfSb009389; Wed, 1 Aug 2007 05:33:41 GMT From: "Dan Wing" To: "'Pekka Savola'" Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Tue, 31 Jul 2007 22:33:41 -0700 Message-ID: <001401c7d3fd$8577b530$c5f0200a@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: AcfT+Y2jm/+roXToTZqnX36fb8YojwAA7rCw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3997; t=1185946422; x=1186810422; 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[BEHAVE]=20Re=3A=20CPE=20equipments=20and=20stateful= 20filters |Sender:=20; bh=mUOTipoyYuB1Yr6+Y/XhxYnYUAO0wTzYfOUNpKvVZ7E=; b=OAEWlbpayypqeig0BOCsG3f2TINpRa6n8I/3P5NE4b2Y9c+aYnynX3Uepmh5HAsMT5CYYATw OX16idT6qOjlBqh4PGB8Dx97NUfwkzfGmVYJr0AV3A0ZZR3GEe7RNyMi; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Your email and Christian's email are both concerned with end-host protection. I am concerned with protecting the access link from unwanted traffic to save bandwidth and, for battery-powered devices, to save their batteries. If the device isn't listening on UDP/500 and would merely throw away or ICMP the incoming packet, there are advantages with bandwidth-constrained access links and with wireless devices, to discard the packet in the network (in a firewall device). -d > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, July 31, 2007 10:05 PM > To: Dan Wing > Cc: 'james woodyatt'; 'IPv6 Operations'; 'Behave WG' > Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters > > On Tue, 31 Jul 2007, Dan Wing wrote: > >> Neither of these two > >> forms of traffic could reasonably be described as "unsolicited" in > >> this case. > > > > We have different definitions of 'solicited traffic' and > > 'unsolicited traffic'. Other than opening a listener on UDP/500 > > for IKE (and telling the upstream firewall to please open a > > permission for incoming traffic), the host didn't do anything to > > solicit an incoming IKE packet. I call that incoming traffic > > 'unsolicited', because the host (and its firewall) are unaware > > of when a client will send a packet to establish a connection. > > An HTTP server or SMTP server fall into this category, for > > example. > > > > This differs from the SIP model and the RTSP 2.0 model. In > > both SIP and RTSP 2.0, an offer/answer exchange allows the > > server to learn the client desires a new session. With that > > knowledge, the server can communicate more specific information > > to its firewall about the client's IP address; in this way, the > > firewall doens't need to necessarily permit incoming IKE packets > > from arbitrary remote addresses, unless those are first signaled > > with SIP or RTSP. This model is also used by HIP and EME, two > > working groups in the IRTF (www.irtf.org). This is what I would > > consider 'solicited traffic'. > > I'm not sure if this distinction matters that much from the security > perspective. IMHO the main point is the attack vector and effect. > Even though SIP and RTSP 2.0 were offer/answer protocols, the main > point is that there needs to be a service listening (to the whole > world) on some ports, the same as with IKE. You're just shifting the > attack vector from IKE to SIP/RTSP 2.0 which in and of itself doesn't > help anything; in fact it could make the situation worse, given that > (AFAIK) the SIP/RTSP 2.0 protocol suite is more complicated than IKE. > > The critical question then is, how much (and how complex) code in the > listening service is required to make a decision whether to drop the > new session or allow it to be established. In other words, if a > vulnerability is found in the listening service software, can it be > exploited by unauthenticated/unauthorized attackers and can > it be used > for compromise (e.g., remote code execution)? (I exclude DoS > vulnerabilities from the interesting ones in this context.) > > This also affects protocol design, i.e., the protocols should be > designed so that the amount and complexity of code needed to drop > uninteresting connection requests can be minimal. > > There have been security vulnerabilities in both IKE and SIP protocol > suites, but I do not recall outright whether such have enabled > unauthenticated remote code execution exploits. If such were to be > the case, or such vulnerabilities would have a high likelihood of > succeeding, I'd think that most security administrators would want to > filter out both IKE and SIP/RTSP 2.0. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 01 03:04:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG8G9-0004at-0h; Wed, 01 Aug 2007 03:04:41 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IG8G7-0004ak-Cu for behave-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 03:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG8G3-0004WL-MJ for behave@ietf.org; Wed, 01 Aug 2007 03:04:35 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG8G3-0002Jd-9R for behave@ietf.org; Wed, 01 Aug 2007 03:04:35 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 1 Aug 2007 00:04:34 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.70.16) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.726.0; Wed, 1 Aug 2007 00:04:34 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com (157.54.62.24) by TK5-EXMLT-W601.wingroup.windeploy.ntdev.microsoft.com (157.54.70.16) with Microsoft SMTP Server id 8.1.122.1; Wed, 1 Aug 2007 00:04:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Wed, 1 Aug 2007 00:03:36 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0640547EEF2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <001401c7d3fd$8577b530$c5f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: CPE equipments and stateful filters Thread-Index: AcfT+Y2jm/+roXToTZqnX36fb8YojwAA7rCwAALsZpA= References: <001401c7d3fd$8577b530$c5f0200a@amer.cisco.com> From: Christian Huitema To: Dan Wing , Pekka Savola X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IPv6 Operations , Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, July 31, 2007 10:34 PM > To: 'Pekka Savola' > Cc: 'IPv6 Operations'; 'Behave WG' > Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters >=20 > Your email and Christian's email are both concerned with end-host > protection. I am concerned with protecting the access link from > unwanted traffic to save bandwidth and, for battery-powered devices, > to save their batteries. If the device isn't listening on UDP/500 > and would merely throw away or ICMP the incoming packet, there are > advantages with bandwidth-constrained access links and with wireless > devices, to discard the packet in the network (in a firewall device). If we followed your reasoning, cell phones should never be allowed to ring, because doing so might deplete the batteries. They would only be allowed to make outgoing calls... There are many other ways to resolve this issue for the small battery powered devices. For example, they may be programmed to only listen to local addresses, which would radically solve the issue. They may also keep their address "hidden", so as to not receive traffic. There are also some better ways to answer to DOS attacks in a firewall than blocking traffic outright. If the concern really is the batteries, then rate limiting comes to mind. For example, if a device receives a packet and does not respond, or send an ICMP, block the port for some period.=20 -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 01 16:18:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKe9-0000lS-Gp; Wed, 01 Aug 2007 16:18:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IGKe7-0000gh-RH for behave-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 16:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKe7-0000gS-H4 for behave@ietf.org; Wed, 01 Aug 2007 16:18:15 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGKe6-0000v6-Bc for behave@ietf.org; Wed, 01 Aug 2007 16:18:15 -0400 Received: by an-out-0708.google.com with SMTP id c17so58900anc for ; Wed, 01 Aug 2007 13:18:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Ys7TlKxT3TL+ieV8AgchA4p3H6hLDzCp+saSepsZfCDZpGCAMUGxBCKAwdDckbwqlZ/2L7CgivlAioYIoMqEIuA4gnHtbMFngxkZP/+k3AmTiE/B7hQNG8xolrqPR5E/ZDBYX4PmGP7HkGn0Utuci5URLkj5tsVT1t+X3fa8S4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=O34DH4wWbt3Odla4QNdQi9DgoREW87o5jAqftsi+bdRYphGctTP0Ovo9VxJ5dJ5ZxjzERolDRYSaJl5uIxdjPDjoIZVR13aYqA9WoCM8F9uv0gj3k6ldlcjKPCkPar1DktxsQYROnZBGiDbknP83NI/SNT41OfF4HmajQgaU+jQ= Received: by 10.100.110.16 with SMTP id i16mr666312anc.1185999493614; Wed, 01 Aug 2007 13:18:13 -0700 (PDT) Received: by 10.100.107.11 with HTTP; Wed, 1 Aug 2007 13:18:13 -0700 (PDT) Message-ID: <20d2bdfb0708011318t1b9d543ct59e3fbca27a31607@mail.gmail.com> Date: Wed, 1 Aug 2007 16:18:13 -0400 From: "Bruce Lowekamp" To: "=?ISO-8859-1?Q?R=E9mi_Denis-Courmont?=" Subject: Re: [BEHAVE] TURN: technical review by September 1 In-Reply-To: <200707311216.18858.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com> X-Google-Sender-Auth: 08badd38440ccb64 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Rohan Mahy , behave@ietf.org, ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 7/31/07, R=E9mi Denis-Courmont wrote: > At this point, the server really can only do one of three things: > (1) queue an indefinitely big amount of data, > (2) stop dequeing data from the TURN client until TCP_B gets "decongested= ", > (3) drop data for B, and reset/timeout connection with B. > (2) is flawed, as communication between client and peer A will be unduly > disrupted. It is an obvious security issue if A and B do not trust each > others. Even then, it is probably unacceptable: if say, B looses connecti= vity > for some reason, the flow to A will be totally disrupted until TCP_B > connection times out. There are similar problem if connectivity to B is m= uch > slower or less reliable than that to A. I think that 2 is the only possible "correct" behavior, because 1 is unimplementable and 3 breaks the basic TCP model merely because one destination has lower throughput than another. 2's problem is that it restricts both connections to the poorer of the pair (whether deliberate attack or poor provisioning), but at least they both behave like valid TCP connections. There's another possibility of making the protocol more complex by signalling queueing on the client connection, but I really don't think we want that. But unless there's a compelling reason to support it, I think it would be better if TURN just says one peer per client connection. I'm not aware of a compelling reason. If there is a compelling reason to support it, I think big red flags and possibly even SHOULD NOT language should be used to discourage its use except when necessary. Bruce _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 01 19:26:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGNaC-0008Be-HJ; Wed, 01 Aug 2007 19:26:24 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IGNaB-0008BZ-F4 for behave-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 19:26:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGNaB-0008BR-2c for behave@ietf.org; Wed, 01 Aug 2007 19:26:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGNaA-00062W-I2 for behave@ietf.org; Wed, 01 Aug 2007 19:26:22 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Aug 2007 16:26:20 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKOzsEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.19,210,1183359600"; d="scan'208"; a="192769385:sNHT25647336" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l71NQJbh018602; Wed, 1 Aug 2007 16:26:19 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l71NQJed015397; Wed, 1 Aug 2007 23:26:19 GMT From: "Dan Wing" To: "'Christian Huitema'" , "'Pekka Savola'" Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Wed, 1 Aug 2007 16:26:18 -0700 Message-ID: <035301c7d493$5d5dae10$aca36b80@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: <70C6EFCDFC8AAD418EF7063CD132D0640547EEF2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfT+Y2jm/+roXToTZqnX36fb8YojwAA7rCwAALsZpAAGLJ+AA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1930; t=1186010779; x=1186874779; c=relaxed/simple; s=sjdkim4002; 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[BEHAVE]=20Re=3A=20CPE=20equipments=20and=20stateful= 20filters |Sender:=20; bh=7uS+Z0gHc0zKpkyzTFWUg1ALZgcgM8yrrm2HZ4RY8rU=; b=QPzyAnmAvJf5yZgGNkq2ba177WKvopldyiZIRwCgBqMh4Q9qgJib8NW17OKJCawFlziihrPx 84EezBuBjJv51DtvoseV0hoFVYFpDovDUDkOq8xyZDpBWJ6R9ZDJ6Mt8; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Tuesday, July 31, 2007 10:34 PM > > To: 'Pekka Savola' > > Cc: 'IPv6 Operations'; 'Behave WG' > > Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters > > > > Your email and Christian's email are both concerned with end-host > > protection. I am concerned with protecting the access link from > > unwanted traffic to save bandwidth and, for battery-powered devices, > > to save their batteries. If the device isn't listening on UDP/500 > > and would merely throw away or ICMP the incoming packet, there are > > advantages with bandwidth-constrained access links and with wireless > > devices, to discard the packet in the network (in a > firewall device). > > If we followed your reasoning, cell phones should never be allowed to > ring, because doing so might deplete the batteries. They would only be > allowed to make outgoing calls... They would originate and maintain a signaling connection to their call processing box. That is what they do today on v4. > There are many other ways to resolve this issue for the small battery > powered devices. For example, they may be programmed to only listen to > local addresses, which would radically solve the issue. That could work well. > They may also keep their address "hidden", so as to not receive > traffic. I'm sure what you are referring to here; something akin to RFC3041? > There are also some better ways to answer to DOS attacks in a > firewall than blocking traffic outright. If the concern really > is the batteries, then rate limiting comes to mind. For example, > if a device receives a packet and does not respond, or send an ICMP, > block the port for some period. Rate-limiting down to 0 would work fine to protect the battery and the access link. Higher, and the device has to wake up and scarce access link bandwidth is consumed. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 02 17:36:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiLT-0003uZ-Kw; Thu, 02 Aug 2007 17:36:35 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IGiLS-0003uN-S9 for behave-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 17:36:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiLS-0003uA-Gk for behave@ietf.org; Thu, 02 Aug 2007 17:36:34 -0400 Received: from smtpout.mac.com ([17.250.248.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGiLS-0003oB-2s for behave@ietf.org; Thu, 02 Aug 2007 17:36:34 -0400 Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/smtpout04/MantshX 4.0) with ESMTP id l72LaXqp013727 for ; Thu, 2 Aug 2007 14:36:33 -0700 (PDT) Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu [192.150.186.170]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l72LaWLC020426 for ; Thu, 2 Aug 2007 14:36:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: behave@ietf.org From: Sally Floyd Date: Thu, 2 Aug 2007 14:36:32 -0700 X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [BEHAVE] Response of firewalls and middleboxes to TCP SYN packets that are ECN-Capable? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org In the TCPM working group, my co-authors and I are finishing up a draft on adding ECN-capability to TCP's SYN/ACK packets ("http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn"). Dave Thaler gave a report at the March IETF on the problems that regular TCP data packets can encounter from routers or middleboxes along the path ("http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm") The point of this email is to ask if anyone knows anything about specific problems that TCP SYN/ACK packets might encounter from the network if the ECN field in the IP header is marked as ECN-Capable (ECT) or Congestion Experienced (CE), over and above the problems that are already known about for TCP data packets. I am sending this email to this mailing list because it was suggested by someone at the TCPM working group last week. Any feedback that anyone might have would be appreciated. Many thanks, - Sally http://www.icir.org/floyd/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 06 02:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHwIX-000200-OO; Mon, 06 Aug 2007 02:42:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IHwIX-0001vo-4B for behave-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 02:42:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHwIW-0001vc-9j for behave@ietf.org; Mon, 06 Aug 2007 02:42:36 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHwIV-0006qA-L2 for behave@ietf.org; Mon, 06 Aug 2007 02:42:36 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l766fup5001786; Mon, 6 Aug 2007 09:42:20 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 09:42:18 +0300 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 09:42:18 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 6 Aug 2007 09:42:17 +0300 Message-ID: In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640547EEF2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: CPE equipments and stateful filters Thread-Index: AcfT+Y2jm/+roXToTZqnX36fb8YojwAA7rCwAALsZpAA+oH8sA== References: <001401c7d3fd$8577b530$c5f0200a@amer.cisco.com> <70C6EFCDFC8AAD418EF7063CD132D0640547EEF2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: To: , , X-OriginalArrivalTime: 06 Aug 2007 06:42:18.0179 (UTC) FILETIME=[EECD9130:01C7D7F4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: v6ops@ops.ietf.org, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org >-----Original Message----- >From: ext Christian Huitema [mailto:huitema@windows.microsoft.com]=20 >Sent: 01 August, 2007 10:04 > >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Tuesday, July 31, 2007 10:34 PM >>=20 >> Your email and Christian's email are both concerned with end-host=20 >> protection. I am concerned with protecting the access link from=20 >> unwanted traffic to save bandwidth and, for battery-powered devices,=20 >> to save their batteries. If the device isn't listening on=20 >> UDP/500 and would merely throw away or ICMP the incoming packet, >> there are advantages with bandwidth-constrained access links and with >> wireless devices, to discard the packet in the network (in a firewall >> device). Some low-speed radio links might need to be protected. However, the challenge with regards to battery consumption is to not have to send keepalives packet every so often. Quite obviously, sending requires a lot more power than receiving. In that sense, the battery would actually last LONGER on a device with a host firewall (so it does not answer unsolicited packets), but NO network firewall at all (so that there is no need to send keepalives). Explicit firewall signaling would probably provide a little bit more savings, but "implicit" signaling (hole punching...) is simply a big NO NO. However... >If we followed your reasoning, cell phones should never be=20 >allowed to ring, because doing so might deplete the batteries.=20 >They would only be allowed to make outgoing calls... > >There are many other ways to resolve this issue for the small=20 >battery powered devices. For example, they may be programmed=20 >to only listen to local addresses, which would radically solve=20 >the issue. They may also keep their address "hidden", so as to=20 >not receive traffic. > >There are also some better ways to answer to DOS attacks in a=20 >firewall than blocking traffic outright. If the concern really=20 >is the batteries, then rate limiting comes to mind. For=20 >example, if a device receives a packet and does not respond,=20 >or send an ICMP, block the port for some period.=20 Whether it is a good or bad business model, it is a matter of fact that some operators charge their users per-bit or per-packet, and it seems like IPv6 will not bring a change here. These guys really NEED stateful firewalls so that their users do not receive and PAY for packets they did not ask for. Unless they do not mind a class action from said users. --=20 R=E9mi Denis-Courmont Software Engineer Nokia TP/SP, Helsinki _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 06 03:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHwb9-0001re-Lk; Mon, 06 Aug 2007 03:01:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IHwb8-0001rY-4E for behave-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 03:01:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHwb7-0001rQ-QU for behave@ietf.org; Mon, 06 Aug 2007 03:01:49 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHwb6-0007Ae-VN for behave@ietf.org; Mon, 06 Aug 2007 03:01:49 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l7671d1C026775; Mon, 6 Aug 2007 10:01:39 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l7671cYG026772; Mon, 6 Aug 2007 10:01:39 +0300 Date: Mon, 6 Aug 2007 10:01:38 +0300 (EEST) From: Pekka Savola To: Remi.Denis-Courmont@nokia.com Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters In-Reply-To: Message-ID: References: <001401c7d3fd$8577b530$c5f0200a@amer.cisco.com> <70C6EFCDFC8AAD418EF7063CD132D0640547EEF2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3866/Sun Aug 5 22:20:48 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00, L_SPAM_COM_URL autolearn=ham version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: v6ops@ops.ietf.org, behave@ietf.org, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Mon, 6 Aug 2007, Remi.Denis-Courmont@nokia.com wrote: > Some low-speed radio links might need to be protected. ... > Whether it is a good or bad business model, it is a matter of > fact that some operators charge their users per-bit or > per-packet, and it seems like IPv6 will not bring a change > here. I think this is what the argument boils down to. I.e., which mechanisms are applicable on low-speed radio links vs everywhere else. I'd argue that because low-speed radio links already need to implement lots and lots of other protocol unpleasantry (I'd call it 'junk'), the scenario is not very interesting from a generic host perspective. Maybe the best would be to recognize the (at least) two different scenarios and consider applicable solutions separately. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 06 05:32:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHyx4-0001ri-2W; Mon, 06 Aug 2007 05:32:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IHyx3-0001rd-1g for behave-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 05:32:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHyx2-0001rV-Mr for behave@ietf.org; Mon, 06 Aug 2007 05:32:36 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHyx1-00037B-Up for behave@ietf.org; Mon, 06 Aug 2007 05:32:36 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l769WAlC025970; Mon, 6 Aug 2007 12:32:15 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 12:32:07 +0300 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 12:32:06 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] TURN: technical review by September 1 Date: Mon, 6 Aug 2007 12:32:06 +0300 Message-ID: In-Reply-To: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN: technical review by September 1 Thread-Index: AcfSzskf9wxeXRhnSA2cSHWPBMz2GwFO6wrg References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> From: To: , X-OriginalArrivalTime: 06 Aug 2007 09:32:06.0921 (UTC) FILETIME=[A7C43790:01C7D80C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: rohan@ekabal.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org >-----Original Message----- >From: ext Dan Wing [mailto:dwing@cisco.com]=20 >Sent: 30 July, 2007 20:27 >To: behave@ietf.org >Cc: 'Rohan Mahy'; huitema@microsoft.com >Subject: [BEHAVE] TURN: technical review by September 1 > >In Chicago at IETF-69 we explained the urgency around=20 >rfc3489bis ("STUNbis") and TURN. ICE needs to be published at=20 >the same time as rfc3489bis and TURN because ICE normatively=20 >references those documents. Rfc3489bis underwent substantial=20 >revision between -06 and -08, and I just WGLC'd rfc3489bis-08=20 >a few minutes ago. However, TURN is not yet ready to be WGLC'd. Frankly, I do not understand why ICE normatively depends on TURN. I could use SOCKS, UPnP, NAT-PMP, you-name-it... to generate my candidates, yet ICE does not depend on these. Of course, STUNbis is a dependency due to embracing and extending the STUN messages format. But TURN... ??? In fact, while I understand it might be late to "fix" this, I do not understand why ICE specifically mention TURN all over the place in the details, while it mentions tons of other potential non-normative ways to obtain candidates in its introduction, but this is a minor almost-editorial issue. So why is TURN not an informative reference? However... I am sorry to say that, but I think it would be wrong to Declare TURN "ready" before we=B4ve had the chance to examine its Interactions with ICE-TCP, and that=B4s not something I can put within 5 weeks (counting from the end of last IETF). I mean, ICE-TCP is no easy task in itself, and it would clearly be a pita when TURN turns out to work fine with UDP and be broken with TCP (I would really like we do not reproduce the mistakes from MSRP this time). An alternative is to split TURN into UDP/UDP, first and the other combinations separately, but I would not like this at all if I were one of the editor. That=B4s what=B4s been done with ICE though, and I expect that=B4s what implementors do - Does anyone know of a ICE-TCP stack out yet at all? Regards, --=20 R=E9mi Denis-Courmont Software Engineer Nokia TP/SP, Helsinki=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 06 05:55: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 1IHzJ0-0003Ey-Ps; Mon, 06 Aug 2007 05:55:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IHzIz-0003Eq-CS for behave-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 05:55:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHzIz-0003Eh-1j for behave@ietf.org; Mon, 06 Aug 2007 05:55:17 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHzIy-0003hX-8s for behave@ietf.org; Mon, 06 Aug 2007 05:55:16 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l769sak1025418; Mon, 6 Aug 2007 12:54:54 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 12:54:18 +0300 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 12:54:19 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] TURN: technical review by September 1 Date: Mon, 6 Aug 2007 12:54:18 +0300 Message-ID: In-Reply-To: <20d2bdfb0708011318t1b9d543ct59e3fbca27a31607@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN: technical review by September 1 Thread-Index: AcfUeSIpMf4IkIyARjS/WDApK4TnuwDkKy2w References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com> <20d2bdfb0708011318t1b9d543ct59e3fbca27a31607@mail.gmail.com> From: To: X-OriginalArrivalTime: 06 Aug 2007 09:54:19.0263 (UTC) FILETIME=[C1E778F0:01C7D80F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rohan@ekabal.com, behave@ietf.org, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org >-----Original Message----- >From: lowekamp@gmail.com [mailto:lowekamp@gmail.com] > >> (2) stop dequeing data from the TURN client until TCP_B gets=20 >> "decongested", >> (3) drop data for B, and reset/timeout connection with B. > >> (2) is flawed, as communication between client and peer A will be=20 >> unduly disrupted. It is an obvious security issue if A and B do not=20 >> trust each others. Even then, it is probably unacceptable: if say, B=20 >> looses connectivity for some reason, the flow to A will be totally=20 >> disrupted until TCP_B connection times out. There are=20 >> similar problem if connectivity to B is much slower or less reliable >> than that to A. >I think that 2 is the only possible "correct" behavior,=20 >because 1 is unimplementable and 3 breaks the basic TCP model=20 >merely because one destination has lower throughput than=20 >another. 2's problem is that it restricts both connections to=20 >the poorer of the pair (whether deliberate attack or poor=20 >provisioning), but at least they both behave like valid TCP=20 >connections. (2) is hardly more correct than (3). B could bring its TCP window to zero for as long as the TCP timeout, then accept a few bytes, and go back to zero, and so on... And then, there=B4s the issue that it allows a single TURN client to exhaust the server resources more easily. >There's another possibility of making the protocol more=20 >complex by signalling queueing on the client connection, but I=20 >really don't think we want that. Agreed. That would be the proper solution, but that would also be overly complicated. At the end, we=B4d redefine conveying datagrams on top of TCP, so you can do TCP over TCP :-( >But unless there's a compelling reason to support it, I think=20 >it would be better if TURN just says one peer per client=20 >connection. I'm not aware of a compelling reason. If there=20 >is a compelling reason to support it, I think big red flags=20 >and possibly even SHOULD NOT language should be used to=20 >discourage its use except when necessary. Personnaly, I tend to agree with Alfred and Evgeniy: Multiple simultaneously-active connections should not be supported at all. In fact, the send&data indications format is not quite Suited for connection-oriented transports. By the way, does ICE-TCP requires the TURN server to accept multiple connections? If so, how does this fit with the requirements to only allow one connection in order not to "bypass security"? --=20 R=E9mi Denis-Courmont Software Engineer Nokia TP/SP, Helsinki=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 06 10:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II3hX-0007W4-C8; Mon, 06 Aug 2007 10:36:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1II3hW-0007Vh-2p for behave-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 10:36:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II3hV-0007VV-OA for behave@ietf.org; Mon, 06 Aug 2007 10:36:53 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II3hV-0001rN-09 for behave@ietf.org; Mon, 06 Aug 2007 10:36:53 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l76Eakp22791; Mon, 6 Aug 2007 07:36:47 -0700 In-Reply-To: References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Subject: Re: [BEHAVE] TURN: technical review by September 1 Date: Mon, 6 Aug 2007 07:36:46 -0700 To: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Rohan Mahy , behave@ietf.org, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Remi, I seem to remember that gathering TURN candidates specifically was a =20 SHOULD in a previous version of ICE. Now it just says: "Agents =20 SHOULD obtain relayed candidates..." but doesn't specify a specific =20 method. Even so, it seems that normatively describing how to use at =20 least one method with ICE is quite important. A related issue is that since SIP calls can fork, ICE needs to work =20 in this environment, so any relay protocol needs to have =20 deterministic behavior in this environment. I personally would not =20 have done TURN if we did not need support for forking. Without =20 forking we could have reused another relay protocol (like SOCKS). And as much as I would like to wish otherwise, I suspect you are =20 right that we don't know how well TURN TCP really works without an =20 early implementation ICE TCP. thanks, -rohan On Aug 6, 2007, at 2:32 AM, wrote: >> -----Original Message----- >> From: ext Dan Wing [mailto:dwing@cisco.com] >> Sent: 30 July, 2007 20:27 >> To: behave@ietf.org >> Cc: 'Rohan Mahy'; huitema@microsoft.com >> Subject: [BEHAVE] TURN: technical review by September 1 >> >> In Chicago at IETF-69 we explained the urgency around >> rfc3489bis ("STUNbis") and TURN. ICE needs to be published at >> the same time as rfc3489bis and TURN because ICE normatively >> references those documents. Rfc3489bis underwent substantial >> revision between -06 and -08, and I just WGLC'd rfc3489bis-08 >> a few minutes ago. However, TURN is not yet ready to be WGLC'd. > > Frankly, I do not understand why ICE normatively depends on TURN. > I could use SOCKS, UPnP, NAT-PMP, you-name-it... to generate > my candidates, yet ICE does not depend on these. > > Of course, STUNbis is a dependency due to embracing and extending > the STUN messages format. But TURN... ??? In fact, while I understand > it might be late to "fix" this, I do not understand why ICE > specifically mention TURN all over the place in the details, while it > mentions tons of other potential non-normative ways to obtain > candidates in its introduction, but this is a minor almost-editorial > issue. So why is TURN not an informative reference? > > > However... I am sorry to say that, but I think it would be wrong to > Declare TURN "ready" before we=B4ve had the chance to examine its > Interactions with ICE-TCP, and that=B4s not something I can put within > 5 weeks (counting from the end of last IETF). I mean, ICE-TCP is no > easy task in itself, and it would clearly be a pita when TURN turns > out to work fine with UDP and be broken with TCP (I would really like > we do not reproduce the mistakes from MSRP this time). > > An alternative is to split TURN into UDP/UDP, first and the other > combinations separately, but I would not like this at all if I were > one of the editor. That=B4s what=B4s been done with ICE though, and I > expect that=B4s what implementors do - Does anyone know of a ICE-TCP > stack out yet at all? > > Regards, > > --=20 > R=E9mi Denis-Courmont > Software Engineer > Nokia TP/SP, Helsinki _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 06 10:38:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II3j3-0008Ud-SB; Mon, 06 Aug 2007 10:38:29 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1II3j2-0008U8-EP for behave-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 10:38:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II3j2-0008U0-4u for behave@ietf.org; Mon, 06 Aug 2007 10:38:28 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II3iy-0007wQ-UN for behave@ietf.org; Mon, 06 Aug 2007 10:38:28 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l76EcDp22802; Mon, 6 Aug 2007 07:38:14 -0700 In-Reply-To: References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com> <20d2bdfb0708011318t1b9d543ct59e3fbca27a31607@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Subject: Re: [BEHAVE] TURN: technical review by September 1 Date: Mon, 6 Aug 2007 07:38:13 -0700 To: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Rohan Mahy , behave@ietf.org, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Remi, I think (2) is the normal, default handling for TCP to TCP relays. =20 Yes, B could make its window very, very small, but TCP A is still no =20 worse off than a direct connection to the peer would have been. I =20 also don't see how this exhausts server resources. The server does =20 not have to do any work while it is not reading. It just needs to =20 keep connection state for the two connections. The TURN server could still set some minimum responsiveness or =20 throughput metric after which it employs (3), but (2) is still the =20 best default IMO. thanks, -rohan On Aug 6, 2007, at 2:54 AM, wrote: >> -----Original Message----- >> From: lowekamp@gmail.com [mailto:lowekamp@gmail.com] >> >>> (2) stop dequeing data from the TURN client until TCP_B gets >>> "decongested", >>> (3) drop data for B, and reset/timeout connection with B. >> >>> (2) is flawed, as communication between client and peer A will be >>> unduly disrupted. It is an obvious security issue if A and B do not >>> trust each others. Even then, it is probably unacceptable: if say, B >>> looses connectivity for some reason, the flow to A will be totally >>> disrupted until TCP_B connection times out. There are >>> similar problem if connectivity to B is much slower or less reliable >>> than that to A. > >> I think that 2 is the only possible "correct" behavior, >> because 1 is unimplementable and 3 breaks the basic TCP model >> merely because one destination has lower throughput than >> another. 2's problem is that it restricts both connections to >> the poorer of the pair (whether deliberate attack or poor >> provisioning), but at least they both behave like valid TCP >> connections. > > (2) is hardly more correct than (3). B could bring its TCP window > to zero for as long as the TCP timeout, then accept a few bytes, > and go back to zero, and so on... > > And then, there=B4s the issue that it allows a single TURN client to > exhaust the server resources more easily. > >> There's another possibility of making the protocol more >> complex by signalling queueing on the client connection, but I >> really don't think we want that. > > Agreed. That would be the proper solution, but that would also > be overly complicated. At the end, we=B4d redefine conveying datagrams > on top of TCP, so you can do TCP over TCP :-( > >> But unless there's a compelling reason to support it, I think >> it would be better if TURN just says one peer per client >> connection. I'm not aware of a compelling reason. If there >> is a compelling reason to support it, I think big red flags >> and possibly even SHOULD NOT language should be used to >> discourage its use except when necessary. > > Personnaly, I tend to agree with Alfred and Evgeniy: > Multiple simultaneously-active connections should not be supported > at all. In fact, the send&data indications format is not quite > Suited for connection-oriented transports. > > By the way, does ICE-TCP requires the TURN server to accept > multiple connections? If so, how does this fit with the requirements > to only allow one connection in order not to "bypass security"? > > > --=20 > R=E9mi Denis-Courmont > Software Engineer > Nokia TP/SP, Helsinki _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 07 02:38:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIIhh-0007Ea-2K; Tue, 07 Aug 2007 02:38:05 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIIhf-0007EU-K2 for behave-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 02:38:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIIhf-0007EK-9q for behave@ietf.org; Tue, 07 Aug 2007 02:38:03 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIIhe-0000wa-PJ for behave@ietf.org; Tue, 07 Aug 2007 02:38:03 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l776bUZc028948; Tue, 7 Aug 2007 09:37:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 09:37:42 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 09:37:41 +0300 Received: from hed050118.research.nokia.com ([172.21.50.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 09:37:41 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Rohan Mahy" Subject: Re: [BEHAVE] TURN: technical review by September 1 Date: Tue, 7 Aug 2007 09:37:42 +0300 User-Agent: KMail/1.9.6 References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708070937.42455.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 07 Aug 2007 06:37:41.0759 (UTC) FILETIME=[7474F8F0:01C7D8BD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: behave@ietf.org, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Monday 06 August 2007 17:36:46 ext Rohan Mahy wrote: > A related issue is that since SIP calls can fork, ICE needs to work > in this environment, so any relay protocol needs to have > deterministic behavior in this environment. I personally would not > have done TURN if we did not need support for forking. Without > forking we could have reused another relay protocol (like SOCKS). After a bit of thinking, I doubt forking really requires multiplexing=20 TCP-over-TCP. The client can simply reconnect to the TURN server and reques= t=20 the same port number as was already allocated using REQUESTED-PORT-PROPS,=20 REQUESTED-IP and REQUESTED-TRANSPORT, and preserve 1:1 TCP connection=20 relaying. As such, I see no reasons for allowing 1:N (TCP|TLS)-to-TCP. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 07 10:03:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPeX-0001N9-0w; Tue, 07 Aug 2007 10:03:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIPeV-0001N2-M3 for behave-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 10:03:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPeV-0001Mu-Bu for behave@ietf.org; Tue, 07 Aug 2007 10:03:15 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIPeU-0007Km-OV for behave@ietf.org; Tue, 07 Aug 2007 10:03:15 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l77E33p19037; Tue, 7 Aug 2007 07:03:03 -0700 In-Reply-To: <200708070937.42455.remi.denis-courmont@nokia.com> References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200708070937.42455.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1FA2E0BB-9028-48E0-87E6-01B0D31E3365@ekabal.com> Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Subject: Re: [BEHAVE] TURN: technical review by September 1 Date: Tue, 7 Aug 2007 07:03:02 -0700 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Rohan Mahy , behave@ietf.org, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi R=E9mi, I have to think about this suggestion a bit more. Today, sending a =20 new Allocate request with an existing allocated address and port =20 causes a move. We would need to add a new attribute at least. I'm not sure this is really any simpler than supporting and (briefly) =20= using 1:N TCP connections. I don't think it is a practical problem =20 to limit the speed of the client to TURN server connection to the =20 speed of the slowest of the server to peer connections, but this =20 would be good to model. thanks, -rohan On Aug 6, 2007, at 11:37 PM, R=E9mi Denis-Courmont wrote: > On Monday 06 August 2007 17:36:46 ext Rohan Mahy wrote: >> A related issue is that since SIP calls can fork, ICE needs to work >> in this environment, so any relay protocol needs to have >> deterministic behavior in this environment. I personally would not >> have done TURN if we did not need support for forking. Without >> forking we could have reused another relay protocol (like SOCKS). > > After a bit of thinking, I doubt forking really requires multiplexing > TCP-over-TCP. The client can simply reconnect to the TURN server =20 > and request > the same port number as was already allocated using REQUESTED-PORT-=20 > PROPS, > REQUESTED-IP and REQUESTED-TRANSPORT, and preserve 1:1 TCP connection > relaying. > > As such, I see no reasons for allowing 1:N (TCP|TLS)-to-TCP. > > --=20 > R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 07 10:29:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQ3e-0004Tx-0S; Tue, 07 Aug 2007 10:29:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIQ3c-0004Th-NR for behave-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 10:29:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQ3c-0004TY-DE; Tue, 07 Aug 2007 10:29:12 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIQ3b-000179-TH; Tue, 07 Aug 2007 10:29:12 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l77ESilH009245; Tue, 7 Aug 2007 17:29:09 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:29:00 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:29:00 +0300 Received: from hed050118.research.nokia.com ([172.21.50.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:28:59 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Tue, 7 Aug 2007 17:28:59 +0300 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708071728.59636.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 07 Aug 2007 14:28:59.0590 (UTC) FILETIME=[4B5B8E60:01C7D8FF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mmusic@ietf.org Subject: [BEHAVE] STUN fingerprint and integrity tests X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org [ Please direct responses to BEHAVE mailing list, NOT MMUSIC! ] Hello, If anyone is implementing an ICE or something-using-STUN stack, I have put= =20 sample FINGERPRINT and MESSAGE-INTEGRITY test vectors. I might have messed= =20 them up, since I have not had the chance to test with third parties. Pending processing by the secretariat, you can find them here: http://www.remlab.net/files/ietf/draft-denis-behave-rfc3489bis-test-vectors= =2D00.txt Regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 07 11:55:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIRPE-0002q2-6x; Tue, 07 Aug 2007 11:55:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIRPC-0002pw-Ds for behave-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:55:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIRPC-0002po-3p for behave@ietf.org; Tue, 07 Aug 2007 11:55:34 -0400 Received: from www.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIRPB-0004ro-QO for behave@ietf.org; Tue, 07 Aug 2007 11:55:34 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id C34B43A02022; Tue, 7 Aug 2007 08:55:30 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 9DD9B3A02020; Tue, 7 Aug 2007 08:55:29 -0700 (PDT) Message-ID: <46B895F1.6010501@acm.org> Date: Tue, 07 Aug 2007 08:55:29 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [BEHAVE] STUN fingerprint and integrity tests References: <200708071728.59636.remi.denis-courmont@nokia.com> In-Reply-To: <200708071728.59636.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org R=E9mi Denis-Courmont wrote: > [ Please direct responses to BEHAVE mailing list, NOT MMUSIC! ] >=20 > Hello, >=20 > If anyone is implementing an ICE or something-using-STUN stack, I have = put=20 > sample FINGERPRINT and MESSAGE-INTEGRITY test vectors. I might have mes= sed=20 > them up, since I have not had the chance to test with third parties. It seems that you did not adjust the header length before calculating the MESSAGE-INTEGRITY for the request message (see last paragraph of section 14.4 of rfc3489bis-08). --=20 Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 07 14:15:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITab-0006MR-T1; Tue, 07 Aug 2007 14:15:29 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IITaZ-0006Io-Vy for behave-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 14:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITaZ-0006Ig-MW for behave@ietf.org; Tue, 07 Aug 2007 14:15:27 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IITaX-0005sj-BG for behave@ietf.org; Tue, 07 Aug 2007 14:15:27 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l77IFH9r023486; Tue, 7 Aug 2007 21:15:19 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 21:15:17 +0300 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 21:15:17 +0300 Received: from 172.21.143.123 ([172.21.143.123]) by esebe108.NOE.Nokia.com ([172.21.138.114]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Aug 2007 18:15:17 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable From: "Denis-Courmont Remi (Nokia-TP-MSW/Helsinki)" X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [BEHAVE] STUN fingerprint and integrity tests Thread-Index: AcfZHugvWQLXAcvMRpKkpPTwYAxK6A== To: "ext Marc Petit-Huguenin" Subject: Re: [BEHAVE] STUN fingerprint and integrity tests Date: Tue, 7 Aug 2007 18:15:13 +0300 Message-ID: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> X-Mailer: EAS Version 1.00 MIME-Version: 1.0 Content-Language: i-default X-OriginalArrivalTime: 07 Aug 2007 18:15:17.0811 (UTC) FILETIME=[E89BA830:01C7D91E] X-Nokia-AV: Clean X-Spam-Score: 1.4 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org You must be right, the SHA1s were computed according to -06. I will fix them tomorrow. thanks for the catch. Remi Denis-Courmont --- message original --- De : "ext Marc Petit-Huguenin" Objet : Re: [BEHAVE] STUN fingerprint and integrity tests Date : 7 ao=C3=BBt 2007 Heure : 18:55:38 R=C3=A9mi Denis-Courmont wrote: > [ Please direct responses to BEHAVE mailing list, NOT MMUSIC! ] >=20 > Hello, >=20 > If anyone is implementing an ICE or something-using-STUN stack, I have = put=20 > sample FINGERPRINT and MESSAGE-INTEGRITY test vectors. I might have = messed=20 > them up, since I have not had the chance to test with third parties. It seems that you did not adjust the header length before calculating the MESSAGE-INTEGRITY for the request message (see last paragraph of section 14.4 of rfc3489bis-08). --=20 Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 08 05:03:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIhSC-0002UQ-IX; Wed, 08 Aug 2007 05:03:44 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIhSA-0002UK-Df for behave-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 05:03:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIhS9-0002U4-Jg for behave@ietf.org; Wed, 08 Aug 2007 05:03:41 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIhS9-00015g-2N for behave@ietf.org; Wed, 08 Aug 2007 05:03:41 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7893IfE026687; Wed, 8 Aug 2007 12:03:35 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 12:03:19 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 12:03:19 +0300 Received: from esdhcp05134.research.nokia.com ([172.21.51.34]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 12:03:18 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] STUN fingerprint and integrity tests Date: Wed, 8 Aug 2007 12:03:19 +0300 User-Agent: KMail/1.9.6 References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> In-Reply-To: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708081203.19729.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 08 Aug 2007 09:03:18.0924 (UTC) FILETIME=[F6A04CC0:01C7D99A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > I will fix them tomorrow. thanks for the catch. Alright, here are the hopefully fixed vectors: static const char req[] =3D "\x00\x01\x00\x44" "\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae" "\x00\x24\x00\x04" "\x6e\x00\x01\xff" "\x80\x29\x00\x08" "\x93\x2f\xf9\xb1\x51\x26\x3b\x36\x00\x06\x00" "\x09\x65\x76\x74\x6a\x3a\x68\x36\x76\x59\x20\x20\x20" "\x00\x08\x00\x14" "\x62\x4e\xeb\xdc\x3c\xc9\x2d\xd8\x4b\x74\xbf\x85" "\xd1\xc0\xf5\xde\x36\x87\xbd\x33" "\x80\x28\x00\x04" "\xad\x8a\x85\xff"; static const char resp[] =3D "\x01\x01\x00\x3c" "\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae" "\x80\x22\x00\x0b" "\x74\x65\x73\x74\x20\x76\x65\x63\x74\x6f\x72\x20" "\x00\x20\x00\x08" "\x00\x01\xa1\x47\x5e\x12\xa4\x43" "\x00\x08\x00\x14" "\xab\x4e\x53\x29\x61\x00\x08\x4c\x89\xf2\x7c\x69" "\x30\x33\x5c\xa3\x58\x14\xea\x90" "\x80\x28\x00\x04" "\xae\x25\x8d\xf2"; Do they look OK to you? =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 08 09:53:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIlyk-0004Fu-SR; Wed, 08 Aug 2007 09:53:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIlyj-0004Fo-OL for behave-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 09:53:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIlyj-0004Fg-Er for behave@ietf.org; Wed, 08 Aug 2007 09:53:37 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIlyh-0000kL-Ju for behave@ietf.org; Wed, 08 Aug 2007 09:53:37 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l78Dqvqd019541; Wed, 8 Aug 2007 16:53:31 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 16:52:57 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 16:52:57 +0300 Received: from esdhcp05134.research.nokia.com ([172.21.51.34]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 16:52:57 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, "ext Sally Floyd" Subject: Re: [BEHAVE] Response of firewalls and middleboxes to TCP SYN packets that are ECN-Capable? Date: Wed, 8 Aug 2007 16:52:58 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708081652.59037.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 08 Aug 2007 13:52:57.0137 (UTC) FILETIME=[6CD92A10:01C7D9C3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 03 August 2007 00:36:32 ext Sally Floyd wrote: > In the TCPM working group, my co-authors and I are finishing up a > draft on adding ECN-capability to TCP's SYN/ACK packets > ("http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn"). > > Dave Thaler gave a report at the March IETF on the problems that > regular TCP data packets can encounter from routers or middleboxes > along the path > ("http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm") > > The point of this email is to ask if anyone knows anything about > specific problems that TCP SYN/ACK packets might encounter from the > network if the ECN field in the IP header is marked as ECN-Capable > (ECT) or Congestion Experienced (CE), over and above the problems > that are already known about for TCP data packets. I am sending > this email to this mailing list because it was suggested by someone > at the TCPM working group last week. I remember having to disable ECN on my desktop PC to be able to reach some= =20 websites at all. I am not aware of any specific additionnal problem with=20 SYN/ACK. I would expect that be the result of broken firewall/router=20 implementations that discard any packet with unknown IP header flags,=20 regardless of the transport header. That's pure guessing though. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 08 12:17: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 1IIoDX-00016K-8K; Wed, 08 Aug 2007 12:17:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIoDS-000142-Kg for behave-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 12:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIoDQ-00013A-UC for behave@ietf.org; Wed, 08 Aug 2007 12:16:57 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIoDP-0004Im-Ad for behave@ietf.org; Wed, 08 Aug 2007 12:16:56 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id EC6193A02022; Wed, 8 Aug 2007 09:16:53 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 6D4C33A02020; Wed, 8 Aug 2007 09:16:51 -0700 (PDT) Message-ID: <46B9EC72.2080602@acm.org> Date: Wed, 08 Aug 2007 09:16:50 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= Subject: Re: [BEHAVE] STUN fingerprint and integrity tests References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <200708081203.19729.remi.denis-courmont@nokia.com> In-Reply-To: <200708081203.19729.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org R=C3=A9mi Denis-Courmont wrote: >> I will fix them tomorrow. thanks for the catch. >=20 > Alright, here are the hopefully fixed vectors: >=20 > static const char req[] =3D > "\x00\x01\x00\x44" > "\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae" > "\x00\x24\x00\x04" "\x6e\x00\x01\xff" > "\x80\x29\x00\x08" "\x93\x2f\xf9\xb1\x51\x26\x3b\x36\x00\x06\x00" > "\x09\x65\x76\x74\x6a\x3a\x68\x36\x76\x59\x20\x20\x20" > "\x00\x08\x00\x14" "\x62\x4e\xeb\xdc\x3c\xc9\x2d\xd8\x4b\x74\xbf\x85" > "\xd1\xc0\xf5\xde\x36\x87\xbd\x33" > "\x80\x28\x00\x04" "\xad\x8a\x85\xff"; >=20 > static const char resp[] =3D > "\x01\x01\x00\x3c" > "\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae" > "\x80\x22\x00\x0b" "\x74\x65\x73\x74\x20\x76\x65\x63\x74\x6f\x72\x20" > "\x00\x20\x00\x08" "\x00\x01\xa1\x47\x5e\x12\xa4\x43" > "\x00\x08\x00\x14" "\xab\x4e\x53\x29\x61\x00\x08\x4c\x89\xf2\x7c\x69" > "\x30\x33\x5c\xa3\x58\x14\xea\x90" > "\x80\x28\x00\x04" "\xae\x25\x8d\xf2"; >=20 > Do they look OK to you? >=20 Yes, I added them to my unit tests. Thanks. --=20 Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 08 15:50:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIrXy-0006mU-OZ; Wed, 08 Aug 2007 15:50:22 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIrXx-0006mO-M6 for behave-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 15:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIrXx-0006mG-BS for behave@ietf.org; Wed, 08 Aug 2007 15:50:21 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIrXw-0001A9-KA for behave@ietf.org; Wed, 08 Aug 2007 15:50:21 -0400 Received: from auguste.remlab.net (unknown [IPv6:2002:3e4e:969c:0:20d:60ff:fe38:6d16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by poy.chewa.net (Postfix) with ESMTP id 28C759677D; Wed, 8 Aug 2007 21:50:19 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: v6ops WG Date: Wed, 8 Aug 2007 22:50:11 +0300 User-Agent: KMail/1.9.7 References: <1EBC4F40-7873-4FA4-9DC3-3909B321661B@daork.net> In-Reply-To: <1EBC4F40-7873-4FA4-9DC3-3909B321661B@daork.net> MIME-Version: 1.0 Message-Id: <200708082250.14884@auguste.remlab.net> X-Spam-Score: -0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: behave@ietf.org Subject: [BEHAVE] Re: I-D ACTION:draft-nward-v6ops-teredo-server-selection-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0363295412==" Errors-To: behave-bounces@ietf.org --===============0363295412== Content-Type: multipart/signed; boundary="nextPart2891757.frkKtS9z3P"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2891757.frkKtS9z3P Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le vendredi 3 ao=FBt 2007, Nathan Ward a =E9crit : > > 1) There are proprietary Teredo extensions (AFAIK, at least one > > that allows working with symmetric NATs). Do these depend on > > additional code the servers? If so, one server is not necessarily > > equivalent to another, and I could understand why MSFT would be > > reticent to use anycast. If so, one also might need to reconsider > > whether an anycast prefix makes sense when servers may provide > > different feature sets. > > I'm not aware of these extensions, can anyone provide info? =46rom http://www.microsoft.com/technet/network/ipv6/teredo.mspx : Symmetric NATs (...) Teredo in Windows Vista and Windows Server 2008 can work between Teredo clients if only one Teredo client is behind one or more symmetric NATs. For example, Teredo in Windows Vista and Windows Server 2008 will work if one of the peers is behind a symmetric NAT and the other is behind a cone or restricted NAT. As far as I can tell, symmetric NAT detection is already part of the=20 base spec, so it is not unlikely that this unspecified extension does=20 not involve any change to the servers. What's weirdest to me, as a regular of the BEHAVE WG, is support for=20 symmetric-to-restricted traversal. Symmetric-to-cone is "easy", but=20 symmetric-to-restricted, hmm?! At least, ICE cannot do that. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ --nextPart2891757.frkKtS9z3P Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iEYEABECAAYFAka6HnYACgkQw+xtvt1tEr2YWgCg5Msz+cxbPX48h1p6/Jp24CQw 1/4Anju3yeyvfrzg4brQ8mkhxGAFMuYW =yCgM -----END PGP SIGNATURE----- --nextPart2891757.frkKtS9z3P-- --===============0363295412== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0363295412==-- From behave-bounces@ietf.org Wed Aug 08 18:23:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItwM-0002et-Lt; Wed, 08 Aug 2007 18:23:42 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IItwL-0002eo-AK for behave-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 18:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItwL-0002ef-0b for behave@ietf.org; Wed, 08 Aug 2007 18:23:41 -0400 Received: from submit01.sysedata.no ([195.159.29.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IItwJ-00048O-Gw for behave@ietf.org; Wed, 08 Aug 2007 18:23:40 -0400 Received: from [84.215.127.238] (helo=[10.0.0.4]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1IItwG-00015r-PE; Thu, 09 Aug 2007 00:23:36 +0200 Message-ID: <46BA4268.2060204@db.org> Date: Thu, 09 Aug 2007 00:23:36 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.12 (X11/20070606) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= Subject: Re: [BEHAVE] STUN fingerprint and integrity tests References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <200708081203.19729.remi.denis-courmont@nokia.com> In-Reply-To: <200708081203.19729.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org RĂ©mi Denis-Courmont wrote: >> I will fix them tomorrow. thanks for the catch. > > Alright, here are the hopefully fixed vectors: > > static const char req[] = > "\x00\x01\x00\x44" > "\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae" > "\x00\x24\x00\x04" "\x6e\x00\x01\xff" > "\x80\x29\x00\x08" "\x93\x2f\xf9\xb1\x51\x26\x3b\x36\x00\x06\x00" > "\x09\x65\x76\x74\x6a\x3a\x68\x36\x76\x59\x20\x20\x20" > "\x00\x08\x00\x14" "\x62\x4e\xeb\xdc\x3c\xc9\x2d\xd8\x4b\x74\xbf\x85" > "\xd1\xc0\xf5\xde\x36\x87\xbd\x33" > "\x80\x28\x00\x04" "\xad\x8a\x85\xff"; > > static const char resp[] = > "\x01\x01\x00\x3c" > "\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae" > "\x80\x22\x00\x0b" "\x74\x65\x73\x74\x20\x76\x65\x63\x74\x6f\x72\x20" > "\x00\x20\x00\x08" "\x00\x01\xa1\x47\x5e\x12\xa4\x43" > "\x00\x08\x00\x14" "\xab\x4e\x53\x29\x61\x00\x08\x4c\x89\xf2\x7c\x69" > "\x30\x33\x5c\xa3\x58\x14\xea\x90" > "\x80\x28\x00\x04" "\xae\x25\x8d\xf2"; > > Do they look OK to you? > Remi, many thanks for doing this. It looks ok after I fixed some bugs in my code. Is the 64-bytes HMAC-SHA1 padding removed from rfc3489-bis, btw? could I ask that the USERNAME padding is changed from 0x20 to 0x00 ? /alfred _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 08 20:08:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIvZF-0002g7-Te; Wed, 08 Aug 2007 20:07:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIvZF-0002fb-7G for behave-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 20:07:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIvZE-0002fM-Ta for behave@ietf.org; Wed, 08 Aug 2007 20:07:56 -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 1IIvZD-0005YD-Ld for behave@ietf.org; Wed, 08 Aug 2007 20:07:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 08 Aug 2007 17:07:56 -0700 X-IronPort-AV: i="unknown"; a="511667043:sNHT0" 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 l7907tAv020747; Wed, 8 Aug 2007 17:07:55 -0700 Received: from dwingwxp (dhcp-128-107-163-88.cisco.com [128.107.163.88]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7907oVp027547; Thu, 9 Aug 2007 00:07:50 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" Subject: RE: [BEHAVE] Re: I-DACTION:draft-nward-v6ops-teredo-server-selection-00.txt Date: Wed, 8 Aug 2007 17:07:50 -0700 Message-ID: <073501c7da19$559dc8f0$98db47ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfZ9XEJujtJreWyQJCyriBJV1eyAgAImE9w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <200708082250.14884@auguste.remlab.net> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1443; t=1186618075; x=1187482075; 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[BEHAVE]=20Re=3A=20I-DACTION=3Adraft-nward-v6ops-tere do-server-selection-00.txt |Sender:=20; bh=BbKTgDpyAK2pozvkKd/qGFgnHpaDChJlH2kyMSARO1s=; b=fPxJ69YBzW4/kKCFB5vaI18JDcU+jkNUg7lVIytgjzmQbq2WTUz4qNbGbG/RuehIWUqETAHu 4DOwCCI1FozEMdCbOkresoahx2khxDG2oEdLpG1PzFH4FD+Qcu6KXd9w; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > From http://www.microsoft.com/technet/network/ipv6/teredo.mspx : > > Symmetric NATs > (...) > Teredo in Windows Vista and Windows Server 2008 can work between > Teredo clients if only one Teredo client is behind one or more > symmetric NATs. For example, Teredo in Windows Vista and Windows > Server 2008 will work if one of the peers is behind a symmetric NAT > and the other is behind a cone or restricted NAT. > > As far as I can tell, symmetric NAT detection is already part of the > base spec, so it is not unlikely that this unspecified extension does > not involve any change to the servers. > > > What's weirdest to me, as a regular of the BEHAVE WG, is support for > symmetric-to-restricted traversal. Symmetric-to-cone is "easy", but > symmetric-to-restricted, hmm?! At least, ICE cannot do that. Using RFC3489 terms, ICE can successfully establish a direct peer-to- peer UDP session between two hosts where one is behind a 'symmetric' NAT and another is behind a 'restricted cone' NAT (but you're right that ICE cannot establish that connection if it's a 'port restricted cone'). RFC4787's terminology, although longer than what most people use and are familiar with, does a much cleaner job of separating the port assignment (which is part of the problem; this is the major problem with 'symmetric' NATs) from the filtering (which is the other part of the problem). -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 09 02:18: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 1IJ1Lv-0000iw-FB; Thu, 09 Aug 2007 02:18:35 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IJ1Lu-0000il-0u for behave-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 02:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ1Lt-0000iY-EB for behave@ietf.org; Thu, 09 Aug 2007 02:18:33 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ1Lr-00027A-Pb for behave@ietf.org; Thu, 09 Aug 2007 02:18:33 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l796ICAl030089; Thu, 9 Aug 2007 09:18:25 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 09:18:11 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 09:18:11 +0300 Received: from esdhcp05135.research.nokia.com ([172.21.51.35]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 09:18:10 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Alfred E. Heggestad" Subject: Re: [BEHAVE] STUN fingerprint and integrity tests Date: Thu, 9 Aug 2007 09:18:13 +0300 User-Agent: KMail/1.9.6 References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <200708081203.19729.remi.denis-courmont@nokia.com> <46BA4268.2060204@db.org> In-Reply-To: <46BA4268.2060204@db.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708090918.13691.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 09 Aug 2007 06:18:10.0934 (UTC) FILETIME=[0F6AC160:01C7DA4D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Thursday 09 August 2007 01:23:36 ext Alfred E. Heggestad wrote: > Remi, many thanks for doing this. It looks ok after I fixed some bugs in = my > code. Is the 64-bytes HMAC-SHA1 padding removed from rfc3489-bis, btw? Yes. That text has been removed a bunch of revisions ago. You'd have to ask= =20 the editors why, but it was simply a "bad" idea - HMAC-SHA1 already pads=20 internally anyway. > could I ask that the USERNAME padding is changed from 0x20 to 0x00 ? rfc3489bis-08 says attribute padding can be anything. I am purposedly using= =20 white spaces instead of nuls to root out incorrect C implementations. I=20 should perhaps have used 0x41 to make it more obvious :) =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 09 07:02:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ5mm-0001C4-Lt; Thu, 09 Aug 2007 07:02:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IJ5mk-0001Bw-Sb for behave-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 07:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ5mj-0001Bm-Vb for behave@ietf.org; Thu, 09 Aug 2007 07:02:33 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ5mi-0007KM-4q for behave@ietf.org; Thu, 09 Aug 2007 07:02:33 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l79B1xdo017416; Thu, 9 Aug 2007 14:02:18 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 14:01:35 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 14:01:29 +0300 Received: from esdhcp05135.research.nokia.com ([172.21.51.35]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 14:01:29 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Rohan Mahy" , behave@ietf.org Subject: Re: [BEHAVE] TURN: technical review by September 1 Date: Thu, 9 Aug 2007 14:01:29 +0300 User-Agent: KMail/1.9.6 References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200708070937.42455.remi.denis-courmont@nokia.com> <1FA2E0BB-9028-48E0-87E6-01B0D31E3365@ekabal.com> In-Reply-To: <1FA2E0BB-9028-48E0-87E6-01B0D31E3365@ekabal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708091401.29705.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 09 Aug 2007 11:01:29.0575 (UTC) FILETIME=[A3658770:01C7DA74] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, On Tuesday 07 August 2007 17:03:02 ext Rohan Mahy wrote: > I have to think about this suggestion a bit more. Today, sending a > new Allocate request with an existing allocated address and port > causes a move. We would need to add a new attribute at least. While I do understand the point of moving a UDP flow, I doubt moving a TCP= =20 session makes any sense. If the TCP connection breaks, the server and the=20 server cannot really know up to where the other side has successfully=20 received data - all they know is that it's somewhere between the highest=20 received acknowledgement sequence and the highest sent sequence. But within= =20 the window, it's unknown by design. In theory, both sides could replicate "stream offsets" above the socket lay= er,=20 and exchange them when moving a connection, but I think nobody wants to go= =20 into that. And we'd have to replicate the TCP window buffers as well to=20 support retransmission. As such, I really think "moving" should be restricted to UDP server-to-peer= =20 flows. For TCP server-to-peer flows, if the client-to-server session breaks= ,=20 the server must break the server-to-peer connection. > I'm not sure this is really any simpler than supporting and (briefly) > using 1:N TCP connections. I don't think it is a practical problem > to limit the speed of the client to TURN server connection to the > speed of the slowest of the server to peer connections, but this > would be good to model. Say I want to send a 2gigs movie to a forked MSRP session. Should the faste= st=20 receiver wait for the slowest one? As a user, I definitely expect the faste= st=20 to not to have to wait. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 09 13:09:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJBW8-0007qE-UK; Thu, 09 Aug 2007 13:09:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IJBW8-0007oO-Fi for behave-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 13:09:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJBW8-0007ln-3f for behave@ietf.org; Thu, 09 Aug 2007 13:09:48 -0400 Received: from submit01.sysedata.no ([195.159.29.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJBW6-0006zM-Fi for behave@ietf.org; Thu, 09 Aug 2007 13:09:48 -0400 Received: from [84.215.127.238] (helo=[10.0.0.8]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1IJBW3-0006gf-JZ; Thu, 09 Aug 2007 19:09:43 +0200 Message-ID: <46BB4B0C.6030204@db.org> Date: Thu, 09 Aug 2007 19:12:44 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= Subject: Re: [BEHAVE] STUN fingerprint and integrity tests References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <200708081203.19729.remi.denis-courmont@nokia.com> <46BA4268.2060204@db.org> <200708090918.13691.remi.denis-courmont@nokia.com> In-Reply-To: <200708090918.13691.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org RĂ©mi Denis-Courmont wrote: > On Thursday 09 August 2007 01:23:36 ext Alfred E. Heggestad wrote: >> Remi, many thanks for doing this. It looks ok after I fixed some bugs in my >> code. Is the 64-bytes HMAC-SHA1 padding removed from rfc3489-bis, btw? > > Yes. That text has been removed a bunch of revisions ago. You'd have to ask > the editors why, but it was simply a "bad" idea - HMAC-SHA1 already pads > internally anyway. > ok thanks, that makes the implementation much simpler. with the current MESSAGE-INTEGRITY calculation, it means that the receiver must modify the incoming data before calculating HMAC-SHA1, in case the FINGERPRINT attribute is present after M-I. it also means that the STUN receiver must parse the whole message first, to check if the FINGERPRINT attribute is present, and the subtract 8 from the STUN Header length field. rfc3489bis-08 says that before calculating the M-I, a dummy M-I must be inserted into the message (to get the correct length). would it not be better to include the FINGERPRINT as a "dummy" attribute also? If that was the case, the length fields needs not modification at all. >> could I ask that the USERNAME padding is changed from 0x20 to 0x00 ? > > rfc3489bis-08 says attribute padding can be anything. I am purposedly using > white spaces instead of nuls to root out incorrect C implementations. I > should perhaps have used 0x41 to make it more obvious :) > okay. btw, could you add that the mapped address is 127.0.0.1:32853 in your response vector? /alfred _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 09 19:21:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHJq-0008V3-Vn; Thu, 09 Aug 2007 19:21:30 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIrql-0006AH-Rh for behave-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 16:09:47 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IIrql-0006A9-IW for behave@ietf.org; Wed, 08 Aug 2007 16:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqxN-0002Rp-R6 for behave@ietf.org; Wed, 08 Aug 2007 15:12:33 -0400 Received: from shell.rawbw.com ([198.144.192.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIqxM-0000Rr-C0 for behave@ietf.org; Wed, 08 Aug 2007 15:12:33 -0400 Received: from [10.0.1.2] (IDENT:stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id l78JCU8L073374; Wed, 8 Aug 2007 12:12:30 -0700 (PDT) In-Reply-To: <200708081203.19729.remi.denis-courmont@nokia.com> References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <200708081203.19729.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <49BE27AF-27F0-4399-B6E6-45386DCD617A@networkresonance.com> Content-Transfer-Encoding: quoted-printable From: Brian Korver Subject: Re: [BEHAVE] STUN fingerprint and integrity tests Date: Wed, 8 Aug 2007 12:12:20 -0700 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-TMDA-Confirmed: Wed, 08 Aug 2007 16:09:47 -0400 X-Mailman-Approved-At: Thu, 09 Aug 2007 19:21:27 -0400 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org These look good. -briank briank@networkresonance.com On Aug 8, 2007, at 2:03 AM, R=E9mi Denis-Courmont wrote: >> I will fix them tomorrow. thanks for the catch. > > Alright, here are the hopefully fixed vectors: > > static const char req[] =3D > "\x00\x01\x00\x44" > "\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae" > "\x00\x24\x00\x04" "\x6e\x00\x01\xff" > "\x80\x29\x00\x08" "\x93\x2f\xf9\xb1\x51\x26\x3b\x36\x00\x06\x00" > "\x09\x65\x76\x74\x6a\x3a\x68\x36\x76\x59\x20\x20\x20" > "\x00\x08\x00\x14" "\x62\x4e\xeb\xdc\x3c\xc9\x2d\xd8\x4b\x74\xbf\x85" > "\xd1\xc0\xf5\xde\x36\x87\xbd\x33" > "\x80\x28\x00\x04" "\xad\x8a\x85\xff"; > > static const char resp[] =3D > "\x01\x01\x00\x3c" > "\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae" > "\x80\x22\x00\x0b" "\x74\x65\x73\x74\x20\x76\x65\x63\x74\x6f\x72\x20" > "\x00\x20\x00\x08" "\x00\x01\xa1\x47\x5e\x12\xa4\x43" > "\x00\x08\x00\x14" "\xab\x4e\x53\x29\x61\x00\x08\x4c\x89\xf2\x7c\x69" > "\x30\x33\x5c\xa3\x58\x14\xea\x90" > "\x80\x28\x00\x04" "\xae\x25\x8d\xf2"; > > Do they look OK to you? > > --=20 > R=E9mi Denis-Courmont > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Aug 10 01:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNSA-0005Gd-Gr; Fri, 10 Aug 2007 01:54:30 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IJNS9-0005GM-Cc for behave-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 01:54:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNS9-0005G9-1w for behave@ietf.org; Fri, 10 Aug 2007 01:54:29 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJNS8-00061l-I1 for behave@ietf.org; Fri, 10 Aug 2007 01:54:28 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7A5s2pI027973; Fri, 10 Aug 2007 08:54:19 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:54:09 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:54:09 +0300 Received: from hed050122.research.nokia.com ([172.21.50.122]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:54:08 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Alfred E. Heggestad" Subject: Re: [BEHAVE] STUN fingerprint and integrity tests Date: Fri, 10 Aug 2007 08:54:09 +0300 User-Agent: KMail/1.9.6 References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <200708090918.13691.remi.denis-courmont@nokia.com> <46BB4B0C.6030204@db.org> In-Reply-To: <46BB4B0C.6030204@db.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708100854.09986.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 10 Aug 2007 05:54:08.0801 (UTC) FILETIME=[DE407910:01C7DB12] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Thursday 09 August 2007 20:12:44 you wrote: > with the current MESSAGE-INTEGRITY calculation, it means that the receiver > must modify the incoming data before calculating HMAC-SHA1, in case the > FINGERPRINT attribute is present after M-I. it also means that the STUN > receiver must parse the whole message first, to check if the FINGERPRINT > attribute is present, and the subtract 8 from the STUN Header length fiel= d. > > rfc3489bis-08 says that before calculating the M-I, a dummy M-I must be > inserted into the message (to get the correct length). would it not be > better to include the FINGERPRINT as a "dummy" attribute also? If that was > the case, the length fields needs not modification at all. Yes. The current -07/-08 text is optimized for sending, while the -06 was=20 implicitly optimized for receiving. In practice, -07/-08 makes sending bare= ly=20 easier, and receiving much more intricate. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Aug 10 10:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVGe-00018e-9U; Fri, 10 Aug 2007 10:15:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IJVGd-00015c-57 for behave-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 10:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVGc-00015S-R8 for behave@ietf.org; Fri, 10 Aug 2007 10:15:06 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJVGa-0006Xf-D4 for behave@ietf.org; Fri, 10 Aug 2007 10:15:06 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l7AEExp25932; Fri, 10 Aug 2007 07:15:00 -0700 In-Reply-To: <200708091401.29705.remi.denis-courmont@nokia.com> References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200708070937.42455.remi.denis-courmont@nokia.com> <1FA2E0BB-9028-48E0-87E6-01B0D31E3365@ekabal.com> <200708091401.29705.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1A1A8416-C8B0-45CC-ACAE-EDB535551A23@ekabal.com> Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Subject: Re: [BEHAVE] TURN: technical review by September 1 Date: Fri, 10 Aug 2007 07:14:58 -0700 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Rohan Mahy , behave@ietf.org, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Aug 9, 2007, at 4:01 AM, R=E9mi Denis-Courmont wrote: >> I'm not sure this is really any simpler than supporting and (briefly) >> using 1:N TCP connections. I don't think it is a practical problem >> to limit the speed of the client to TURN server connection to the >> speed of the slowest of the server to peer connections, but this >> would be good to model. > > Say I want to send a 2gigs movie to a forked MSRP session. Should =20 > the fastest > receiver wait for the slowest one? As a user, I definitely expect =20 > the fastest > to not to have to wait. Yes, I still think it is reasonable for the fastest receiver to wait =20 for the slowest one. This only happens during the period where you =20 are forking. You probably won't start sending a 2gig movie until =20 you've resolved which instance you are sending it to, and therefore =20 selected a single fork by then. thanks, -rohan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Aug 12 14:52:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKIXv-0004JZ-Qb; Sun, 12 Aug 2007 14:52:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKIXt-0004IN-TZ for behave-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 14:52:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKIXt-0004IF-Jy for behave@ietf.org; Sun, 12 Aug 2007 14:52:13 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKIXs-0002l7-Cq for behave@ietf.org; Sun, 12 Aug 2007 14:52:13 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 12 Aug 2007 11:52:12 -0700 X-IronPort-AV: i="4.19,251,1183359600"; d="scan'208"; a="198776381:sNHT43110198" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7CIqBoU021675 for ; Sun, 12 Aug 2007 11:52:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7CIqBVp008464 for ; Sun, 12 Aug 2007 18:52:11 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Aug 2007 11:52:11 -0700 Received: from [192.168.1.3] ([10.21.116.53]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Aug 2007 11:52:11 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2A6464F7-9BD9-43B6-B701-6C48E0CAE3EB@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Behave WG From: Cullen Jennings Date: Sun, 12 Aug 2007 11:51:00 -0700 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Aug 2007 18:52:11.0280 (UTC) FILETIME=[E400F900:01C7DD11] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=804; t=1186944731; x=1187808731; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Minor=20concern=20about=20one=20of=20the=20milestones=20 |Sender:=20; bh=+/ijJ150tF1Dw317VbgUDmGX6M9f7oduwxJakDmCvmo=; b=eZ6C5tMXXsCPDx5ysehjtzUCEFJXgeOwoODdTqZ7OVb0JusZmq+RiTcNwWsX0n2TIy1OBo88 20IqWi7x5hf51WE9tinMHGVUtR1XtfHHkz+dbJ/pDegeMySwkiIuB2CY; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [BEHAVE] Minor concern about one of the milestones X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org One of our milestones is Submit standards-track document that describes how an application can determine the type of NAT it is behind I think it is very hard for an application to reliably do this except under environments where all the traffic to the NAT is controlled. (Basically this was the general limitation of RFC 3489). I hope that the document for this milestone is more an approach to characterizing and testing behavior of NATs and is not a general suggestion that an application might be able to figure out what type of NAT it is behind then modify the applications behavior based on the type of NAT is is behind. I seem to recall the old milestone was more along the lines of testing but I can not find a copy of it. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 13 00:33:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKRbx-0001ul-0A; Mon, 13 Aug 2007 00:33:01 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKRbv-0001rr-L6 for behave-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 00:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKRbv-0001qg-A5 for behave@ietf.org; Mon, 13 Aug 2007 00:32:59 -0400 Received: from smtpout.mac.com ([17.250.248.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKRbt-0001JD-R9 for behave@ietf.org; Mon, 13 Aug 2007 00:32:59 -0400 Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/smtpout07/MantshX 4.0) with ESMTP id l7D4WubW013143; Sun, 12 Aug 2007 21:32:56 -0700 (PDT) Received: from [192.168.1.64] (adsl-70-231-252-248.dsl.snfc21.sbcglobal.net [70.231.252.248]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id l7D4WuuH025088; Sun, 12 Aug 2007 21:32:56 -0700 (PDT) In-Reply-To: <200708081652.59037.remi.denis-courmont@nokia.com> References: <200708081652.59037.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Sally Floyd Subject: Re: [BEHAVE] Response of firewalls and middleboxes to TCP SYN packets that are ECN-Capable? Date: Sun, 12 Aug 2007 21:32:54 -0700 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Remi - > I remember having to disable ECN on my desktop PC to be able to reach =20= > some > websites at all. I am not aware of any specific additionnal problem =20= > with > SYN/ACK. I would expect that be the result of broken firewall/router > implementations that discard any packet with unknown IP header flags, > regardless of the transport header. Many thanks for the feedback. I will add that to the draft. I have an old paper, "Measuring Interactions Between Transport Protocols and Middleboxes" ("http://www.icir.org/tbit/", Figure 1) that shows that there are many paths where the TCP SYN exchange doesn't complete if the SYN packet contains a known or unknown IP Option... - Sally http://www.icir.org/floyd/ ------------------------------------------------------------------------=20= ------------------------------------------ On Aug 8, 2007, at 6:52 AM, R=E9mi Denis-Courmont wrote: > On Friday 03 August 2007 00:36:32 ext Sally Floyd wrote: >> In the TCPM working group, my co-authors and I are finishing up a >> draft on adding ECN-capability to TCP's SYN/ACK packets >> ("http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn"). >> >> Dave Thaler gave a report at the March IETF on the problems that >> regular TCP data packets can encounter from routers or middleboxes >> along the path >> ("http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm") >> >> The point of this email is to ask if anyone knows anything about >> specific problems that TCP SYN/ACK packets might encounter from the >> network if the ECN field in the IP header is marked as ECN-Capable >> (ECT) or Congestion Experienced (CE), over and above the problems >> that are already known about for TCP data packets. I am sending >> this email to this mailing list because it was suggested by someone >> at the TCPM working group last week. > > I remember having to disable ECN on my desktop PC to be able to reach =20= > some > websites at all. I am not aware of any specific additionnal problem =20= > with > SYN/ACK. I would expect that be the result of broken firewall/router > implementations that discard any packet with unknown IP header flags, > regardless of the transport header. > > That's pure guessing though. > > --=20 > R=E9mi Denis-Courmont > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 13 02:54:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKToj-0001kL-Vw; Mon, 13 Aug 2007 02:54:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKToj-0001kE-5s for behave-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 02:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKTof-0001k2-Io for behave@ietf.org; Mon, 13 Aug 2007 02:54:17 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKToe-0003yQ-2j for behave@ietf.org; Mon, 13 Aug 2007 02:54:17 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7D6ra7o015496; Mon, 13 Aug 2007 09:54:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 09:53:48 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 09:53:47 +0300 Received: from esdhcp05140.research.nokia.com ([172.21.51.40]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 09:53:47 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Alfred E. Heggestad" Subject: Re: [BEHAVE] STUN fingerprint and integrity tests Date: Mon, 13 Aug 2007 09:53:51 +0300 User-Agent: KMail/1.9.6 References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <200708090918.13691.remi.denis-courmont@nokia.com> <46BB4B0C.6030204@db.org> In-Reply-To: <46BB4B0C.6030204@db.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708130953.51394.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 13 Aug 2007 06:53:47.0532 (UTC) FILETIME=[B294BCC0:01C7DD76] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Thursday 09 August 2007 20:12:44 ext Alfred E. Heggestad wrote: > okay. btw, could you add that the mapped address is 127.0.0.1:32853 in yo= ur > response vector? Hmm, yes... but... whoops, I SHOULD have used example IP addresses range...= =20 Looks like I'll have to update the vectors yet again :-( =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 13 03:16:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKUA9-0008CO-5o; Mon, 13 Aug 2007 03:16:29 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKUA7-0008Av-L9 for behave-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 03:16:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKUA7-00088O-8h for behave@ietf.org; Mon, 13 Aug 2007 03:16:27 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKUA6-0002jm-Jy for behave@ietf.org; Mon, 13 Aug 2007 03:16:27 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7D7FuSl002314; Mon, 13 Aug 2007 10:16:11 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:15:52 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:15:51 +0300 Received: from esdhcp05140.research.nokia.com ([172.21.51.40]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:15:51 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Rohan Mahy" Subject: Re: [BEHAVE] TURN: technical review by September 1 Date: Mon, 13 Aug 2007 10:15:47 +0300 User-Agent: KMail/1.9.6 References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200708091401.29705.remi.denis-courmont@nokia.com> <1A1A8416-C8B0-45CC-ACAE-EDB535551A23@ekabal.com> In-Reply-To: <1A1A8416-C8B0-45CC-ACAE-EDB535551A23@ekabal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708131015.47596.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 13 Aug 2007 07:15:51.0492 (UTC) FILETIME=[C7B90040:01C7DD79] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: behave@ietf.org, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 10 August 2007 17:14:58 ext Rohan Mahy wrote: > On Aug 9, 2007, at 4:01 AM, R=E9mi Denis-Courmont wrote: > >> I'm not sure this is really any simpler than supporting and (briefly) > >> using 1:N TCP connections. I don't think it is a practical problem > >> to limit the speed of the client to TURN server connection to the > >> speed of the slowest of the server to peer connections, but this > >> would be good to model. > > > > Say I want to send a 2gigs movie to a forked MSRP session. Should > > the fastest > > receiver wait for the slowest one? As a user, I definitely expect > > the fastest > > to not to have to wait. > > Yes, I still think it is reasonable for the fastest receiver to wait > for the slowest one. This only happens during the period where you > are forking. You probably won't start sending a 2gig movie until > you've resolved which instance you are sending it to, and therefore > selected a single fork by then. I do not quite agree. To recap, there are lots of issues with 1:N TURN/TCP= =20 sessions. =46irst, there is no TCP protocol that supports forking as of now. Contrary= to=20 my earlier assumption (my mistake), MSRP does not support forking at all.=20 Quoting draft-ietf-simple-message-sessions-19 =A75.4: (...) The node MUST also check to make sure the session is not already in use on another connection. If the session is already in use, it MUST reject the request with a 506 response. If it were legal to have multiple connections associated with the same session, a security problem would exist. If the initial SEND request is not protected, an eavesdropper might learn the URI, and use it to insert messages into the session via a different connection. Second, I am still doubtful how practical it would be to "resolve" a fork w= hen=20 the slowest peer is very slow. Third, there is no way for the client to request resetting a TCP session. O= ne=20 simple way would have been to close the TURN connection, but that only work= s=20 if we have 1:1 connection, and disallow "moving" TCP connections. =46orth, I may have missed something, but how will support for multiple TCP= not=20 contradict the security requirement NOT to allow running servers? =46ifth, and loosely related, "moving" TCP connections is not generally=20 possible. It might work for TCP-framed RTP. But it does not work with=20 any "normally TCP" protocol, such as TLS or MSRP, as these cannot cope with= =20 reordering or packet loss. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 13 09:13:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKZjk-0007fM-Ga; Mon, 13 Aug 2007 09:13:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKZjj-0007eU-LB for behave-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 09:13:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKZjj-0007dE-B7 for behave@ietf.org; Mon, 13 Aug 2007 09:13:35 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKZjh-0004Vu-Us for behave@ietf.org; Mon, 13 Aug 2007 09:13:35 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7DDCtHh003442; Mon, 13 Aug 2007 16:13:18 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 16:13:15 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 16:13:15 +0300 Received: from essapo-nirac25282.europe.nokia.com ([10.162.252.82]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 16:13:14 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: ext Rohan Mahy , jdrosen@cisco.com Date: Mon, 13 Aug 2007 15:29:13 +0300 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708131529.13949.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 13 Aug 2007 13:13:14.0997 (UTC) FILETIME=[B50C3250:01C7DDAB] X-Nokia-AV: Clean X-Spam-Score: 1.8 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: behave@ietf.org Subject: [BEHAVE] TURN: REQUESTED-IP / RELAY-ADDRESS X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, It currently seems that REQUESTED-IP is supposed to not be "obfuscated" whi= le=20 RELAY-ADDRESS is. I expect both options to contain the same IP address... i= s=20 there a reason for this apparent inconsistency? Regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 13 13:30: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 1IKdkh-0000ms-V0; Mon, 13 Aug 2007 13:30:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKdkg-0000jG-6j for behave-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdkf-0000iw-JY; Mon, 13 Aug 2007 13:30:49 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKdke-00064Y-C7; Mon, 13 Aug 2007 13:30:49 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 13 Aug 2007 10:30:47 -0700 X-IronPort-AV: i="4.19,255,1183359600"; d="scan'208"; a="170725367:sNHT48323862" 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 l7DHUlL8029172; Mon, 13 Aug 2007 10:30:47 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7DHUPF4010015; Mon, 13 Aug 2007 17:30:34 GMT From: "Dan Wing" To: "'Brian Haberman'" Subject: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt Date: Mon, 13 Aug 2007 10:30:22 -0700 Message-ID: <01b701c7ddcf$adfe2030$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.3028 In-Reply-To: <466804F3.5040400@innovationslab.net> Thread-Index: AcepBgFLbeOu0nfqSnmecsmR20l6OA0yR5kw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3307; t=1187026247; x=1187890247; 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[BEHAVE]=20Re=3A=20[magma]=20RE=3A=20[MBONED]=20FW=3A =20WGLC=3Adraft-ietf-behave-multicast-06.txt |Sender:=20; bh=Ps56Ct0ynoZNaMk0b6xAcHZDsWjqfEJ1ydfd7n+zxiE=; b=if/fZdIEfe13QFONJ3yQTvk31uFhgfNym2cS4BQIst47qapJARd8jo+bEftKsPUeVrnfpNVY +q0FwXjlYVGdY8G5IaPe9VNzjIP1k/CuSTUbgpjq+sRq4D0cOWZMQfCK; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: behave@ietf.org, 'Marshall Eubanks' , 'Alvaro Fernandez' , 'Marshall Eubanks' , mboned@ietf.org, magma@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Thursday, June 07, 2007 6:16 AM > To: Dan Wing > Cc: 'Marshall Eubanks'; mboned@ietf.org; 'Alvaro Fernandez'; > magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; Toerless Eckert > Subject: Re: [BEHAVE] Re: [magma] RE: [MBONED] FW: > WGLC:draft-ietf-behave-multicast-06.txt .... > > > > Dan Wing wrote: > >> The NAPT knows what is SSM. Couldn't it also do a Multicast Group > >> Translation for SSM groups ? Why > >> is this more difficult than, say, port translation ? > > > > It may be fairly easy -- except for rewriting the > > advertisements in SAP, > > HTTP, HTTPS (a big problem there), email, SIP, RTSP, .... > > > > And NAPTs don't do that kind of rewriting today; > > draft-ietf-behave-multicast > > is only a BCP and trying to describe what a NAT should best > > be doing as of > > its date of publication. > > > > > > If we want NAPTs to do this, we would want a different > > document that was > > standards-track and that document would define how we > > wanted NAPTs to > > perform this function. However, I don't see a successful > > path if such an > > operation would require the NAPT to have an ALG for SAP, > > HTTP, SIP, and RTSP > > and requires the NAT also rewrite those packets. We'd need > > something else. > > ALGs don't work well for a variety of reasons. > > Given that, I would suggest that the document state that > administrators of the network behind the NAPT assign sub-ranges > of the SSM space to their multicast sources. This could be done > manually or *possibly* with the tools developed by the MALLOC > WG. For the ma & pa type residential networks, I doubt you will > see multiple machines behind a NAPT sourcing SSM. For more > corporate types, the network admin can control the allocation of > the SSM range. I moved text discussing what applications should do into an appendix, as the document's BCP scope is really around NATs (rather than applications that need to handle NATs). Based on your comment above, and some other input, the text now has the following paragraph. I believe this captures your suggestion. "If multiple SSM sources on the inside of a NAT choose the same multicast group address, those sources are uniquely identifiable because their IP addresses are unique. However, if their multicast traffic is NATted and sent on the NAT's public interface, the traffic from those individual sources is no longer uniquely identifiable. This will cause problems for multicast receivers which will see an intermixing of traffic from those sources. Resolution of this issue is left for future study. In the meantime, applications that source SSM multicast traffic are encouraged to allow the user to modify the multicast SSM address so that users can avoid this problem if that application is placed behind a NAT." The text doesn't quite go so far to say that a range has to be assigned a priori. But let me know if it is acceptable. I have not submitted -09, but a preview is here if anyone wants to see the full context: http://svn.resiprocate.org/rep/ietf-drafts/behave/draft-ietf-behave-multicast- 09.txt -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 13 13:32:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdmE-0001YU-QX; Mon, 13 Aug 2007 13:32:26 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKdmD-0001YL-Mf for behave-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:32:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdmD-0001YD-D1; Mon, 13 Aug 2007 13:32:25 -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 1IKdmC-00068e-4S; Mon, 13 Aug 2007 13:32:25 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2007 10:32:23 -0700 X-IronPort-AV: i="4.19,255,1183359600"; d="scan'208"; a="513011753:sNHT49430096" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7DHWNAx019462; Mon, 13 Aug 2007 10:32:23 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7DHWMiF023384; Mon, 13 Aug 2007 17:32:23 GMT From: "Dan Wing" To: , , Date: Mon, 13 Aug 2007 10:32:20 -0700 Message-ID: <01b801c7ddcf$e71d62e0$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.3028 In-Reply-To: <000601c7b4b4$46c224f0$5f17120a@china.huawei.com> Thread-Index: Ace0YtOhtzS6gCiiQkmvBKD7ohFyDQAUEzsgCkcjxdA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3006; t=1187026343; x=1187890343; 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[magma]=20multicast=20senders=20behind=20an=20IGMP=20 Proxy |Sender:=20; bh=6ZdFdj9F6ZIWscEZuefQU3edM+p7bd2dFYV2vD5Pm/g=; b=AtWcJoTdM0D3o66YGeZMsDjjbTMZazNDtjV9AKoIV4dLBKg3zjoMMA7WHCztij98wf/oqw// P6BwfBaBUmqr0NMXrwwytar3xkx5C0AD16s7jTaS2rKA99xq18q9sY/utCRsFtzULhZxED7Cna vDqtuBXIdWmik/G9V+/SF28lU=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [BEHAVE] RE: [magma] multicast senders behind an IGMP Proxy X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Prashant Jhingran [mailto:prashantj@huawei.com] > Sent: Friday, June 22, 2007 3:01 AM > To: 'Dan Wing'; behave@ietf.org; magma@ietf.org > Cc: 'Toerless Eckert' > Subject: RE: [magma] multicast senders behind an IGMP Proxy > > Hi, > > I would like to suggest following methods to resolve this > issue: > > - TTL scoping can be used to control the distribution of > multicast traffic with the objective of easing stress on > scarce resources viz. bandwidth. Toerless and I went back and forth on this suggestion, and finally decided on the following text in the appendix of multicast-09 (which we're about to publish): A multicast source that wants its traffic to not traverse a router (e.g., leave a home network) may find it useful to send traffic with IP TTL=1. Both ASM and SSM sources may find this useful. -d > - Another way (and probably a preferred choice) would be to > use administratively scoped IP multicast [rfc2365]. > > Moreover, these methods can (to a certain extent) help in > achieving privacy. > > PS: "sending audio to all of your IP-enabled speakers > distributed throughout your house" seems to be very > ambitious usage of multicast :-) > > Regards, > Prashant Jhingran > > Huawei Technologies > +91-80-41117676 Ext -7175 > +91-9448927814 > > "Sing, dance, serve, meditate and celebrate" > - www.artofliving.org > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, June 22, 2007 5:48 AM > To: behave@ietf.org; magma@ietf.org > Cc: Toerless Eckert > Subject: [magma] multicast senders behind an IGMP Proxy > > During WGLC, there was clear consensus from MAGMA and MBONED > that supporting > multicast senders behind the IGMP Proxy device was > desirable. However, > while wrapping up draft-ietf-behave-multicast-07, Toerless > pointed out a > problem with multicast senders behind an IGMP Proxy device > (any IGMP Proxy > device -- not just an IGMP Proxy in a NAT). > > The problem is that any multicast flows generated behind the > IGMP proxy will > be forwarded up the access link towards the Internet -- even > for flows that > you want to keep within your network. Concrete examples of > generating > multicast within a home network include: > > * sending audio to all of your IP-enabled speakers > distributed > throughout your house, > * IP-enabled intercom system, > * HD video to multiple telvision sets (kitchen and living > room). > > In each case, you "could" do unicast, but especially for HD > one might easily > envision not having sufficient bandwidth or not wanting to > waste the > bandwidth (which might be used for other things). > > Does anyone have suggestions on how this might be resolved? > > -d > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 07:46:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuqs-000241-5c; Tue, 14 Aug 2007 07:46:22 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKuqr-0001zc-7k for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 07:46:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuqq-0001yE-Sg for behave@ietf.org; Tue, 14 Aug 2007 07:46:20 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKuqq-0000HL-8s for behave@ietf.org; Tue, 14 Aug 2007 07:46:20 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7EBk8M7018792; Tue, 14 Aug 2007 14:46:15 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:46:10 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:46:10 +0300 Received: from esdhcp041244.research.nokia.com ([172.21.41.244]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:46:09 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, ext Dan Wing , jdrosen@cisco.com, philip_matthews@magma.ca Date: Tue, 14 Aug 2007 14:46:09 +0300 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708141446.10170.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 14 Aug 2007 11:46:10.0000 (UTC) FILETIME=[B51EAD00:01C7DE68] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [BEHAVE] rfc3489bis-08 last minute comment: 401 still problematic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, It was recently agreed that incorrect usernames and incorrect message=20 integrity hashes would be treated identically by STUN servers, which is to= =20 say, yield a 401 error. The idea is that an attacker cannot probe for valid= =20 usernames separately from the shared secret. However, at the moment, this is still possible because stale nonce=20 verification is done AFTER username validation, but BEFORE message integrit= y=20 validation. IMHO, it should be done after both, otherwise a bad username=20 yields 401, but a bad message integrity along with a bad nonce yields 438. Therefore, I would suggest replacing that (=A710.2.2) " o If the NONCE is no longer valid, the server MUST generate an error response with an error code of 438 (Stale Nonce). This response MUST include a NONCE and REALM attribute. o Using the password associated with the username in the USERNAME attribute, compute the value for the message-integrity as described in Section 14.4. If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized). It MUST include a REALM and NONCE attribute. " with this: " o Using the password associated with the username in the USERNAME attribute, compute the value for the message-integrity as described in Section 14.4. If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized). It MUST include a REALM and NONCE attribute. o Otherwise, if the NONCE is no longer valid, the server MUST generate an error response with an error code of 438 (Stale Nonce). This response MUST include a NONCE and REALM attribute. " Best regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 09:00:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKw0W-0006KL-Ku; Tue, 14 Aug 2007 09:00:24 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKw0G-0006AT-EL for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 09:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKw0G-0006AB-1G for behave@ietf.org; Tue, 14 Aug 2007 09:00:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKw0E-0000jW-QP for behave@ietf.org; Tue, 14 Aug 2007 09:00:08 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Aug 2007 09:00:06 -0400 X-IronPort-AV: i="4.19,259,1183348800"; d="scan'208"; a="67949542:sNHT147022556" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7ED04r1006170; Tue, 14 Aug 2007 09:00:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7ED04md002384; Tue, 14 Aug 2007 13:00:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:00:04 -0400 Received: from [64.101.155.162] ([64.101.155.162]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:00:03 -0400 Message-ID: <46C1A762.3010004@cisco.com> Date: Tue, 14 Aug 2007 09:00:18 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <200708141446.10170.remi.denis-courmont@nokia.com> In-Reply-To: <200708141446.10170.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Aug 2007 13:00:03.0813 (UTC) FILETIME=[07E0D950:01C7DE73] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3210; t=1187096404; x=1187960404; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20rfc3489bis-08=20last=20minute=20comment=3A=20401=20st ill=20problematic |Sender:=20 |To:=20=3D?ISO-8859-1?Q?R=3DE9mi_Denis-Courmont?=3D=0A=20; bh=tsIqBu3hlkWx8Il3JtIBSMVeUvjCOg25G+5SztXUs/k=; b=pWVv4Cwz8kNcoixN+6HFAHHKEymxXBkXfhWYEcOa9OGb00abgdfCCGTwdx2NWYeOBIJ+/hOt yFh8SEjeUwYz1rPBuzfDpxJKg8EORl1KCH5E5enmyznoqNw6TSe1A48O; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: behave@ietf.org, philip_matthews@magma.ca, ext Dan Wing Subject: [BEHAVE] Re: rfc3489bis-08 last minute comment: 401 still problematic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Well, this is a dual-edged sword. Though you are correct, that such a change would stop a user from being able to probe for usernames separately from passwords, it does allow an attacker to cause the server to compute message integrity for any request, as long as the attacker knows a valid username. With the current ordering, they need to know the current username and have a valid nonce. Having a valid nonce helps eliminate the impact of DDOS attacks. With your change, if an attacker can guess a username, they can have a botnet army each send requests with valid usernames and invalid nonces and MI, and cause the server to do lots of hashing without return routability. I think the current text is the lesser of two evils in this. -Jonathan R. Rémi Denis-Courmont wrote: > Hello, > > It was recently agreed that incorrect usernames and incorrect message > integrity hashes would be treated identically by STUN servers, which is to > say, yield a 401 error. The idea is that an attacker cannot probe for valid > usernames separately from the shared secret. > > However, at the moment, this is still possible because stale nonce > verification is done AFTER username validation, but BEFORE message integrity > validation. IMHO, it should be done after both, otherwise a bad username > yields 401, but a bad message integrity along with a bad nonce yields 438. > > Therefore, I would suggest replacing that (§10.2.2) > " > o If the NONCE is no longer valid, the server MUST generate an error > response with an error code of 438 (Stale Nonce). This response > MUST include a NONCE and REALM attribute. > > o Using the password associated with the username in the USERNAME > attribute, compute the value for the message-integrity as > described in Section 14.4. If the resulting value does not match > the contents of the MESSAGE-INTEGRITY attribute, the server MUST > reject the request with an error response. This response MUST use > an error code of 401 (Unauthorized). It MUST include a REALM and > NONCE attribute. > " > with this: > " > o Using the password associated with the username in the USERNAME > attribute, compute the value for the message-integrity as > described in Section 14.4. If the resulting value does not match > the contents of the MESSAGE-INTEGRITY attribute, the server MUST > reject the request with an error response. This response MUST use > an error code of 401 (Unauthorized). It MUST include a REALM and > NONCE attribute. > > o Otherwise, if the NONCE is no longer valid, the server MUST > generate an error response with an error code of 438 (Stale Nonce). > This response MUST include a NONCE and REALM attribute. > " > > Best regards, > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 09:06: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 1IKw6m-00032J-JM; Tue, 14 Aug 2007 09:06:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKw6l-00031z-EU for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 09:06:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKw6l-00031p-42 for behave@ietf.org; Tue, 14 Aug 2007 09:06:51 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKw6k-0003cl-82 for behave@ietf.org; Tue, 14 Aug 2007 09:06:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7ED6VMk031017; Tue, 14 Aug 2007 16:06:45 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:05:19 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:05:19 +0300 Received: from esdhcp041244.research.nokia.com ([172.21.41.244]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:05:18 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Jonathan Rosenberg" Date: Tue, 14 Aug 2007 16:05:19 +0300 User-Agent: KMail/1.9.6 References: <200708141446.10170.remi.denis-courmont@nokia.com> <46C1A762.3010004@cisco.com> In-Reply-To: <46C1A762.3010004@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708141605.19285.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 14 Aug 2007 13:05:18.0983 (UTC) FILETIME=[C3BBF970:01C7DE73] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: behave@ietf.org, philip_matthews@magma.ca, ext Dan Wing Subject: [BEHAVE] Re: rfc3489bis-08 last minute comment: 401 still problematic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 14 August 2007 16:00:18 ext Jonathan Rosenberg wrote: > Well, this is a dual-edged sword. > > Though you are correct, that such a change would stop a user from being > able to probe for usernames separately from passwords, it does allow an > attacker to cause the server to compute message integrity for any > request, as long as the attacker knows a valid username. With the > current ordering, they need to know the current username and have a > valid nonce. Having a valid nonce helps eliminate the impact of DDOS > attacks. With your change, if an attacker can guess a username, they can > have a botnet army each send requests with valid usernames and invalid > nonces and MI, and cause the server to do lots of hashing without return > routability. True. Then perhaps NONCE should be checked before both USERNAME and M-I. It= =20 cannot depend on the username anyway (since the server must return a valid= =20 NONCE to an unauthenticated request). No? =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 09:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwNJ-0007jf-Fu; Tue, 14 Aug 2007 09:23:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKwNH-0007jR-Mb for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 09:23:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwNH-0007jE-CB for behave@ietf.org; Tue, 14 Aug 2007 09:23:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKwNG-00044g-TU for behave@ietf.org; Tue, 14 Aug 2007 09:23:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Aug 2007 09:23:55 -0400 X-IronPort-AV: i="4.19,259,1183348800"; d="scan'208"; a="128826815:sNHT50282318" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7EDNsSS001260; Tue, 14 Aug 2007 09:23:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7EDNOja022527; Tue, 14 Aug 2007 13:23:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:23:49 -0400 Received: from [64.101.247.250] ([64.101.247.250]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:23:48 -0400 Message-ID: <46C1ACF3.7000202@cisco.com> Date: Tue, 14 Aug 2007 09:24:03 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Alfred E. Heggestad" Subject: Re: [BEHAVE] STUN fingerprint and integrity tests References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <200708081203.19729.remi.denis-courmont@nokia.com> <46BA4268.2060204@db.org> <200708090918.13691.remi.denis-courmont@nokia.com> <46BB4B0C.6030204@db.org> In-Reply-To: <46BB4B0C.6030204@db.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Aug 2007 13:23:48.0913 (UTC) FILETIME=[594DDA10:01C7DE76] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2873; t=1187097834; x=1187961834; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20fingerprint=20and=20integrity=20tes ts |Sender:=20 |To:=20=22Alfred=20E.=20Heggestad=22=20; bh=qrZyExL9WXiPuIf9qMnd+IJVFNIDrBJm7wUz5pKbyoY=; b=JzA/XZB0r7xs5x3Dk6Fi9Wd5nOt8Pu0p4sqkYciz64qxxG4YoWK5qt3JFn+MsxwgBRz2XZNR 0jRpe/clDP3hxBOPq443TJSr/+pBh0yVgcEZMNzNBNCeq7VWKueZngIU; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org An important point of clarification here. Though FINGERPRINT is currently the only attribute beyond the MI, there could potentially be others in the future so you can't depend on it being the only one. So inserting a dummy FINGERPRINT won't help. A different idea which might help is that the hash is computed by *starting* with the attributes, going through all of the attributes up to but not including M-I, and then including the STUN message header as the *last* attribute, with the length instead set as equal to the length of the data that the hash is computed over. This would mean that, you could do the parse and integrity computation simultaneously. -Jonathan R. Alfred E. Heggestad wrote: > RĂ©mi Denis-Courmont wrote: >> On Thursday 09 August 2007 01:23:36 ext Alfred E. Heggestad wrote: >>> Remi, many thanks for doing this. It looks ok after I fixed some bugs >>> in my >>> code. Is the 64-bytes HMAC-SHA1 padding removed from rfc3489-bis, btw? >> >> Yes. That text has been removed a bunch of revisions ago. You'd have >> to ask the editors why, but it was simply a "bad" idea - HMAC-SHA1 >> already pads internally anyway. >> > > ok thanks, that makes the implementation much simpler. > > with the current MESSAGE-INTEGRITY calculation, it means that the > receiver must > modify the incoming data before calculating HMAC-SHA1, in case the > FINGERPRINT > attribute is present after M-I. it also means that the STUN receiver > must parse > the whole message first, to check if the FINGERPRINT attribute is > present, and > the subtract 8 from the STUN Header length field. > > rfc3489bis-08 says that before calculating the M-I, a dummy M-I must be > inserted > into the message (to get the correct length). would it not be better to > include > the FINGERPRINT as a "dummy" attribute also? If that was the case, the > length > fields needs not modification at all. > > >>> could I ask that the USERNAME padding is changed from 0x20 to 0x00 ? >> >> rfc3489bis-08 says attribute padding can be anything. I am purposedly >> using white spaces instead of nuls to root out incorrect C >> implementations. I should perhaps have used 0x41 to make it more >> obvious :) >> > > okay. btw, could you add that the mapped address is 127.0.0.1:32853 in your > response vector? > > > > /alfred > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 09:24:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwOC-00089v-DM; Tue, 14 Aug 2007 09:24:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKwOA-000871-Hb for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 09:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwOA-00086t-83 for behave@ietf.org; Tue, 14 Aug 2007 09:24:50 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKwO9-0001M2-0h for behave@ietf.org; Tue, 14 Aug 2007 09:24:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Aug 2007 09:24:49 -0400 X-IronPort-AV: i="4.19,259,1183348800"; d="scan'208"; a="128826887:sNHT47584610" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7EDOmFQ001614 for ; Tue, 14 Aug 2007 09:24:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7EDOVjQ022900 for ; Tue, 14 Aug 2007 13:24:48 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:24:44 -0400 Received: from [64.101.247.250] ([64.101.247.250]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:24:44 -0400 Message-ID: <46C1AD2A.4080706@cisco.com> Date: Tue, 14 Aug 2007 09:24:58 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [BEHAVE] Minor concern about one of the milestones References: <2A6464F7-9BD9-43B6-B701-6C48E0CAE3EB@cisco.com> In-Reply-To: <2A6464F7-9BD9-43B6-B701-6C48E0CAE3EB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 13:24:44.0335 (UTC) FILETIME=[7A5693F0:01C7DE76] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1454; t=1187097888; x=1187961888; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Minor=20concern=20about=20one=20of=20the=2 0milestones |Sender:=20 |To:=20Cullen=20Jennings=20; bh=2NeidSonWXMZRuoWT0SZZpJMNaFClP6WxaDOxSTurcs=; b=mP8TyHQjY4A4FHsUVR7T2ma7oR/ldc5ZeSfzYMFrRRMaK92r81ipQPrTN5X5FZEsGIM7AW4Z Yy8GoXzBZ4U9JCAebxGnS75mnOdEc2wDIxl/7emy2p/H44BlGM3AsOfX; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I think there was consensus in the room in chicago to make this either informational or experimental. -Jonathan R. Cullen Jennings wrote: > > One of our milestones is > > Submit standards-track document that describes how an application can > determine the type of NAT it is behind > > I think it is very hard for an application to reliably do this except > under environments where all the traffic to the NAT is controlled. > (Basically this was the general limitation of RFC 3489). I hope that the > document for this milestone is more an approach to characterizing and > testing behavior of NATs and is not a general suggestion that an > application might be able to figure out what type of NAT it is behind > then modify the applications behavior based on the type of NAT is is > behind. I seem to recall the old milestone was more along the lines of > testing but I can not find a copy of it. > > Cullen > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 09:44:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwh7-0005fT-FC; Tue, 14 Aug 2007 09:44:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKwh6-0005fN-8s for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 09:44:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwh5-0005fF-VT for behave@ietf.org; Tue, 14 Aug 2007 09:44:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKwh4-0001m5-Jy for behave@ietf.org; Tue, 14 Aug 2007 09:44:23 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 06:44:22 -0700 X-IronPort-AV: i="4.19,259,1183359600"; d="scan'208"; a="199802165:sNHT51731379" 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 l7EDiMT7003350; Tue, 14 Aug 2007 06:44:22 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7EDhnFa019265; Tue, 14 Aug 2007 13:44:21 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:44:17 -0400 Received: from [64.101.247.250] ([64.101.247.250]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:44:16 -0400 Message-ID: <46C1B1BF.9030404@cisco.com> Date: Tue, 14 Aug 2007 09:44:31 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <200708141446.10170.remi.denis-courmont@nokia.com> <46C1A762.3010004@cisco.com> <200708141605.19285.remi.denis-courmont@nokia.com> In-Reply-To: <200708141605.19285.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Aug 2007 13:44:16.0812 (UTC) FILETIME=[35305EC0:01C7DE79] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3737; t=1187099062; x=1187963062; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20rfc3489bis-08=20last=20minute=20comment=3A=20401=20st ill=20problematic |Sender:=20; bh=T43g+pVXM9sErMjasH/HxFhqinTYLQ0jN8+XPDE1TYw=; b=jwAzn77O2o4yR/P541MQJUW5eGC9QAQ6BMWdj7RfcVqNvjb8ZQCnLWP4YCjE02UFw0gDDQ3g e2PIureH8lRoD4eWPvW9FMBfTww9Sva+9wgiWfhIasm8JrX3aKYH0mwx; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: behave@ietf.org, philip_matthews@magma.ca, ext Dan Wing Subject: [BEHAVE] Re: rfc3489bis-08 last minute comment: 401 still problematic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org OK, here is the text now:
After the server has done the basic processing of a request, it performs the checks listed below in the order specified: If the message does not contain a MESSAGE-INTEGRITY attribute, the server MUST generate an error response with an error code of 401 (Unauthorized). This response MUST include a REALM value. It is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server. The response MUST include a NONCE, selected by the server. If the message contains a MESSAGE-INTEGRITY attribute, but is missing the USERNAME, REALM or NONCE attributes, the server MUST generate an error response with an error code of 400 (Bad Request). If the NONCE is no longer valid, the server MUST generate an error response with an error code of 438 (Stale Nonce). This response MUST include a NONCE and REALM attribute. If the username in the USERNAME attribute is not valid, the server MUST generate an error response with an error code of 401 (Unauthorized). This response MUST include a REALM value. It is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server. The response MUST include a NONCE, selected by the server. Using the password associated with the username in the USERNAME attribute, compute the value for the message-integrity as described in . If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized). It MUST include a REALM and NONCE attribute. If these checks pass, the server continues to process the request or indication. Any response generated by the server MUST include the MESSAGE-INTEGRITY attribute, computed using the username and password utilized to authenticate the request. The REALM, NONCE, and USERNAME attributes SHOULD NOT be included.
That work? -Jonathan R. Rémi Denis-Courmont wrote: > On Tuesday 14 August 2007 16:00:18 ext Jonathan Rosenberg wrote: >> Well, this is a dual-edged sword. >> >> Though you are correct, that such a change would stop a user from being >> able to probe for usernames separately from passwords, it does allow an >> attacker to cause the server to compute message integrity for any >> request, as long as the attacker knows a valid username. With the >> current ordering, they need to know the current username and have a >> valid nonce. Having a valid nonce helps eliminate the impact of DDOS >> attacks. With your change, if an attacker can guess a username, they can >> have a botnet army each send requests with valid usernames and invalid >> nonces and MI, and cause the server to do lots of hashing without return >> routability. > > True. Then perhaps NONCE should be checked before both USERNAME and M-I. It > cannot depend on the username anyway (since the server must return a valid > NONCE to an unauthenticated request). > > No? > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 09:46:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwis-0006kN-B8; Tue, 14 Aug 2007 09:46:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKwir-0006io-HW for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 09:46:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwir-0006ie-7N for behave@ietf.org; Tue, 14 Aug 2007 09:46:13 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKwiq-0004g9-O3 for behave@ietf.org; Tue, 14 Aug 2007 09:46:13 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7EDjtIT026665; Tue, 14 Aug 2007 16:46:08 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:45:53 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:45:53 +0300 Received: from esdhcp041244.research.nokia.com ([172.21.41.244]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:45:53 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Jonathan Rosenberg" Date: Tue, 14 Aug 2007 16:45:52 +0300 User-Agent: KMail/1.9.6 References: <200708141446.10170.remi.denis-courmont@nokia.com> <200708141605.19285.remi.denis-courmont@nokia.com> <46C1B1BF.9030404@cisco.com> In-Reply-To: <46C1B1BF.9030404@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708141645.53135.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 14 Aug 2007 13:45:53.0173 (UTC) FILETIME=[6E9FE450:01C7DE79] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: behave@ietf.org, philip_matthews@magma.ca, ext Dan Wing Subject: [BEHAVE] Re: rfc3489bis-08 last minute comment: 401 still problematic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 14 August 2007 16:44:31 ext Jonathan Rosenberg wrote: > That work? Looks good, thanks. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 13:14:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzyl-0002Zr-1L; Tue, 14 Aug 2007 13:14:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IKzyk-0002Zm-6F for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 13:14:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzyj-0002Zd-Qu for behave@ietf.org; Tue, 14 Aug 2007 13:14:49 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKzyi-0004JX-P6 for behave@ietf.org; Tue, 14 Aug 2007 13:14:49 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 14 Aug 2007 10:14:48 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="170940189:sNHT58934457" 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 l7EHEmpg002197; Tue, 14 Aug 2007 10:14:48 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7EHEka1028877; Tue, 14 Aug 2007 17:14:47 GMT From: "Dan Wing" To: Date: Tue, 14 Aug 2007 10:14:46 -0700 Message-ID: <04bd01c7de96$9de5eb20$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.3028 Thread-Index: AcfelliUjiF67ldmSmaScFU9FAT/uAAAAeAA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8009; t=1187111688; x=1187975688; 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:=20WGLC=20finished,=20draft-ietf-behave-nat-icmp-04.txt |Sender:=20; bh=9cZWZ4N64+FU/fW+bwv9Ekb8FDDja19KONDwJFF9Yys=; b=Di0Bignp0q2jwNWf1o2gLhIRiPZRsQySE2l0RV4UOrIda+6THw2uZqfkH8us3Sr0kvTeBNse 1Gx30C/sfbCovG/wpItsmz3/8A+FOhhGImVja/a/B34UHJKhs5bvXjsN1B6T5fpUYRc0h0QQj/ w5gOwn56q865dMFRnyKYDnB0w=; 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: 963faf56c3a5b6715f0b71b66181e01a Cc: baford@mit.edu Subject: [BEHAVE] WGLC finished, draft-ietf-behave-nat-icmp-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org WGLC finished for draft-ietf-behave-nat-icmp-04.txt with no comments. I just requested publication of the document. The PROTO writeup is below. -d ----- PROTO (RFC4858) writeup for: draft-ietf-behave-nat-icmp-04 August 14, 2007 written by: Dan Wing, dwing@cisco.com (1.a) Who is the Document Shepherd for this document? Dan Wing, dwing@cisco.com Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed extensively within BEHAVE, TCPM (Joe Touch), and authors of draft-ietf-tcpm-icmp-attacks and RFC4963. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. ICMP payload validation (section 4.1 in the document) encourages NATs to validate ICMP packets. The document shepherd is concerned this may cause difficulties with ICMP extensions that the NAT is unaware of. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It represents a relatively solid WG consensus. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No such concerns have been raised. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. All nits are satisfied. Document is intended to be BCP. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. All references have been double-checked and appear accurate. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? There are no IANA considerations for this document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Document contains no formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the ICMP protocol. The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No significant controversy. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? This is a BCP document, and describes current practice in existing NATs, and describes some improvements to current practice. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? They have been acknowledged in the acknowledgements section. If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Dan Wing, dwing@cisco.com Responsible AD: Magnus Westerlund, magnus.westerlund@ericsson.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 13:31:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0Ej-0004fz-9G; Tue, 14 Aug 2007 13:31:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IL0Ei-0004ft-4j for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 13:31:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0Eh-0004fk-RN for behave@ietf.org; Tue, 14 Aug 2007 13:31:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL0Eg-0001GU-JS for behave@ietf.org; Tue, 14 Aug 2007 13:31:19 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 10:31:18 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="199936756:sNHT47363319" 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 l7EHVIae014463 for ; Tue, 14 Aug 2007 10:31:18 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7EHVHa1006722 for ; Tue, 14 Aug 2007 17:31:17 GMT From: "Dan Wing" To: "'Behave WG'" Date: Tue, 14 Aug 2007 10:31:17 -0700 Message-ID: <04bf01c7de98$ec189de0$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.3028 In-Reply-To: <46C1AD2A.4080706@cisco.com> Thread-Index: AcfedoCxthtQCBWqQpa8WgtJW2BfQwAIGUOQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3432; t=1187112678; x=1187976678; 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:=20consensus=20check=3A=20remove=20behavior-discovery=20from=20s tandards-track |Sender:=20; bh=B/rtUhi3T652ayy8XlhN2jX8O698YzjIE4LKvU3MICs=; b=KXdKTOpfEyUHjPqn1srxn/KSbUjz1dTlqdSkCvcHL4aNHdErGRFu03aAtt/SvsATEYvLqSlz QdXvWm8ohDxuPvUyTFUa75l6vjJ/o7znhWeZ3ZRRcOYzthCKyUp+7NZZ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [BEHAVE] consensus check: remove behavior-discovery from standards-track X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I expect to finish the BEHAVE minutes today, but the relevant part of the minutes from this discussion in Chicago is below. I'd like to make sure the mailing list agrees with removing draft-ietf-behave-behavior-discovery and its associated milestone from standards track. This means the document status (and associated milestone) would change to Experimental or change to Informational. (Per the minutes, below, Bruce and Derek will be preparing text and we will decide, as a separate action, if it should be Informational or Experimental.) If you have objections to making draft-ietf-behave-behavior-discovery a non-standards-track document, please reply to this email. -d ----- excerpt from BEHAVE's IETF-69 minutes (not yet published): ... * Current draft is proposed standard. Bruce suggests this should be demoted to Experimental. It's important to have a document that explains what was broken about RFC3489, and why it was broken. Still some value in diagnosing how NATs work. comments on Experimental: Remi: The only protocol I'm aware of that does this is Teredo, which has its own mechanism, so it's not affected by this proposed change. Philip: is anyone using behavior-discovery? Bruce: if anyone needs this functionality, they're doing RFC3489. Bruce knows of 3 people using this, and what they're doing is trying to determine if they need a relay server. In some cases, where they know who they will be communicating to, this works fine. In other cases, they aren't using it appropriately. I want to strenghen the applicability statement to make this clearer. Philip: The one interesting use, which could be hurt by making this Experimental, is to diagnose problems in running ICE. p2p-sip might be hurt by this lack of diagnostics. Bruce: p2p is one possible application that could benefit from behavior-discovery -- with enough tests, you could perhaps determine if you could be a superpeer. However, such a determination would be experimental at this point. Philip: How quickly do we need to decide if this should be experimental. Jonathan: I think the change to Experimental is appropriate, and anything using this is unreliable. It's the difference between working 95% and 99.99% of the time. Magnus: There are grounds for defining this as an experiment and deciding how well this works before moving forward. "Do we have an experiment". It seems we do have one. Bruce: Today this is useful for diagnostics and instrumentation. We do not have a clear view on how this can be useful for changing application behavior. Francois Audet: This should be Informational, not Experimental. People have used techniques like this for a long time, even before STUN, to detect bad NATs. The fear is people will look at behavior-discovery and say "this is easier than ICE, let's use it", but making it Experimental won't necessarily accomplish that goal. It certainly doesn't belong in standards-track. Dan asked for hum on standards-track: a quiet, yet strong consensus to demote away from standards-track. Bruce: we'll adjust the applicability statement and bring that to the list. ... _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 14:47: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 1IL1QR-0001HB-TG; Tue, 14 Aug 2007 14:47:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IL1QP-0001H5-Pp for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 14:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1QP-0001Gx-GK for behave@ietf.org; Tue, 14 Aug 2007 14:47:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL1QO-0002sM-8J for behave@ietf.org; Tue, 14 Aug 2007 14:47:29 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 11:47:27 -0700 X-IronPort-AV: i="4.19,261,1183359600"; d="scan'208"; a="199984878:sNHT45445554" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7EIlRpT031820; Tue, 14 Aug 2007 11:47:27 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l7EIlPiG015203; Tue, 14 Aug 2007 18:47:25 GMT In-Reply-To: <46C1AD2A.4080706@cisco.com> References: <2A6464F7-9BD9-43B6-B701-6C48E0CAE3EB@cisco.com> <46C1AD2A.4080706@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] Minor concern about one of the milestones Date: Tue, 14 Aug 2007 11:46:08 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1939; t=1187117247; x=1187981247; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20Minor=20concern=20about=20one=20of=20the=2 0milestones |Sender:=20; bh=pspK8ht59C+DFhFj8LTZjOQLdtpKlHKkdO6iBRo9q4A=; b=OtBsQgjOvvJeK3ay5BQ4eJxUe5ee6ofycNqXsePTYeixgkoKc07asEHEVIXDDbo4sJ7iPEmB /GB45t5CVXiTwYo/lHI27noQ+T91tyk+MewTQ8c0ZrFKSx4v83BhbUPn; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org ok - I certainly understand making it informational but on experimental, I would ask what is the experiment? If the experiment is "can an application with a single IP behind a NAT reliably predict the NAT behavior?", well then I think we already know the answer to this experiment. Anyways, I was not in the room so sorry for missing the discussion around this. Cullen On Aug 14, 2007, at 6:24 AM, Jonathan Rosenberg wrote: > I think there was consensus in the room in chicago to make this > either informational or experimental. > > -Jonathan R. > > Cullen Jennings wrote: >> One of our milestones is >> Submit standards-track document that describes how an application >> can determine the type of NAT it is behind >> I think it is very hard for an application to reliably do this >> except under environments where all the traffic to the NAT is >> controlled. (Basically this was the general limitation of RFC >> 3489). I hope that the document for this milestone is more an >> approach to characterizing and testing behavior of NATs and is not >> a general suggestion that an application might be able to figure >> out what type of NAT it is behind then modify the applications >> behavior based on the type of NAT is is behind. I seem to recall >> the old milestone was more along the lines of testing but I can >> not find a copy of it. >> Cullen >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 15:50:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL2Ox-00072B-9F; Tue, 14 Aug 2007 15:50:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IL2Ov-00071w-5r for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 15:50:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL2Ou-00071j-P3 for behave@ietf.org; Tue, 14 Aug 2007 15:50:00 -0400 Received: from www.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL2Ou-0008Iy-8e for behave@ietf.org; Tue, 14 Aug 2007 15:50:00 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 96C1E3A02022; Tue, 14 Aug 2007 12:49:59 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 3877F3A02020; Tue, 14 Aug 2007 12:49:55 -0700 (PDT) Message-ID: <46C20762.3030203@acm.org> Date: Tue, 14 Aug 2007 12:49:54 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] Re: rfc3489bis-08 last minute comment: 401 still problematic References: <200708141446.10170.remi.denis-courmont@nokia.com> <46C1A762.3010004@cisco.com> <200708141605.19285.remi.denis-courmont@nokia.com> <46C1B1BF.9030404@cisco.com> In-Reply-To: <46C1B1BF.9030404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: behave@ietf.org, philip_matthews@magma.ca, ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jonathan Rosenberg wrote: > OK, here is the text now: > >
> > > After the server has done the basic processing of a request, it > performs the checks listed below in the order specified: > > > > If the message does not contain a MESSAGE-INTEGRITY attribute, > the server MUST > generate an error response with an error code of > 401 (Unauthorized). This response MUST include a REALM value. It is > RECOMMENDED that the REALM value be the domain name of > the provider of the STUN server. The response MUST > include a NONCE, selected by the server. > > > > If the message contains a MESSAGE-INTEGRITY > attribute, but is missing the USERNAME, REALM or > NONCE attributes, the server MUST generate an error > response with an error code of 400 (Bad Request). > > > > If the NONCE is no longer valid, the server MUST > generate an error response with an error code of 438 > (Stale Nonce). This response MUST include a NONCE and REALM > attribute. > > > > If the username in the USERNAME attribute is not valid, the server > MUST generate an error response with an error code of > 401 (Unauthorized). This response MUST include a REALM value. It is > RECOMMENDED that the REALM value be the domain name of > the provider of the STUN server. The response MUST > include a NONCE, selected by the server. > > > Using the password associated with the username in > the USERNAME attribute, > compute the value for the message-integrity as > described in > . If the > resulting value does not match the contents of the > MESSAGE-INTEGRITY attribute, the server MUST > reject the request with an error response. This > response MUST use an error code of 401 (Unauthorized). It MUST > include a REALM > and NONCE attribute. > > > > > If these checks pass, the server continues to process the > request or indication. Any response generated by the server Per 10.2, the long-term credential mechanism cannot be used to protect indications. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 14 16:36:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL37h-0000BU-1m; Tue, 14 Aug 2007 16:36:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IL37f-0000BP-OR for behave-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 16:36:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL37f-0000BH-Eq for behave@ietf.org; Tue, 14 Aug 2007 16:36:15 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL37d-0005gw-Vw for behave@ietf.org; Tue, 14 Aug 2007 16:36:15 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 13:36:13 -0700 X-IronPort-AV: i="4.19,261,1183359600"; d="scan'208"; a="200040541:sNHT72267210" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7EKaDSq020679 for ; Tue, 14 Aug 2007 13:36:13 -0700 Received: from dwingwxp01 (dhcp-128-107-100-242.cisco.com [128.107.100.242]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l7EKaDgB013214 for ; Tue, 14 Aug 2007 20:36:13 GMT From: "Dan Wing" To: "'Behave WG'" Date: Tue, 14 Aug 2007 13:36:13 -0700 Message-ID: <05c401c7deb2$c1983070$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.3028 Thread-Index: AcfesqqSnatS39c3QTCqlxFnzyVTOAAAASrA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8531; t=1187123773; x=1187987773; 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:=20pub=20requested=3A=20draft-ietf-behave-p2p-state-03.txt |Sender:=20; bh=1e15T5V5JzL5azqP/hBwWUk5+0Z1HCTQuHoDYclFhSs=; b=VkZQmkEpRafC1KIC1l4/l23i6yclsFq2wIaHGTYfrV6MClOcX1CDJ1Q9ZGKRAG6uguDzFEal /3O0ETTqsyKpu4VpleSchoh3fJ1lSmz7a5TOZspz7pSAh9ffJuF7B4Jb; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a492040269d440726bfd84680622cee7 Subject: [BEHAVE] pub requested: draft-ietf-behave-p2p-state-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org FYI, the second WGLC for draft-ietf-behave-p2p-state-03.txt completed with no comments received during the WGLC period. I have requested publication of draft-ietf-behave-p2p-state-03.txt. PROTO writeup is below. -d ----- PROTO (RFC4858) writeup for: draft-ietf-behave-p2p-state-03.txt August 14, 2007 written by: Dan Wing, dwing@cisco.com (1.a) Who is the Document Shepherd for this document? Dan Wing, dwing@cisco.com Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, it has been reviewed by some members of the BEHAVE working group and some members of SIP-P2P. The document shepherd believes the document accurately describes today's state-of-the-art for NAT traversal. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. This document was WGLC'd previously, and all substantive comments were integrated into the document. During this second WGLC, there were no additional comments. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Most of the working group appears satisified with the document as being useful to explain how applications are traversing NATs today. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There have been no such concerns. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) The only remaining nits are to older versions of the drafts (-03 instead of -04). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? Yes; none are required. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Informational. (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? It contains a reference to RFC2766, which has recently been declared Historic; however, the document is Informational so this isn't a significant concern. If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document is Informational, so this isn't a concern. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? Document is Informational and has no IANA considerations. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There is no formal language in the document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This memo documents the various methods known to be in use by applications to establish direct UDP or TCP communication in the presence of Network Address Translators (NATs). Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Agreeing on RFC3489 terminology (which is well known) versus RFC4787 terminology (which is more accurate but longer) involved some controversy. Consensus was to use RFC4787 terminology. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Yes, in a manner of speaking -- the document explains how existing software traverses NATs. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? They have been acknowledged in the Acknowledgements section. If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? The document is Informational and only describes the state-of-the-art for traversal of NATs for UDP and TCP. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Dan Wing, dwing@cisco.com Responsible AD: Magnus Westerlund, magnus.westerlund@ericsson.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 15 02:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILBx8-0002F4-Ol; Wed, 15 Aug 2007 02:01:58 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILBx6-0002Em-NM for behave-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 02:01:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILBx5-0002Ee-Tj for behave@ietf.org; Wed, 15 Aug 2007 02:01:55 -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 1ILBx5-0007e8-E8 for behave@ietf.org; Wed, 15 Aug 2007 02:01:55 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2007 23:01:55 -0700 X-IronPort-AV: i="4.19,264,1183359600"; d="scan'208"; a="513617469:sNHT49874756" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7F61sQu026967; Tue, 14 Aug 2007 23:01:54 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7F61ra1022806; Wed, 15 Aug 2007 06:01:54 GMT From: "Dan Wing" To: "'Cullen Jennings'" , "'Jonathan Rosenberg'" Subject: RE: [BEHAVE] Minor concern about one of the milestones Date: Tue, 14 Aug 2007 23:01:53 -0700 Message-ID: <000101c7df01$c81c07b0$c6f0200a@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: Acfeo50YNenwY7ApQWaiGSTy8TJSagAXe2kg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2737; t=1187157714; x=1188021714; c=relaxed/simple; s=sjdkim4002; 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[BEHAVE]=20Minor=20concern=20about=20one=20of=20the=2 0milestones |Sender:=20; bh=kRFfKffMjWkmU1Kun8CO0TacuLUJ99ar5Xi3MxQ+RWo=; b=EyYQuJhHnIiGbihWavcN9tx0gPWztYaIcwl4wcwd9QQuveS4hBRwNUoP/y7b6qYmI31c81wm OgznFifDeQkaKveDqnOT6pD6T4oNMm8p2n6pOp0No9wWj/LUXiWjPzCT; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org When Derek and Bruce finish their applicability text, we may know better if this is, in fact, something we can declare as an Experiment (hopefully with exit criteria), or if this would be Informational. (That is, as long as we have consensus around removing the document from standards-track!) -d > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, August 14, 2007 11:46 AM > To: Jonathan Rosenberg > Cc: Behave WG > Subject: Re: [BEHAVE] Minor concern about one of the milestones > > > ok - I certainly understand making it informational but on > experimental, I would ask what is the experiment? If the experiment > is "can an application with a single IP behind a NAT reliably > predict > the NAT behavior?", well then I think we already know the answer to > this experiment. Anyways, I was not in the room so sorry for missing > the discussion around this. > > Cullen > > On Aug 14, 2007, at 6:24 AM, Jonathan Rosenberg wrote: > > > I think there was consensus in the room in chicago to make this > > either informational or experimental. > > > > -Jonathan R. > > > > Cullen Jennings wrote: > >> One of our milestones is > >> Submit standards-track document that describes how an application > >> can determine the type of NAT it is behind > >> I think it is very hard for an application to reliably do this > >> except under environments where all the traffic to the NAT is > >> controlled. (Basically this was the general limitation of RFC > >> 3489). I hope that the document for this milestone is more an > >> approach to characterizing and testing behavior of NATs > and is not > >> a general suggestion that an application might be able to figure > >> out what type of NAT it is behind then modify the applications > >> behavior based on the type of NAT is is behind. I seem to recall > >> the old milestone was more along the lines of testing but I can > >> not find a copy of it. > >> Cullen > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 15 02:46:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILCeG-0002HR-Lm; Wed, 15 Aug 2007 02:46:32 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILCeF-0002HL-Ux for behave-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 02:46:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILCeC-0002HC-4Y for behave@ietf.org; Wed, 15 Aug 2007 02:46:28 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILCeA-0003bz-6U for behave@ietf.org; Wed, 15 Aug 2007 02:46:27 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7F6jm44003275; Wed, 15 Aug 2007 09:46:16 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:46:15 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:46:15 +0300 Received: from esdhcp041244.research.nokia.com ([172.21.41.244]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:46:15 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Jonathan Rosenberg" , ext Dan Wing Subject: Re: [BEHAVE] STUN fingerprint and integrity tests Date: Wed, 15 Aug 2007 09:46:15 +0300 User-Agent: KMail/1.9.6 References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <46BB4B0C.6030204@db.org> <46C1ACF3.7000202@cisco.com> In-Reply-To: <46C1ACF3.7000202@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708150946.16105.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 15 Aug 2007 06:46:15.0368 (UTC) FILETIME=[F9E57C80:01C7DF07] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 14 August 2007 16:24:03 ext Jonathan Rosenberg wrote: > An important point of clarification here. > > Though FINGERPRINT is currently the only attribute beyond the MI, there > could potentially be others in the future so you can't depend on it > being the only one. So inserting a dummy FINGERPRINT won't help. Ok, that's right. With this in mind, I think the same considerations need to be made for the= =20 =46INGERPRINT attribute: if we ever had something past it, it will need to = hash=20 the message length the way M-I does. Otherwise, anything that adds optional attributes after FINGERPRINT will be= =20 undeployable for not being backward compatible (-> Uho, STUN NAT control...= ). Regards, =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 15 16:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPGl-00062B-3d; Wed, 15 Aug 2007 16:15:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILPGh-00061O-2T for behave-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 16:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPGg-000611-KP; Wed, 15 Aug 2007 16:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILPGg-000887-58; Wed, 15 Aug 2007 16:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0F52426E60; Wed, 15 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ILPGf-0000mK-U2; Wed, 15 Aug 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Aug 2007 16:15:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-multicast-09.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP Multicast Requirements for a Network Address (and port) Translator (NAT) Author(s) : T. Eckert, D. Wing Filename : draft-ietf-behave-multicast-09.txt Pages : 16 Date : 2007-8-15 This document specifies requirements for a Network Address (and port) Translator (NAT) that supports any source IP multicast or source specific IP multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-multicast-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-multicast-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-15151502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-multicast-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-multicast-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-15151502.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Wed Aug 15 18:37:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRU1-0006aH-DI; Wed, 15 Aug 2007 18:36:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILRTz-0006a2-44 for behave-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 18:36:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRTy-0006Zj-Eq; Wed, 15 Aug 2007 18:36:54 -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 1ILRTy-0003em-0u; Wed, 15 Aug 2007 18:36:54 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2007 15:36:53 -0700 X-IronPort-AV: i="4.19,268,1183359600"; d="scan'208"; a="513909360:sNHT46698684" 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 l7FMar8t007048; Wed, 15 Aug 2007 15:36:53 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7FMaqF4014422; Wed, 15 Aug 2007 22:36:52 GMT From: "Dan Wing" To: Date: Wed, 15 Aug 2007 15:36:52 -0700 Message-ID: <020401c7df8c$c7009c70$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.3028 In-Reply-To: Thread-Index: AcffeP5eA7+qimH3RRePmNdagPNxJgADnYIQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1874; t=1187217413; x=1188081413; 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:=20WGLC=20for=20draft-ietf-behave-multicast-09 |Sender:=20; bh=LTWb9eK489RSI1cXz6bFvi8xUOHt0boOvvzyvOR8px8=; b=PZYPibaA29l/ZI1X8SoM6hOY+6P0HZiTIsSG2liv5Se0O/icihdOe3yWA5VSlqqXM6NcvEme WLVpYGIXeAT0eHwnZ4WRPHvV+oGlEUSUZ9R0zPS4JjBq8vOPlefq8G6x; 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: 4adaf050708fb13be3316a9eee889caa Cc: mboned@ietf.org, magma@ietf.org Subject: [BEHAVE] WGLC for draft-ietf-behave-multicast-09 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I am starting the 3rd WGLC on draft-ietf-behave-multicast-09, "IP Multicast Requirements for a Network Address (and port) Translator NAT". The WGLC ends on September 3. The previous WGLCs were for -06 and -03 (which also went to IESG). Draft-ietf-behave-multicast-09 integrates all of the comments received to date. Significant changes from -08 include: * Consideration of Gorry Fairhurst's comments in Chicago about a multicast source inside of a multi-homed network; unfortunately the best I could describe to deal with that problem was the new requirement 5-a: "a: If a network is multihomed, the NATs or the network configuration MUST ensure that duplicate instances of the multicast data traffic does not appear on the public network. This can be accomplished by network design (an access control list) or a protocol between the NATs (e.g., the NAT with the higher IP address transmits multicast data towards the public network and other NATs drop it)." * a NAT with multiple public interfaces SHOULD pair for multicast in the same way it pairs for unicast (new requirement 4-c). * The "application considerations" section has been moved to an appendix, as it seems outside the scope of a document describing the behavior for NATs. Differences between -09 and -08: http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-behave- multicast-09.txt http://tinyurl.com/yqej5l Differences between -09 and -06: http://tinyurl.com/create.php?url=http://tools.ietf.org/rfcdiff?url1=http://to ols.ietf.org/id/draft-ietf-behave-multicast-06.txt&url2=http://tools.ietf.org/ id/draft-ietf-behave-multicast-09.txt http://tinyurl.com/yulw5t Please reply with any comments. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 15 20:53:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILTbe-0003Uu-5x; Wed, 15 Aug 2007 20:52:58 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILTbc-0003Uo-Im for behave-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 20:52:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILTbc-0003TN-8L for behave@ietf.org; Wed, 15 Aug 2007 20:52:56 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILTbb-0001Ql-1M for behave@ietf.org; Wed, 15 Aug 2007 20:52:56 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Aug 2007 17:52:53 -0700 X-IronPort-AV: i="4.19,268,1183359600"; d="scan'208"; a="200795024:sNHT6082760421" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7G0qqf2016875 for ; Wed, 15 Aug 2007 17:52:52 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7G0qqVp012114 for ; Thu, 16 Aug 2007 00:52:52 GMT From: "Dan Wing" To: "'Behave WG'" Date: Wed, 15 Aug 2007 17:52:51 -0700 Message-ID: <001901c7df9f$c667e440$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.3028 Thread-Index: Acffn8YP+43Dey7kQeKurPnyv1BIxA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=361; t=1187225572; x=1188089572; 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:=20draft=20BEHAVE=20minutes |Sender:=20; bh=kL0UGCuEzYcMsIJoeL40cj24hJn8PyJ1Kf+Hza28Dr8=; b=TnAp0jEyqBQOH9FXzRgJkHF4NC8CD1Apb9DcCJFP0eeG8Bo4UNQpdSZ4Yg8I1IQ4yuZNJ5lX Tb9+p4+8QdG30jpeduzgwmNu2z9+/+5vu9duKQWcNrBI3cblmXso2n+PDQjEMZYlnl/KvFsdiP wIOqN1CINm2w1tPxhGkJhxAWg=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [BEHAVE] draft BEHAVE minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I have posted the draft minutes from BEHAVE's IETF-69 meeting in Chicago to: http://www3.ietf.org/proceedings/07jul/minutes/behave.txt Thanks to all the presenters! Please reply with any changes to the minutes. Audio of the session is here: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch5-thurs-af noon-plenary.mp3 -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 15 23:28:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILW20-0004rB-Av; Wed, 15 Aug 2007 23:28:20 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILW1z-0004r5-8U for behave-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 23:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILW1y-0004qx-V7 for behave@ietf.org; Wed, 15 Aug 2007 23:28:18 -0400 Received: from web33305.mail.mud.yahoo.com ([68.142.206.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ILW1x-0006SG-I6 for behave@ietf.org; Wed, 15 Aug 2007 23:28:18 -0400 Received: (qmail 58321 invoked by uid 60001); 16 Aug 2007 03:28:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=kh2AYTIcBQzIvf2tRCIOfCDjFTyUpUMueXQiRZ+qNes55OlplwVC/AvdYulQW/k0sBRJNbNDXEJzLCR9DlqxuuEWEl1qypBPNpmb3K1Mo75AqRjeLoaxTkkm+QQoBqxjQ30BC50HCTYeE/gucojX+sXQR6JeroRRXBU4DXgZrcw=; X-YMail-OSG: gDI132UVM1lpaooAXo4.B1vQK.n0d375qXJyRRdCFJTEscGtK0Ssg3fRrSP5ovLy19jLM18uo9Lx1_q9PbszkExoObltSu1Vs4uz4LljbJcA0RlKVJI- Received: from [209.172.74.45] by web33305.mail.mud.yahoo.com via HTTP; Wed, 15 Aug 2007 20:28:17 PDT Date: Wed, 15 Aug 2007 20:28:17 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: Magnus Westerlund In-Reply-To: <46AF3813.1020105@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <136097.58028.qm@web33305.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Magnus, I was out of town and just got back. Just catching up on the e-mails. Please see my responses inline below. regards, suresh --- Magnus Westerlund wrote: > Suresh, > > I would propose that you drop MMUSIC mailing listif responding to this > as you appear to want to discuss the removal of a BEHAVE milestone, > rather than ICE and its way forward. But I will leave it there to let > the MMUSIC people see my response. > [suresh] I am not opposed to ICE moving forward. Please see below for my objection to ICE. > It seems most of the issues in this discussion is between, what I at > least thought was a specific way of performing the hole punching rather > than the general concept that I acknowledge has existed since the > creation of NATs. I will drop these items an respond to few of them. [suresh] Sorry, the hole punchign techniques havent been there since the conception of NATs. They came about principally in the context of P2P applications, much aftet the original NATs. > > Pyda Srisuresh skrev: > > --- Magnus Westerlund wrote: > >> > >> There also has been discussion about if there should be multiple > >> solutions etc. But, to my knowledge the consensus also there has been > >> that one solution is the way to go. > >> > > [suresh] I have not been part of the discussion pertaining to the merit of > > multiple solutions vs single soultions. This may have been discussed in the > > context of SIP and NAT traversal. So, I cant comment on this. > > Yes, that was in the context of ICE. As my email was about that. > > > > >> So Suresh, you and everyone else as participants in the IETF is > >> responsible for what you call HOLE PUNCHING TECHNIQUES are not an WG > >> item. > > > > [suresh] Magnus - I dont know what you are talking about. How do you mean I > am > > responsible for why the HOLE PUNCHING TECHNIQUE draft is not a WG item. The > > ford-behave-app draft has been around for many years since the inception of > > BEHAVE. Last I checked, The application milestone is no longer on BEHVAE > > charter. I certainly am not responsible for removign the milestone. > > This was written as reaction on how work gets done in the IETF. One or > more proponents goes out and sell their idea so that enough people are > interested to participate in the work on that idea. In cases the > proponents are not succesful in getting traction for the idea it rarely > goes anywhere. In the case of the ford-behave-app draft there has been > no support for keeping the milestone or more important, do the work. > [suresh] I personally know of several applications using the TCP/UDP HOLE PUNCHING techniques directly (not using ICE). Irrespective of whether the IETF endorses design guidelines using HOLE PUNCHING techniques or not, this work will continue. It is ironic to me why the WG chose not to take up design guidelines using HOLE PUNCHING techniques as WG item. I cant explain it. > > > [suresh] Magnus - I have not been part of the consensus for ICE. However, I > do > > know ICE adapts the HOLE PUNCHING TECHNIQUES and the BCP recommendations > > identified in ford-behave-app draft. Yet, neither of the ICE drafts (UDP or > the > > TCP version) refer the ford-behave-app draft or prior work on HOLE PUNCHING > as > > normative reference. This iS WRONG. > > > > I believe, the ICE drafts should refer the prior work (kegel work on UDP > hole > > punching, USENIX paper for TCP hole punching and ford-behave-app draft for > > application traversal design) on which the ICE work is based. > > > > I think you should review your sources here. The first version of > ford-beahve-app was submitted february 2005. At that point STUN (RFC > 3489 had been published in almost 2 years (March 2003). The first > individual version of ICE was submitted to IETF february 2003. I am not > going to untangle this, but if you are going down this path: Please have > you facts right. > [suresh] Below is the chronology of the sources I am refering to. You can see for yourself what I am talking about. Nothing complex to untagle. a) http://alumnus.caltech.edu/~dank/peer-nat.html (Dec 98)- First documented reference to UDP hole punching technique. b) draft-ford-midcom-nat-p2p-00.txt (Sept 03) - First known reference to TCP hole punching technique and P2P application design guidelines c) Peer-to-peer communication across NATs USENIX '05 paper (04/2005) - This is derived from draft-ford-midcom-nat-p2p draft. Considerign that draft-ford-midcom-nat-p2p draft expired, this is the first formal documented reference to TCP hole punching d) draft-ford-behave-app-05.txt (March '07) - This is the currently active application design guidelines draft, derived from draft-ford-midcom-nat-p2p draft. e) draft-rosenberg-sipping-ice-00 (Feb 03) - First rev of ICE over UDP draft. This uses UDP hole punching technique. The ICE draft currently in MMUSIC WG has evolved and folds in a number of application design guidelines in ford-midcom-nat-p2p and ford-behave-app drafts, besides the UDP HOLE PUNCHING technique. f) draft-ietf-mmusic-ice-tcp-00 (Mar 06) - First rev of ICE over TCP draft. This uses TCP hole punching technique and folds in a number of application design guidelines in ford-midcom-nat-p2p and ford-behave-app drafts. I believe, there should be acknowledgement where the acknowledgement is due. The ICE drafts use the HOLE PUNCHING technique and adapt guidelines specified in ford-behave-app draft. But none of a), c) or e) are referred by the ICE drafts (ICE and ICE-TCP). > I am not denying that work commonly builds up on others. And that it is > common curtesy to reference such work. However, that is commonly done by > an informative reference. Normative references are for things that you > absolutely need to include to build interoperable implementations. > Please do review IESG statement on references: > > http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt > [suresh] Thanks for the pointer. The description is subject to individual interpretation. For example, it says "Normative references specify documents that must be read to understand or implement the technology in the new RFC". If you describe the technique used inside a draft, does it make the technique non-normative? I dont want to get into the nitty grittys on this. I will be fine, if the ICE drafts referred the docs I mentioned even as informational references. > > > > On the one hand, IETF (IESG) has been adamant about the standard level of > the > > normative references for a proposes standard. Yet, it is ironic that when > HOLE > > PUNCHING is normative to the design of ICE, the IETF is not allowing the > HOLE > > PUNCHING work to be standardized. > > Once more a missunderstanding about what it means to be a normative > reference in an RFC. > [suresh] Please see my comment above. > > > > Why is the IETF not allowing HOLE PUNCHING TECHNIQUES and P2P application > > traversal identified in draft-ford-behave-app draft to move forward as a > BCP WG > > item? > > > > As stated before. There is a clear lack of interest in this document. I > wished there wasn't. But the fact is that no-one except you have really > argued for it, not even your co-authors. We can't publish a document > where no-one reads and reviews it and stil claim that their exist > consensus behind it. [suresh] Magnus - My co-authors are not arguing for it because they have given up they can get anywhere with arguing. It is just that I didnt. regards, suresh > > Regards > > 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 From behave-bounces@ietf.org Thu Aug 16 04:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILaVn-0006ov-Ev; Thu, 16 Aug 2007 04:15:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILaVm-0006oe-Dq for behave-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 04:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILaVd-0006nd-Gr; Thu, 16 Aug 2007 04:15:13 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILaVc-0006Qa-LP; Thu, 16 Aug 2007 04:15:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 5C8292BAD66; Thu, 16 Aug 2007 10:15:11 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14824-01-48; Thu, 16 Aug 2007 10:15:10 +0200 (CEST) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id D193C2BACF1; Thu, 16 Aug 2007 10:15:10 +0200 (CEST) Message-ID: <46C4078E.9050507@uninett.no> Date: Thu, 16 Aug 2007 10:15:10 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.5 (X11/20070731) MIME-Version: 1.0 To: Dan Wing References: <020401c7df8c$c7009c70$c6f0200a@cisco.com> In-Reply-To: <020401c7df8c$c7009c70$c6f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -1.4 (-) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mboned@ietf.org, magma@ietf.org, behave@ietf.org Subject: [BEHAVE] Re: [MBONED] WGLC for draft-ietf-behave-multicast-09 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan Wing wrote: > I am starting the 3rd WGLC on draft-ietf-behave-multicast-09, "IP Multicast > Requirements for a Network Address (and port) Translator NAT". The WGLC ends > on September 3. The previous WGLCs were for -06 and -03 (which also went to > IESG). [...] Here are my thoughts upon reading this draft. In section 3 background it says: This specifically means that IGMP protocol packets sent by the NAT device will always use IP address of the interface (inside or outside) to which they are sent, but because those packets are ^^^^^ logically "sourced" and not "forwarded", NAT does not have any impact into this. I might be confused here, but shouldn't it be "_from_ which they are sent"? In 4.1.1: REQ-1: For IP multicast packets that are forward to a host(s) on ^^^^^^^^^ forwarded My only substantial comment is regarding 4.3 and RTP. I think it should be noted that there might be SSRC collisions that are not detected since RTP packets from different hosts behind a NAT might appear to be from the same. One could then note that CNAME (defined in RFC 3550) might be of help. One interesting thing here is that hosts might use their IP address to construct the CNAME. This means that their private addresses may be exposed. I don't know how serious a problem that is though... However, it is not unlikely that two hosts behind two different NATs have the same private IP address. If they both source RTP, they may pick the same CNAME which is a problem. RFC 3550 says in 6.5.1: applications MAY provide a means to configure a unique CNAME, but the burden is on the translator to translate CNAMEs from private addresses to public addresses if necessary to keep private addresses from being exposed. Doing this however, could mean that two multicast sources behind the same NAT end up sending RTP with the same CNAME, so I don't know how good that is. Anyhow, I believe this draft should note some of the issues with CNAME. Finally, one tiny editorial comment. At least I would write "Source-Specific Multicast" rather than "source specific multicast", and "Any Source Multicast" rather than "any source multicast". At least I find this easier to read. Stig _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 16 12:10:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhv7-0008B5-Jp; Thu, 16 Aug 2007 12:10:01 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILhv6-0008AY-Gi for behave-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 12:10:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhv6-0008AN-5k for behave@ietf.org; Thu, 16 Aug 2007 12:10:00 -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 1ILhv5-0003e5-PF for behave@ietf.org; Thu, 16 Aug 2007 12:10:00 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 16 Aug 2007 09:09:59 -0700 X-IronPort-AV: i="4.19,272,1183359600"; d="scan'208"; a="514192010:sNHT49397074" 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 l7GG9xvs028477; Thu, 16 Aug 2007 09:09:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7GG9dFG011068; Thu, 16 Aug 2007 16:09:59 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:09:54 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:09:53 -0700 Message-ID: <46C476DF.3060107@cisco.com> Date: Thu, 16 Aug 2007 12:10:07 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= Subject: Re: [BEHAVE] STUN fingerprint and integrity tests References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <46BB4B0C.6030204@db.org> <46C1ACF3.7000202@cisco.com> <200708150946.16105.remi.denis-courmont@nokia.com> In-Reply-To: <200708150946.16105.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Aug 2007 16:09:54.0005 (UTC) FILETIME=[E1C9B850:01C7E01F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1210; t=1187280599; x=1188144599; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20fingerprint=20and=20integrity=20tes ts |Sender:=20; bh=cLs6fQHO6mS9R1imoBVJHwPMHTiJw3HTHK3WlVluMJQ=; b=ZERAaRimBa+uCvFQ0oRsjY7bghu75lAfNKdrO/ysSNet4TxkszcUI5OGnN3mGgC6alXC+mNQ mlX2eeIkkNN4Iur7EQGgR4hIKSUegriGirhB6v5XWV3WlHHpZik9fP03eKltO3P2FV25QXpl2H ep2qc0i9boDtkpvmWg6IeKFz0=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: behave@ietf.org, ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Remi - any comment on the other part of my mail, on the alternative hash computation? -Jonathan R. RĂ©mi Denis-Courmont wrote: > On Tuesday 14 August 2007 16:24:03 ext Jonathan Rosenberg wrote: >> An important point of clarification here. >> >> Though FINGERPRINT is currently the only attribute beyond the MI, there >> could potentially be others in the future so you can't depend on it >> being the only one. So inserting a dummy FINGERPRINT won't help. > > Ok, that's right. > > With this in mind, I think the same considerations need to be made for the > FINGERPRINT attribute: if we ever had something past it, it will need to hash > the message length the way M-I does. > > Otherwise, anything that adds optional attributes after FINGERPRINT will be > undeployable for not being backward compatible (-> Uho, STUN NAT control...). > > Regards, > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 16 12:12:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhxf-0000PD-Bv; Thu, 16 Aug 2007 12:12:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILhxe-0000P8-9K for behave-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 12:12:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhxd-0000P0-Uq for behave@ietf.org; Thu, 16 Aug 2007 12:12:37 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILhxd-0003hh-Ee for behave@ietf.org; Thu, 16 Aug 2007 12:12:37 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 16 Aug 2007 09:12:37 -0700 X-IronPort-AV: i="4.19,272,1183359600"; d="scan'208"; a="392647830:sNHT52775444" 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 l7GGCaEt018356; Thu, 16 Aug 2007 09:12:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7GGCaF6014573; Thu, 16 Aug 2007 16:12:36 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:12:28 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:12:27 -0700 Message-ID: <46C47779.4000800@cisco.com> Date: Thu, 16 Aug 2007 12:12:41 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] Re: rfc3489bis-08 last minute comment: 401 still problematic References: <200708141446.10170.remi.denis-courmont@nokia.com> <46C1A762.3010004@cisco.com> <200708141605.19285.remi.denis-courmont@nokia.com> <46C1B1BF.9030404@cisco.com> <46C20762.3030203@acm.org> In-Reply-To: <46C20762.3030203@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2007 16:12:27.0849 (UTC) FILETIME=[3D7C7390:01C7E020] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2749; t=1187280756; x=1188144756; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Re=3A=20rfc3489bis-08=20last=20minute=20co mment=3A=20401=20still=09problematic |Sender:=20; bh=4VMfT+tXAd/PCDY2pUiaZAPMlZALOPl59BIH+uGJ/g8=; b=VQR1CSjPU1Ra8kDAjURh83jwGpn6s10UkPoMpwbfWzImXvpK4cT97Og5GhmAaj7e0AF7v+gb g0VGZ4vwDkXDl7hcSEkBJfBZ1xrk4hFNVb27YLhC0/a3gBB3OR9Cf3zB; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: behave@ietf.org, philip_matthews@magma.ca, ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Fixed, thanks. -Jonathan R. Marc Petit-Huguenin wrote: > Jonathan Rosenberg wrote: >> OK, here is the text now: >> >>
>> >> >> After the server has done the basic processing of a request, it >> performs the checks listed below in the order specified: >> >> >> >> If the message does not contain a MESSAGE-INTEGRITY attribute, >> the server MUST >> generate an error response with an error code of >> 401 (Unauthorized). This response MUST include a REALM value. It is >> RECOMMENDED that the REALM value be the domain name of >> the provider of the STUN server. The response MUST >> include a NONCE, selected by the server. >> >> >> >> If the message contains a MESSAGE-INTEGRITY >> attribute, but is missing the USERNAME, REALM or >> NONCE attributes, the server MUST generate an error >> response with an error code of 400 (Bad Request). >> >> >> >> If the NONCE is no longer valid, the server MUST >> generate an error response with an error code of 438 >> (Stale Nonce). This response MUST include a NONCE and REALM >> attribute. >> >> >> >> If the username in the USERNAME attribute is not valid, the server >> MUST generate an error response with an error code of >> 401 (Unauthorized). This response MUST include a REALM value. It is >> RECOMMENDED that the REALM value be the domain name of >> the provider of the STUN server. The response MUST >> include a NONCE, selected by the server. >> >> >> Using the password associated with the username in >> the USERNAME attribute, >> compute the value for the message-integrity as >> described in >> . If the >> resulting value does not match the contents of the >> MESSAGE-INTEGRITY attribute, the server MUST >> reject the request with an error response. This >> response MUST use an error code of 401 (Unauthorized). It MUST >> include a REALM >> and NONCE attribute. >> >> >> >> >> If these checks pass, the server continues to process the >> request or indication. Any response generated by the server > > Per 10.2, the long-term credential mechanism cannot be used to protect > indications. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 16 12:28: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 1ILiD5-00056s-Hb; Thu, 16 Aug 2007 12:28:35 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILiD4-00056n-TI for behave-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 12:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILiD4-00056f-Jc for behave@ietf.org; Thu, 16 Aug 2007 12:28:34 -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 1ILiD3-0003CD-Au for behave@ietf.org; Thu, 16 Aug 2007 12:28:34 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 16 Aug 2007 09:28:34 -0700 X-IronPort-AV: i="4.19,272,1183359600"; d="scan'208"; a="392649972:sNHT50577400" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7GGSWSN028531; Thu, 16 Aug 2007 09:28:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7GGSOir012976; Thu, 16 Aug 2007 16:28:32 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:28:29 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:28:29 -0700 Message-ID: <46C47B3B.2020701@cisco.com> Date: Thu, 16 Aug 2007 12:28:43 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= Subject: Re: [BEHAVE] STUN fingerprint and integrity tests References: <72e3f01c7d91e$e82fc589$7b8f15ac@NOE.Nokia.com> <46BB4B0C.6030204@db.org> <46C1ACF3.7000202@cisco.com> <200708150946.16105.remi.denis-courmont@nokia.com> <46C476DF.3060107@cisco.com> In-Reply-To: <46C476DF.3060107@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Aug 2007 16:28:29.0699 (UTC) FILETIME=[7ACB1D30:01C7E022] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1395; t=1187281712; x=1188145712; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20fingerprint=20and=20integrity=20tes ts |Sender:=20; bh=Hs5KPLSR22qAfkvebUFwAGEQzwLOJq9oI8HyG1KrSGg=; b=HAJ/F8yZ29WgvtbqdIE1FPNE9kA2eSLkNaJJYjOynIyd4OOU2WWRqilzQVFytqj/a5xiDPQ3 4n5BiQgeM1OltIODX9HaSTCTj1YxjKWs28OCyhNdHwXdXPPJrfGF1L67+ubi9WiN/1zHTWbnq4 D5d33qWvGG8Zp2VCdynP+AIPA=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: behave@ietf.org, ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Actually, forget it. I withdraw this idea. Its a big change with questionable value, late in the game. -Jonathan R. Jonathan Rosenberg wrote: > Remi - any comment on the other part of my mail, on the alternative hash > computation? > > -Jonathan R. > > RĂ©mi Denis-Courmont wrote: >> On Tuesday 14 August 2007 16:24:03 ext Jonathan Rosenberg wrote: >>> An important point of clarification here. >>> >>> Though FINGERPRINT is currently the only attribute beyond the MI, there >>> could potentially be others in the future so you can't depend on it >>> being the only one. So inserting a dummy FINGERPRINT won't help. >> >> Ok, that's right. >> >> With this in mind, I think the same considerations need to be made for >> the FINGERPRINT attribute: if we ever had something past it, it will >> need to hash the message length the way M-I does. >> >> Otherwise, anything that adds optional attributes after FINGERPRINT >> will be undeployable for not being backward compatible (-> Uho, STUN >> NAT control...). >> >> Regards, >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 16 15:31:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILl43-0005LJ-7G; Thu, 16 Aug 2007 15:31:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILl42-0005Ks-1N for behave-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 15:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILl41-0005KZ-31; Thu, 16 Aug 2007 15:31:25 -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 1ILl3z-0001Pd-S1; Thu, 16 Aug 2007 15:31:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 16 Aug 2007 12:31:23 -0700 X-IronPort-AV: i="4.19,273,1183359600"; d="scan'208"; a="514257753:sNHT57897386" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7GJVNW4021000; Thu, 16 Aug 2007 12:31:23 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7GJVMiF013092; Thu, 16 Aug 2007 19:31:22 GMT From: "Dan Wing" To: "'Stig Venaas'" Date: Thu, 16 Aug 2007 12:31:22 -0700 Message-ID: <016401c7e03c$076ea5e0$c6f0200a@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: <46C4078E.9050507@uninett.no> Thread-Index: Acff3ZX1U+llEPiNRIChDzLho1/KMwAV5YYA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3008; t=1187292683; x=1188156683; c=relaxed/simple; s=sjdkim4002; 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[MBONED]=20WGLC=20for=20draft-ietf-behave-multicast-0 9 |Sender:=20; bh=5wj9cbv5HTRrkdqO4PBv0WmfQ0zbJ7zDLpPWI8UKV1g=; b=Xb0hucOMhkG3AsInrOrXOGALhMmFIxhAGI3BaXRwNdJpbtp4vyZsPl3AbtXa2aqOynHOPbLd X+eQv5R5P8Tonhv5YDTYKw6F1wrsic01Cco5/II6SOi7R/l6sHY4NyIa; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mboned@ietf.org, magma@ietf.org, behave@ietf.org Subject: [BEHAVE] RE: [MBONED] WGLC for draft-ietf-behave-multicast-09 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Stig Venaas wrote: > Dan Wing wrote: > > I am starting the 3rd WGLC on > > draft-ietf-behave-multicast-09, "IP Multicast > > Requirements for a Network Address (and port) Translator > > NAT". The WGLC ends > > on September 3. The previous WGLCs were for -06 and -03 > > (which also went to > > IESG). > [...] > > Here are my thoughts upon reading this draft. > > In section 3 background it says: > > This specifically means that IGMP protocol packets sent by the NAT > device will always use IP address of the interface (inside or > outside) to which they are sent, but because those packets are > ^^^^^ > logically "sourced" and not "forwarded", NAT does not have > any impact into this. > > I might be confused here, but shouldn't it be "_from_ which they are > sent"? > > In 4.1.1: > > REQ-1: For IP multicast packets that are forward to a host(s) on > ^^^^^^^^^ > forwarded Thanks, I made those adjustments in -10, which I expect will be sent to IESG. > My only substantial comment is regarding 4.3 and RTP. > > I think it should be noted that there might be SSRC collisions that > are not detected since RTP packets from different hosts behind a NAT > might appear to be from the same. One could then note that CNAME > (defined in RFC 3550) might be of help. One interesting thing here > is that hosts might use their IP address to construct the CNAME. This > means that their private addresses may be exposed. I don't know how > serious a problem that is though... However, it is not unlikely that > two hosts behind two different NATs have the same private IP > address. If they both source RTP, they may pick the same CNAME which > is a problem. > > RFC 3550 says in 6.5.1: > > applications MAY provide a means to configure a unique > CNAME, but the > burden is on the translator to translate CNAMEs from private > addresses to public addresses if necessary to keep private > addresses > from being exposed. > > Doing this however, could mean that two multicast sources behind the > same NAT end up sending RTP with the same CNAME, so I don't know how > good that is. > > Anyhow, I believe this draft should note some of the issues > with CNAME. I agreed. Would the following additional text in the non-normative Application Considerations appendix be sufficient: As many NATs use the same private address space (e.g., 192.168.0.0/16, [RFC1918]), RTP stacks are encouraged to generate CNAMEs properly (see end of Section 6.5.1 of [RFC3550].) Please let me know if that is suitable. > Finally, one tiny editorial comment. At least I would write > "Source-Specific Multicast" rather than "source specific > multicast", and > "Any Source Multicast" rather than "any source multicast". At least I > find this easier to read. Done. That does help readability. Thanks for your review. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Aug 17 11:20:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3cJ-0002IH-TB; Fri, 17 Aug 2007 11:20:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IM3cI-0002Hs-O8 for behave-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 11:20:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3cI-0002Hk-CO; Fri, 17 Aug 2007 11:20:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM3cH-0007hN-UZ; Fri, 17 Aug 2007 11:20:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id CCA7B26E6E; Fri, 17 Aug 2007 15:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IM3cH-0005ng-O5; Fri, 17 Aug 2007 11:20:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 17 Aug 2007 11:20:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-09.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Session Traversal Utilities for (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-09.txt Pages : 47 Date : 2007-08-17 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-08-17111617.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-08-17111617.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Sun Aug 19 11:12:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMmSM-00028S-Fx; Sun, 19 Aug 2007 11:12:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IMmSL-000289-MC for behave-confirm+ok@megatron.ietf.org; Sun, 19 Aug 2007 11:12:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMmSL-000280-AI; Sun, 19 Aug 2007 11:12:45 -0400 Received: from [80.81.115.248] (helo=soportemv.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMmSJ-0006CT-Iu; Sun, 19 Aug 2007 11:12:45 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 19 Aug 2007 17:11:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt Thread-Index: AcepBgFLbeOu0nfqSnmecsmR20l6OA0yR5kwAShy3JQ= References: <01b701c7ddcf$adfe2030$c6f0200a@cisco.com> From: "Alvaro Fernandez" To: "Dan Wing" , "Brian Haberman" X-Spam-Score: 1.9 (+) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: behave@ietf.org, Marshall Eubanks , Marshall Eubanks , mboned@ietf.org, magma@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1082708544==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1082708544== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E273.4324ED24" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E273.4324ED24 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Just another comment: =20 If the sender behind the NAT uses Ethernet and maps de lower 28 bits IP = multicast address ( first 4 bits are always 1110) to 23 bits in the = multicast MAC address, =BFwhich 5 high order bits uses the NAT to send = the IP multicast packets?=20 =20 Considering that SSM range is 232/8. How the NAT knows if the paquet is = within the SSM range? =20 Regards =20 Alvaro ________________________________ De: Dan Wing [mailto:dwing@cisco.com] Enviado el: lun 13/08/2007 19:30 Para: 'Brian Haberman' CC: 'Marshall Eubanks'; mboned@ietf.org; Alvaro Fernandez; = magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; 'Toerless Eckert' Asunto: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: = WGLC:draft-ietf-behave-multicast-06.txt > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Thursday, June 07, 2007 6:16 AM > To: Dan Wing > Cc: 'Marshall Eubanks'; mboned@ietf.org; 'Alvaro Fernandez'; > magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; Toerless Eckert > Subject: Re: [BEHAVE] Re: [magma] RE: [MBONED] FW: > WGLC:draft-ietf-behave-multicast-06.txt .... > > > > Dan Wing wrote: > >> The NAPT knows what is SSM. Couldn't it also do a Multicast Group=20 > >> Translation for SSM groups ? Why > >> is this more difficult than, say, port translation ? > > > > It may be fairly easy -- except for rewriting the > > advertisements in SAP, > > HTTP, HTTPS (a big problem there), email, SIP, RTSP, .... > > > > And NAPTs don't do that kind of rewriting today; > > draft-ietf-behave-multicast > > is only a BCP and trying to describe what a NAT should best > > be doing as of > > its date of publication. > > > > > > If we want NAPTs to do this, we would want a different > > document that was > > standards-track and that document would define how we > > wanted NAPTs to > > perform this function. However, I don't see a successful > > path if such an > > operation would require the NAPT to have an ALG for SAP, > > HTTP, SIP, and RTSP > > and requires the NAT also rewrite those packets. We'd need > > something else. > > ALGs don't work well for a variety of reasons. > > Given that, I would suggest that the document state that > administrators of the network behind the NAPT assign sub-ranges > of the SSM space to their multicast sources. This could be done > manually or *possibly* with the tools developed by the MALLOC > WG. For the ma & pa type residential networks, I doubt you will > see multiple machines behind a NAPT sourcing SSM. For more > corporate types, the network admin can control the allocation of > the SSM range. I moved text discussing what applications should do into an appendix, as the document's BCP scope is really around NATs (rather than applications that need to handle NATs). Based on your comment above, and some other input, the text now has the following paragraph. I believe this captures your suggestion. "If multiple SSM sources on the inside of a NAT choose the same multicast group address, those sources are uniquely identifiable because their IP addresses are unique. However, if their multicast traffic is NATted and sent on the NAT's public interface, the traffic from those individual sources is no longer uniquely identifiable. This will cause problems for multicast receivers which will see an intermixing of traffic from those sources. Resolution of this issue is left for future study. In the meantime, applications that source SSM multicast traffic are encouraged to allow the user to modify the multicast SSM address so that users can avoid this problem if that application is placed behind a NAT." The text doesn't quite go so far to say that a range has to be assigned = a priori. But let me know if it is acceptable. I have not submitted -09, but a preview is here if anyone wants to see = the full context: http://svn.resiprocate.org/rep/ietf-drafts/behave/draft-ietf-behave-multi= cast- 09.txt -d ------_=_NextPart_001_01C7E273.4324ED24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: = WGLC:draft-ietf-behave-multicast-06.txt=0A= =0A= =0A= =0A=
=0A=
Hi,
=0A=
 
=0A=
Just another = comment:
=0A=
 
=0A=
If the sender behind the NAT = uses Ethernet and maps de lower 28 bits IP multicast address ( first = 4 bits are always 1110) to 23 bits in the multicast MAC address, = =BFwhich 5 high order bits uses the NAT to send the IP multicast = packets?
=0A=
 
=0A=
Considering that SSM = range is 232/8. How the NAT knows if the paquet is within the SSM = range?
=0A=
 
=0A=
Regards
=0A=
 
=0A=
Alvaro
=0A=

=0A=
=0A= De: Dan Wing = [mailto:dwing@cisco.com]
Enviado el: lun 13/08/2007 = 19:30
Para: 'Brian Haberman'
CC: 'Marshall Eubanks'; = mboned@ietf.org; Alvaro Fernandez; magma@ietf.org; behave@ietf.org; = 'Marshall Eubanks'; 'Toerless Eckert'
Asunto: RE: [BEHAVE] Re: = [magma] RE: [MBONED] FW: = WGLC:draft-ietf-behave-multicast-06.txt

=0A=
=0A=

> -----Original Message-----
> From: Brian = Haberman [mailto:brian@innovationslab.net<= /A>]
> Sent: Thursday, June 07, 2007 6:16 AM
> To: Dan = Wing
> Cc: 'Marshall Eubanks'; mboned@ietf.org; 'Alvaro = Fernandez';
> magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; = Toerless Eckert
> Subject: Re: [BEHAVE] Re: [magma] RE: [MBONED] = FW:
> = WGLC:draft-ietf-behave-multicast-06.txt
....
>
>
>> Dan Wing wrote:
> >> The NAPT knows what is SSM. = Couldn't it also do a Multicast Group 
> >> Translation = for SSM groups ? Why
> >> is this more difficult than, say, = port translation ?
> >
> > It may be fairly easy -- = except for rewriting the
> > advertisements in SAP,
> = > HTTP, HTTPS (a big problem there), email, SIP, RTSP, ....
> = >
> > And NAPTs don't do that kind of rewriting = today;
> > draft-ietf-behave-multicast
> > is only a = BCP and trying to describe what a NAT should best
> > be doing = as of
> > its date of publication.
> >
> = >
> > If we want NAPTs to do this, we would want a = different
> > document that was
> > standards-track = and that document would define how we
> > wanted NAPTs = to
> > perform this function.  However, I don't see a = successful
> > path if such an
> > operation would = require the NAPT to have an ALG for SAP,
> > HTTP, SIP, and = RTSP
> > and requires the NAT also rewrite those packets.  = We'd need
> > something else.
> > ALGs don't work well = for a variety of reasons.
>
> Given that, I would suggest = that the document state that
> administrators of the network = behind the NAPT assign sub-ranges
> of the SSM space to their = multicast sources.  This could be done
> manually or = *possibly* with the tools developed by the MALLOC
> WG.  For = the ma & pa type residential networks, I doubt you will
> see = multiple machines behind a NAPT sourcing SSM.  For more
> = corporate types, the network admin can control the allocation of
> = the SSM range.

I moved text discussing what applications should = do into an appendix,
as the document's BCP scope is really around = NATs (rather than
applications that need to handle NATs).  Based = on your comment above,
and some other input, the text now has the = following paragraph.  I
believe this captures your = suggestion.

  "If multiple SSM sources on the inside of a = NAT choose the same
   multicast group address, those = sources are uniquely identifiable
   because their IP = addresses are unique.  However, if their multicast
   = traffic is NATted and sent on the NAT's public interface, the = traffic
   from those individual sources is no longer = uniquely identifiable.
   This will cause problems for = multicast receivers which will see an
   intermixing of = traffic from those sources.  Resolution of this = issue
   is left for future study.  In the meantime, = applications that source
   SSM multicast traffic are = encouraged to allow the user to modify the
   multicast SSM = address so that users can avoid this problem if that
   = application is placed behind a NAT."

The text doesn't quite go so = far to say that a range has to be assigned a
priori.  But let me = know if it is acceptable.

I have not submitted -09, but a preview = is here if anyone wants to see the
full context:
http://svn.resiprocate.org/rep/ietf-drafts/behave/draft-ie= tf-behave-multicast-
09.txt

-d

<= /HTML> ------_=_NextPart_001_01C7E273.4324ED24-- --===============1082708544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1082708544==-- From behave-bounces@ietf.org Sun Aug 19 12:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMnwP-00029n-Fl; Sun, 19 Aug 2007 12:47:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IMnwN-00029L-IV for behave-confirm+ok@megatron.ietf.org; Sun, 19 Aug 2007 12:47:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMnwM-00028z-VB; Sun, 19 Aug 2007 12:47:50 -0400 Received: from [80.81.115.248] (helo=soportemv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMnwK-0000dN-C1; Sun, 19 Aug 2007 12:47:50 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW:WGLC:draft-ietf-behave-multicast-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 19 Aug 2007 18:45:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: [magma] RE: [MBONED] FW:WGLC:draft-ietf-behave-multicast-06.txt Thread-Index: AcepBgFLbeOu0nfqSnmecsmR20l6OA0yR5kwAShy3JQAA93Wow== References: <01b701c7ddcf$adfe2030$c6f0200a@cisco.com> From: "Alvaro Fernandez" To: "Alvaro Fernandez" , "Dan Wing" , "Brian Haberman" X-Spam-Score: 1.9 (+) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: mboned@ietf.org, magma@ietf.org, behave@ietf.org, Marshall Eubanks X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0005860977==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0005860977== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E280.8B9D3121" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E280.8B9D3121 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My mistake. The info is in the IP header. Alvaro ________________________________ De: Alvaro Fernandez [mailto:Alvaro@soportemv.com] Enviado el: dom 19/08/2007 17:11 Para: Dan Wing; Brian Haberman CC: behave@ietf.org; Marshall Eubanks; mboned@ietf.org; magma@ietf.org Asunto: RE: [BEHAVE] Re: [magma] RE: [MBONED] = FW:WGLC:draft-ietf-behave-multicast-06.txt Hi, =20 Just another comment: =20 If the sender behind the NAT uses Ethernet and maps de lower 28 bits IP = multicast address ( first 4 bits are always 1110) to 23 bits in the = multicast MAC address, =BFwhich 5 high order bits uses the NAT to send = the IP multicast packets?=20 =20 Considering that SSM range is 232/8. How the NAT knows if the paquet is = within the SSM range? =20 Regards =20 Alvaro ________________________________ De: Dan Wing [mailto:dwing@cisco.com] Enviado el: lun 13/08/2007 19:30 Para: 'Brian Haberman' CC: 'Marshall Eubanks'; mboned@ietf.org; Alvaro Fernandez; = magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; 'Toerless Eckert' Asunto: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: = WGLC:draft-ietf-behave-multicast-06.txt > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Thursday, June 07, 2007 6:16 AM > To: Dan Wing > Cc: 'Marshall Eubanks'; mboned@ietf.org; 'Alvaro Fernandez'; > magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; Toerless Eckert > Subject: Re: [BEHAVE] Re: [magma] RE: [MBONED] FW: > WGLC:draft-ietf-behave-multicast-06.txt .... > > > > Dan Wing wrote: > >> The NAPT knows what is SSM. Couldn't it also do a Multicast Group=20 > >> Translation for SSM groups ? Why > >> is this more difficult than, say, port translation ? > > > > It may be fairly easy -- except for rewriting the > > advertisements in SAP, > > HTTP, HTTPS (a big problem there), email, SIP, RTSP, .... > > > > And NAPTs don't do that kind of rewriting today; > > draft-ietf-behave-multicast > > is only a BCP and trying to describe what a NAT should best > > be doing as of > > its date of publication. > > > > > > If we want NAPTs to do this, we would want a different > > document that was > > standards-track and that document would define how we > > wanted NAPTs to > > perform this function. However, I don't see a successful > > path if such an > > operation would require the NAPT to have an ALG for SAP, > > HTTP, SIP, and RTSP > > and requires the NAT also rewrite those packets. We'd need > > something else. > > ALGs don't work well for a variety of reasons. > > Given that, I would suggest that the document state that > administrators of the network behind the NAPT assign sub-ranges > of the SSM space to their multicast sources. This could be done > manually or *possibly* with the tools developed by the MALLOC > WG. For the ma & pa type residential networks, I doubt you will > see multiple machines behind a NAPT sourcing SSM. For more > corporate types, the network admin can control the allocation of > the SSM range. I moved text discussing what applications should do into an appendix, as the document's BCP scope is really around NATs (rather than applications that need to handle NATs). Based on your comment above, and some other input, the text now has the following paragraph. I believe this captures your suggestion. "If multiple SSM sources on the inside of a NAT choose the same multicast group address, those sources are uniquely identifiable because their IP addresses are unique. However, if their multicast traffic is NATted and sent on the NAT's public interface, the traffic from those individual sources is no longer uniquely identifiable. This will cause problems for multicast receivers which will see an intermixing of traffic from those sources. Resolution of this issue is left for future study. In the meantime, applications that source SSM multicast traffic are encouraged to allow the user to modify the multicast SSM address so that users can avoid this problem if that application is placed behind a NAT." The text doesn't quite go so far to say that a range has to be assigned = a priori. But let me know if it is acceptable. I have not submitted -09, but a preview is here if anyone wants to see = the full context: http://svn.resiprocate.org/rep/ietf-drafts/behave/draft-ietf-behave-multi= cast- 09.txt -d ------_=_NextPart_001_01C7E280.8B9D3121 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: = WGLC:draft-ietf-behave-multicast-06.txt=0A= =0A= =0A= =0A=
=0A=
My mistake. = The info is in the IP header.
=0A=
Alvaro
=0A=

=0A=
=0A= De: Alvaro Fernandez = [mailto:Alvaro@soportemv.com]
Enviado el: dom 19/08/2007 = 17:11
Para: Dan Wing; Brian Haberman
CC: = behave@ietf.org; Marshall Eubanks; mboned@ietf.org; = magma@ietf.org
Asunto: RE: [BEHAVE] Re: [magma] RE: [MBONED] = FW:WGLC:draft-ietf-behave-multicast-06.txt

=0A=
=0A=
=0A=
Hi,
=0A=
 
=0A=
Just another = comment:
=0A=
 
=0A=
If the sender behind the NAT = uses Ethernet and maps de lower 28 bits IP multicast address ( first = 4 bits are always 1110) to 23 bits in the multicast MAC address, = =BFwhich 5 high order bits uses the NAT to send the IP multicast = packets?
=0A=
 
=0A=
Considering that SSM = range is 232/8. How the NAT knows if the paquet is within the SSM = range?
=0A=
 
=0A=
Regards
=0A=
 
=0A=
Alvaro
=0A=

=0A=
=0A= De: Dan Wing = [mailto:dwing@cisco.com]
Enviado el: lun 13/08/2007 = 19:30
Para: 'Brian Haberman'
CC: 'Marshall Eubanks'; = mboned@ietf.org; Alvaro Fernandez; magma@ietf.org; behave@ietf.org; = 'Marshall Eubanks'; 'Toerless Eckert'
Asunto: RE: [BEHAVE] Re: = [magma] RE: [MBONED] FW: = WGLC:draft-ietf-behave-multicast-06.txt

=0A=
=0A=

> -----Original Message-----
> From: Brian = Haberman [mailto:brian@innovationslab.net<= /A>]
> Sent: Thursday, June 07, 2007 6:16 AM
> To: Dan = Wing
> Cc: 'Marshall Eubanks'; mboned@ietf.org; 'Alvaro = Fernandez';
> magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; = Toerless Eckert
> Subject: Re: [BEHAVE] Re: [magma] RE: [MBONED] = FW:
> = WGLC:draft-ietf-behave-multicast-06.txt
....
>
>
>> Dan Wing wrote:
> >> The NAPT knows what is SSM. = Couldn't it also do a Multicast Group 
> >> Translation = for SSM groups ? Why
> >> is this more difficult than, say, = port translation ?
> >
> > It may be fairly easy -- = except for rewriting the
> > advertisements in SAP,
> = > HTTP, HTTPS (a big problem there), email, SIP, RTSP, ....
> = >
> > And NAPTs don't do that kind of rewriting = today;
> > draft-ietf-behave-multicast
> > is only a = BCP and trying to describe what a NAT should best
> > be doing = as of
> > its date of publication.
> >
> = >
> > If we want NAPTs to do this, we would want a = different
> > document that was
> > standards-track = and that document would define how we
> > wanted NAPTs = to
> > perform this function.  However, I don't see a = successful
> > path if such an
> > operation would = require the NAPT to have an ALG for SAP,
> > HTTP, SIP, and = RTSP
> > and requires the NAT also rewrite those packets.  = We'd need
> > something else.
> > ALGs don't work well = for a variety of reasons.
>
> Given that, I would suggest = that the document state that
> administrators of the network = behind the NAPT assign sub-ranges
> of the SSM space to their = multicast sources.  This could be done
> manually or = *possibly* with the tools developed by the MALLOC
> WG.  For = the ma & pa type residential networks, I doubt you will
> see = multiple machines behind a NAPT sourcing SSM.  For more
> = corporate types, the network admin can control the allocation of
> = the SSM range.

I moved text discussing what applications should = do into an appendix,
as the document's BCP scope is really around = NATs (rather than
applications that need to handle NATs).  Based = on your comment above,
and some other input, the text now has the = following paragraph.  I
believe this captures your = suggestion.

  "If multiple SSM sources on the inside of a = NAT choose the same
   multicast group address, those = sources are uniquely identifiable
   because their IP = addresses are unique.  However, if their multicast
   = traffic is NATted and sent on the NAT's public interface, the = traffic
   from those individual sources is no longer = uniquely identifiable.
   This will cause problems for = multicast receivers which will see an
   intermixing of = traffic from those sources.  Resolution of this = issue
   is left for future study.  In the meantime, = applications that source
   SSM multicast traffic are = encouraged to allow the user to modify the
   multicast SSM = address so that users can avoid this problem if that
   = application is placed behind a NAT."

The text doesn't quite go so = far to say that a range has to be assigned a
priori.  But let me = know if it is acceptable.

I have not submitted -09, but a preview = is here if anyone wants to see the
full context:
http://svn.resiprocate.org/rep/ietf-drafts/behave/draft-ie= tf-behave-multicast-
09.txt

-d

------_=_NextPart_001_01C7E280.8B9D3121-- --===============0005860977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0005860977==-- From behave-bounces@ietf.org Mon Aug 20 02:33:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN0pb-0004xP-CS; Mon, 20 Aug 2007 02:33:43 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IN0pW-0004wQ-QF for behave-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 02:33:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN0pW-0004wI-E3 for behave@ietf.org; Mon, 20 Aug 2007 02:33:38 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN0pV-0005dE-Qd for behave@ietf.org; Mon, 20 Aug 2007 02:33:38 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7K6XTJi026753; Mon, 20 Aug 2007 09:33:34 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 09:33:05 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 09:33:04 +0300 Received: from esdhcp04062.research.nokia.com ([172.21.40.62]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 09:33:04 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, ext Jonathan Rosenberg Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-09.txt Date: Mon, 20 Aug 2007 09:33:04 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708200933.04645.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 Aug 2007 06:33:04.0613 (UTC) FILETIME=[F6A29950:01C7E2F3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 17 August 2007 18:20:01 ext behave-bounces@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Behavior Engineering for > Hindrance Avoidance Working Group of the IETF. Page 31: As far as I can tell as a non native speaker, "then the converting= =20 the result to network byte order" does not look grammatically correct. Otherwise, I am fine with this new revision document. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 20 07:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN5aN-0006dA-FI; Mon, 20 Aug 2007 07:38:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IN5aM-0006d2-4U for behave-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 07:38:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN5aL-0006cu-Qc; Mon, 20 Aug 2007 07:38:17 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN5aL-0004a9-AO; Mon, 20 Aug 2007 07:38:17 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7KBboZY026318; Mon, 20 Aug 2007 14:38:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 14:37:55 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 14:37:55 +0300 Received: from esdhcp04062.research.nokia.com ([172.21.40.62]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 14:37:54 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: ext Jonathan Rosenberg Date: Mon, 20 Aug 2007 14:37:55 +0300 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708201437.55515.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 Aug 2007 11:37:54.0900 (UTC) FILETIME=[8C7EE940:01C7E31E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: behave@ietf.org, mmusic@ietf.org Subject: [BEHAVE] STUN/ICE: Username length inconstency X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, It seems there is a minor error in the maximum username length between ICE-= 17=20 and RFC3489bis-09. STUN says USERNAME are at most 127 Unicode code points. There is no way a I= CE=20 user fragment of 1024 bytes could fit in there. I would assume the ICE ufra= g=20 should be limited to (127-1)/2 =3D 63 characters, so that the resulting STU= N=20 username is always within the 127 code points limits, including one code=20 point for the semi-colon. In any case, an ICE implemention that fails to obey this limit would fail t= o=20 interoperate with another instance of itself, which is pretty lame :) Also, it ensures the ICE connectivity check packets size remain within the= =20 minimum IPv4 MTU. I hope, that I either misunderstood something, or that this is a minor enou= gh=20 change that it can still be done this late in the process. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 20 10:04:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN7rV-0003pm-Dg; Mon, 20 Aug 2007 10:04:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IN7rU-0003pg-5v for behave-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 10:04:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN7rT-0003pV-SX for behave@ietf.org; Mon, 20 Aug 2007 10:04:07 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN7rS-0005zb-D4 for behave@ietf.org; Mon, 20 Aug 2007 10:04:07 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 16:03:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Aug 2007 16:03:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS mutual authentication for STUN Thread-Index: AcfjMuM2t/W8NrFwQe6BQ4PMkQ8m5Q== From: "BREARD Gael RD-SIRP-ISS" To: X-OriginalArrivalTime: 20 Aug 2007 14:03:40.0165 (UTC) FILETIME=[E9147350:01C7E332] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [BEHAVE] TLS mutual authentication for STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, =20 (My apology if this topic has already been addressed.) =20 STUN seems to only allow authentication based on a shared secret.=20 (And especially TURN requires it) =20 There is some scenario we do not have shared secret but a PKI = architecture. =20 Why do we not allow the use of TLS mutual authentication for STUN (and = so authorize it for TURN) ? =20 Moreover, when using TLS with "server only authentication", is it really = useful to challenge each request ? =20 Ga=EBl _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 20 11:02:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8ld-0003zG-Hk; Mon, 20 Aug 2007 11:02:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IN8lc-0003zB-8I for behave-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 11:02:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8lb-0003z3-TS for behave@ietf.org; Mon, 20 Aug 2007 11:02:07 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN8la-0007Qp-7L for behave@ietf.org; Mon, 20 Aug 2007 11:02:07 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7KF1gYs025936; Mon, 20 Aug 2007 18:02:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 18:01:42 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 18:01:42 +0300 Received: from esdhcp04062.research.nokia.com ([172.21.40.62]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 18:01:41 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext BREARD Gael RD-SIRP-ISS" Subject: Re: [BEHAVE] TLS mutual authentication for STUN Date: Mon, 20 Aug 2007 18:01:43 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708201801.43459.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 Aug 2007 15:01:41.0897 (UTC) FILETIME=[045A9790:01C7E33B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Monday 20 August 2007 17:03:30 ext BREARD Gael RD-SIRP-ISS wrote: > STUN seems to only allow authentication based on a shared secret. > (And especially TURN requires it) STUN defines three authentication profiles: =2D long-term client credentials =2D short-term client credentials =2D no client credentials STUN is only a framework... You can specify a usage that does not require=20 STUN-level client authentication, and then run it on top of TLS and use=20 TLS-level authentication. Or, you can use STUN-level authentication, and yo= u=20 have to specify how the credentials are obtained (e.g. ICE gets them from t= he=20 SDP). TURN is currently out of sync in how it obtains credentials, so it's diffic= ult=20 to comment on whether it does or does not allow something. > There is some scenario we do not have shared secret but a PKI architectur= e. > > Why do we not allow the use of TLS mutual authentication for STUN (and so > authorize it for TURN) ? STUN recommends that the client authenticates the server when TLS is used. This is pretty much common sense, otherwise you might as well not use TLS. It does not say the server cannot authenticate the client. Of course, the s= pec=20 does not require that, since most people use login/password pairs rather th= an=20 client-side certificates. > Moreover, when using TLS with "server only authentication", is it really > useful to challenge each request ? If there are no client-side certificates, the server needs to authenticate = the=20 client with *something*. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 20 11:27: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 1IN99w-0006Oi-KN; Mon, 20 Aug 2007 11:27:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IN99v-0006Od-9N for behave-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 11:27:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN99u-0006OV-W6 for behave@ietf.org; Mon, 20 Aug 2007 11:27:14 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN99t-0008I3-Gn for behave@ietf.org; Mon, 20 Aug 2007 11:27:14 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 17:27:04 +0200 Received: from [10.193.171.88] ([10.193.171.88]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 17:27:11 +0200 Message-ID: <46C9B2C6.9020606@orange-ftgroup.com> Date: Mon, 20 Aug 2007 17:27:02 +0200 From: BREARD Gael MAPS-ISS Organization: France Telecom R&D User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [BEHAVE] TLS mutual authentication for STUN References: <200708201801.43459.remi.denis-courmont@nokia.com> In-Reply-To: <200708201801.43459.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Aug 2007 15:27:11.0856 (UTC) FILETIME=[9447CF00:01C7E33E] X-Spam-Score: 1.2 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Rémi Denis-Courmont a écrit : > TURN is currently out of sync in how it obtains credentials, so it's difficult > to comment on whether it does or does not allow something. Ok, my concern was specifically about this sentence (turn-04 §6.1.2): Allocate requests MUST be authenticated, and furthermore, MUST be authenticated using either a shared secret known between the client and server, or a short term password derived from it. which seems to insist on the "shared secret" necessity. I only think it would be a good idea to allow (in TURN draft) no "STUN authentication" for allocate requests sent over TLS with mutual authentication. >> Moreover, when using TLS with "server only authentication", is it really >> useful to challenge each request ? > If there are no client-side certificates, the server needs to authenticate the > client with *something*. I agree, but it needs to be done (in principle) only *one* time in all the TLS session (not at each request). (Though I understand, it's simpler to do the same than in TCP case.) Gaël _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Aug 20 18:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFY9-0002j3-1c; Mon, 20 Aug 2007 18:16:41 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1INFY7-0002gZ-CJ for behave-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 18:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFY6-0002gN-Ko; Mon, 20 Aug 2007 18:16:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INFY5-0002E2-Ab; Mon, 20 Aug 2007 18:16:38 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Aug 2007 15:16:26 -0700 X-IronPort-AV: i="4.19,286,1183359600"; d="scan'208"; a="203412041:sNHT1657807002" 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 l7KMGQwm026695; Mon, 20 Aug 2007 15:16:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7KMGQF4006559; Mon, 20 Aug 2007 22:16:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 15:16:26 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 15:16:25 -0700 Message-ID: <46CA12C7.6020302@cisco.com> Date: Mon, 20 Aug 2007 18:16:39 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <200708201437.55515.remi.denis-courmont@nokia.com> In-Reply-To: <200708201437.55515.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Aug 2007 22:16:25.0965 (UTC) FILETIME=[BFAB81D0:01C7E377] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1585; t=1187648186; x=1188512186; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20STUN/ICE=3A=20Username=20length=20inconstency |Sender:=20; bh=ZAJdL4EqF8pIUENOk4XApHAqBvVrntu8kBSNh6nzkH4=; b=lZ2awQTAPFzfiPcu5+yLwW6YgLRpvyCreROf69r3CHy713AdQWyfo1ezXYtbvHCl1YyODn5f U9K0WdviUomphzLFSsQmLqDq6x8Z7AeEkgiRPcotypVia0VxnqnanyDJ; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: behave@ietf.org, mmusic@ietf.org Subject: [BEHAVE] Re: STUN/ICE: Username length inconstency X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org This is a good catch. I recently introduced the limit in STUN based on last call comments, forgetting that we had ICE use cases that could result in values longer than 127. I had picked 127 thinking about human readable usernames. My bad. I think the limit in STUN should be increased to match ICE, not the other way around. -Jonathan R. Rémi Denis-Courmont wrote: > Hello, > > It seems there is a minor error in the maximum username length between ICE-17 > and RFC3489bis-09. > > STUN says USERNAME are at most 127 Unicode code points. There is no way a ICE > user fragment of 1024 bytes could fit in there. I would assume the ICE ufrag > should be limited to (127-1)/2 = 63 characters, so that the resulting STUN > username is always within the 127 code points limits, including one code > point for the semi-colon. > > In any case, an ICE implemention that fails to obey this limit would fail to > interoperate with another instance of itself, which is pretty lame :) > Also, it ensures the ICE connectivity check packets size remain within the > minimum IPv4 MTU. > > I hope, that I either misunderstood something, or that this is a minor enough > change that it can still be done this late in the process. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 21 02:06:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INMsh-0006f0-Fh; Tue, 21 Aug 2007 02:06:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1INMsg-0006eu-9g for behave-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 02:06:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INMsf-0006em-TY for behave@ietf.org; Tue, 21 Aug 2007 02:06:21 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INMsf-0000YP-BF for behave@ietf.org; Tue, 21 Aug 2007 02:06:21 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7L66IwJ012944; Tue, 21 Aug 2007 09:06:19 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:06:12 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:06:12 +0300 Received: from esdhcp04062.research.nokia.com ([172.21.40.62]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:06:12 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext BREARD Gael MAPS-ISS" Subject: Re: [BEHAVE] TLS mutual authentication for STUN Date: Tue, 21 Aug 2007 09:06:14 +0300 User-Agent: KMail/1.9.6 References: <200708201801.43459.remi.denis-courmont@nokia.com> <46C9B2C6.9020606@orange-ftgroup.com> In-Reply-To: <46C9B2C6.9020606@orange-ftgroup.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708210906.15225.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 21 Aug 2007 06:06:12.0300 (UTC) FILETIME=[6008E8C0:01C7E3B9] X-Nokia-AV: Clean X-Spam-Score: 1.2 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Monday 20 August 2007 18:27:02 ext BREARD Gael MAPS-ISS wrote: > R=E9mi Denis-Courmont a =E9crit : > > TURN is currently out of sync in how it obtains credentials, so it's > > difficult to comment on whether it does or does not allow something. > > Ok, my concern was specifically about this sentence (turn-04 =A76.1.2): > > Allocate requests MUST be authenticated, and > furthermore, MUST be authenticated using either a shared secret known > between the client and server, or a short term password derived from > it. > > which seems to insist on the "shared secret" necessity. You need a shared secret to secure UDP or TCP STUN requests, and it would b= e=20 pretty suboptimal to use TLS for bulk relayed traffic, *except* when you ha= ve=20 to use TLS because HTTP CONNECT is your only way out. In fact, RTP over TLS= =20 very much sucks and is really the fallback of fallback cases. If you want to encrypt the bulk content, you'd better do it end-to-end (wit= h=20 SRTP or DTLS), not end-to-relay. Hence, if you want to use a PKI for authentication, what you would want is = the=20 infamous Shared Secret Request. It's been purposedly removed because nobody= =20 ever implemented it. And with the implementor hat, if it were ever to be=20 reintroduced, I would rather it could be done over DTLS, than need a TCP=20 connection to the relay. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 21 02:27: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 1INNCv-0005ua-0j; Tue, 21 Aug 2007 02:27:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1INNCp-0005uR-Ll for behave-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 02:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNCo-0005uJ-Sw; Tue, 21 Aug 2007 02:27:11 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INNCn-0005EI-Dl; Tue, 21 Aug 2007 02:27:10 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7L6QgBU019706; Tue, 21 Aug 2007 09:27:05 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:26:42 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:26:42 +0300 Received: from esdhcp04062.research.nokia.com ([172.21.40.62]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:26:42 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Jonathan Rosenberg" Date: Tue, 21 Aug 2007 09:26:44 +0300 User-Agent: KMail/1.9.6 References: <200708201437.55515.remi.denis-courmont@nokia.com> <46CA12C7.6020302@cisco.com> In-Reply-To: <46CA12C7.6020302@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708210926.45072.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 21 Aug 2007 06:26:42.0065 (UTC) FILETIME=[3D082810:01C7E3BC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: behave@ietf.org, mmusic@ietf.org Subject: [BEHAVE] Re: STUN/ICE: Username length inconstency X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 21 August 2007 01:16:39 ext Jonathan Rosenberg wrote: > This is a good catch. I recently introduced the limit in STUN based on > last call comments, forgetting that we had ICE use cases that could > result in values longer than 127. I had picked 127 thinking about human > readable usernames. My bad. I think the limit in STUN should be > increased to match ICE, not the other way around. Hmm, I am not sure 1023 character long username are that great really. For = a=20 start, after concatenation (2047 characters), you'll get connectivity check= s=20 that exceed the typical Internet MTU. That brings either problem: =2D NATs will not handle fragmented packets, or =2D ICE implementation will refuse to send at all (packet too big). Second, I wonder if if makes sense to have a higher entropy for the usernam= e=20 (12,000 bits here!) than we have for the message integrity (160 bits=20 currently) or the shared secret password. But that's something for security= =20 gurus to judge. Even if we switched to SHA512, we'd still have more than=20 enough username entropy with just 63 characters from each sides (756 bits). Third, we do not want to drain the entropy pool of ICE-capable device too=20 badly. There are better stuff to dedicate entropy to that ICE connectivity= =20 checks, such as generating TLS parameters. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 21 04:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INOyK-0005OB-HK; Tue, 21 Aug 2007 04:20:20 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1INOyJ-0005O6-Ot for behave-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 04:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INOyJ-0005Nx-EF for behave@ietf.org; Tue, 21 Aug 2007 04:20:19 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INOyJ-00085i-1b for behave@ietf.org; Tue, 21 Aug 2007 04:20:19 -0400 Received: by py-out-1112.google.com with SMTP id f31so4226797pyh for ; Tue, 21 Aug 2007 01:20:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=dOpcvYAH7IRCLm57kjK/8dgIoqKtvqHmqyY7Djm3D5dI29dd7RWwJGK8YVXUNC9HlQMXuGBbkknG+jy1lA5PxgE9h+rYY1sWOjtSZkD6p0ZmJO2BY8/oUJFAf7rKsClMP8kWydxCVqb9CCMkqgfe9LMZd8LXcZ33i3oNKYbjtsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=EuEnl5mbYfAqavt5GrFshUUizUN03fxoRKLQClBYMon6FEM5i3uoFnxrOtXPPL89xaaKF8RmCkqF82Op/NTzevaNiw9z9csnhTBMLKM1cmUcPxFsok/A9+RaA6oWnSZerOLVIVg2pUbulLuy4p/qMZV1f8CbSM/9ub0u+LLRiOE= Received: by 10.142.77.11 with SMTP id z11mr689668wfa.1187684417698; Tue, 21 Aug 2007 01:20:17 -0700 (PDT) Received: by 10.143.31.8 with HTTP; Tue, 21 Aug 2007 01:20:17 -0700 (PDT) Message-ID: <8f8143dc0708210120q760e45dav9e128de772a134ca@mail.gmail.com> Date: Tue, 21 Aug 2007 10:20:17 +0200 From: "=?ISO-8859-1?Q?Ga=EBl_Br=E9ard?=" To: "=?ISO-8859-1?Q?R=E9mi_Denis-Courmont?=" Subject: Re: [BEHAVE] TLS mutual authentication for STUN In-Reply-To: <200708210906.15225.remi.denis-courmont@nokia.com> MIME-Version: 1.0 References: <200708201801.43459.remi.denis-courmont@nokia.com> <46C9B2C6.9020606@orange-ftgroup.com> <200708210906.15225.remi.denis-courmont@nokia.com> X-Google-Sender-Auth: b5ab430e48099cc8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0583369320==" Errors-To: behave-bounces@ietf.org --===============0583369320== Content-Type: multipart/alternative; boundary="----=_Part_182757_13450692.1187684417657" ------=_Part_182757_13450692.1187684417657 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2007/8/21, R=E9mi Denis-Courmont : > > > You need a shared secret to secure UDP or TCP STUN requests, and it would > be > pretty suboptimal to use TLS for bulk relayed traffic, *except* when you > have > to use TLS because HTTP CONNECT is your only way out. In fact, RTP over > TLS > very much sucks and is really the fallback of fallback cases. I agree. (note: with some proxy/fw you do not need TLS after HTTP CONNECT) If you want to encrypt the bulk content, you'd better do it end-to-end (wit= h > SRTP or DTLS), not end-to-relay. > > > Hence, if you want to use a PKI for authentication, what you would want i= s > the > infamous Shared Secret Request. yes... It's been purposedly removed because nobody > ever implemented it. And with the implementor hat, if it were ever to be > reintroduced, I would rather it could be done over DTLS, than need a TCP > connection to the relay. except when HTTP CONNECT is your only way out ;) ... Thanks for your answers. Ga=EBl ------=_Part_182757_13450692.1187684417657 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

2007/8/21, R=E9mi Denis-Courmont &= lt;remi.denis-courmont@nok= ia.com>:

You need a shared secret to secure UDP or TCP STUN requests, and it wou= ld be
pretty suboptimal to use TLS for bulk relayed traffic, *except* wh= en you have
to use TLS because HTTP CONNECT is your only way out. In fac= t, RTP over TLS
very much sucks and is really the fallback of fallback cases.

I agree.  (note: with some proxy/fw you do not need TLS af= ter HTTP CONNECT)

If you want to encrypt the bulk content, you'd better do it end-to-end = (with
SRTP or DTLS), not end-to-relay.


Hence, if you want to = use a PKI for authentication, what you would want is the
infamous Shared= Secret Request.=20

yes...

It's been purposedly removed because nobody ever implemented it. And with the implementor hat, if it were ever to bereintroduced, I would rather it could be done over DTLS, than need a TCPconnection to the relay.

except when  HTTP CONN= ECT is your only way out ;) ...

Thanks for your answers.

Ga=EBl

------=_Part_182757_13450692.1187684417657-- --===============0583369320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0583369320==-- From behave-bounces@ietf.org Fri Aug 24 08:32:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOYLG-0005NM-4E; Fri, 24 Aug 2007 08:32:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IOYLF-0005NH-C0 for behave-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 08:32:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOYLF-0005N9-1i for behave@ietf.org; Fri, 24 Aug 2007 08:32:45 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOYLE-00026M-H9 for behave@ietf.org; Fri, 24 Aug 2007 08:32:44 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7OCWMB9001331 for ; Fri, 24 Aug 2007 15:32:42 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 15:32:40 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 15:32:40 +0300 Received: from esdhcp04089.research.nokia.com ([172.21.40.89]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 15:32:40 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Fri, 24 Aug 2007 15:32:38 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070508.662491) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708241532.39020.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 24 Aug 2007 12:32:40.0411 (UTC) FILETIME=[DC771AB0:01C7E64A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [BEHAVE] TURN Set Active Destination problem (again) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, About Set Active Destination over UDP, TURN-04 says: If the active destination is already set and the request was received over UDP, the Set Active Destination request is rejected with a 439 Active Destination Already Set error response. This prevents the race condition described in the previous section. If however, the successful response to a Set Active Destination request got= =20 lost, the request is retransmitted. But then, following the current rule, t= he=20 server returns 439. Well, in theory, it must return a success response agai= n,=20 as it should see that the transaction ID is the same as a previous request,= =20 and apply the idempotency principle, but that's a impractical. May I suggest that the server would return a successful response whenever i= t=20 receives a Set Active Destination request where the REMOTE-ADDRESS is=20 identical to the currently active destination? =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 28 20:16:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQBES-0002Fg-EX; Tue, 28 Aug 2007 20:16:28 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IQBEQ-0002Fb-TW for behave-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 20:16:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQBEQ-0002FT-HJ for behave@ietf.org; Tue, 28 Aug 2007 20:16:26 -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 1IQBEP-0004nP-To for behave@ietf.org; Tue, 28 Aug 2007 20:16:26 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 28 Aug 2007 17:16:25 -0700 X-IronPort-AV: i="4.19,319,1183359600"; d="scan'208"; a="518155139:sNHT50763664" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7T0GPu7021022; Tue, 28 Aug 2007 17:16:25 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l7T0GIxm011904; Wed, 29 Aug 2007 00:16:18 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43E08DFF-F4FE-4848-B530-6D7F3CB41DE2@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Tue, 28 Aug 2007 17:14:54 -0700 To: Behave WG , Jonathan Rosenberg , Rohan Mahy X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3546; t=1188346585; x=1189210585; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Comments=20on=20draft-ietf-behave-turn-04 |Sender:=20; bh=uy41j1rHWqZ6WgzZYMR77zTc6pSGPKb+Y+gsZk1qHOE=; b=V1qrzFOEm8gfOH1klrM+1DuqKahwbYvY6N+svM0X+SM5aDh9INaI4G8TkXbcYFv+w50oqpXm iMLwwhOjyRxBFh83i9S6YsgN6imbeDO4nmNIILfWJSlJoA1qlTw/70tJ; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 1.2 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: [BEHAVE] Comments on draft-ietf-behave-turn-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org This document is looking very good - few big items I don't understand when a server would send a status indication with the state as LISTEN. Can we remove this value? I'm a bit lost on auth stuff - probably need separate thread on that. 3489bis removed a way to get short term secrets but turn seems to assume they are still there. More importantly, we need to have some sort of security on the connection status indication bet since this can not be challenged, we can only use short term credentials. However, it's not clear how to get one. I suspect we may need a conference call some time on STUN/TURN credentials. It's not clear that the right message have enough in them to make replay attacks not be a problem for short term credentials usage. What happens when relay receives more than it can send. My initial thought on this is 1) when receiving UDP packets, discard them. 2) when receiving TCP, stop reading from the incoming TCP buffer until their is space to send. If there are multiple incoming TCP connection, order they get serviced in is not specified and clients can't make any assumptions about it. If a client ends up with two remote TCP connection (on the same allocation), it would be nice to have a way to close one of them but not the other. The connection status indication probably needs the remote address attribute so that one can figure out what is going on when there are two TCP connection to same allocation. Section 6.1.2.1 .. the idea that a move can be signaled by using the same credential would work for short term credentials but not long term ones as more than one client can share the same long term. I find this "move" idea fraught with peril to implement - particularly in the TCP case, I wonder if we really need it. I have a hard time imaging an TCP connection with active data flowing not getting out of sync during a move. The redirect to a different server when overloaded seems like a bad idea. Imagine I have two servers A and B that are both overloaded - seems like I could have endless redirects. Having the client know about two servers via DNS then try one and if it is busy try the other makes more sense to me. It might make sense to suggest that after a TCP allocation happened, the TURN server using BSD sockets would not want to start listening on it until their was at least one valid permission set on it. Trivial stuff after this .... Be nice to have an example showing TCP simultaneous open. Section 4.1 - 2nd para - you suggest that there are cases where TLS will get thorough a firewall and TCP will not - this is true but so is the converse so don't want to imply one way or other is better for firewall traversal. Figure 1 - would make more sense to me with s/STUN/TURN Section 6.1.2.1 - It is confusing how the client would know what IP address the server supports for relaying when the client wants to use the REQUEST-IP attribute. If you added some text explaining that this was used when allocating a second port after first port was allocated, it would be easier to understand. In The server SHOULD only allocate ports in the range 1024-65535. This is one of several ways to prohibit relayed transport addresses from being used to attempt to run standard services. This does not seem to be a good way (or the way used in the draft) to accomplish this so I would just delete the second sentence. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Aug 28 20:28:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQBQ7-0002uv-Dc; Tue, 28 Aug 2007 20:28:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IQBQ6-0002pA-C3 for behave-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 20:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQBQ6-0002n2-1V for behave@ietf.org; Tue, 28 Aug 2007 20:28:30 -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 1IQBQ4-0006DH-Qg for behave@ietf.org; Tue, 28 Aug 2007 20:28:30 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 28 Aug 2007 17:28:29 -0700 X-IronPort-AV: i="4.19,319,1183359600"; d="scan'208"; a="395184521:sNHT46117994" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7T0SSwE025680; Tue, 28 Aug 2007 17:28:28 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l7T0SQFZ005160; Wed, 29 Aug 2007 00:28:26 GMT In-Reply-To: References: <049501c7c89d$d34da410$7d646b80@amer.cisco.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AD97F50-725E-4F28-A424-C7C0BAF295B4@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] RE: ICE performance Date: Tue, 28 Aug 2007 17:27:02 -0700 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1013; t=1188347308; x=1189211308; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20RE=3A=20ICE=20performance=20 |Sender:=20; bh=aKK16JtiwuPBCKuuwjegk3YfCEfCpZ18/WBWE1eTbjo=; b=C6QbDs613Kzjzms0GLedZnhaCl/tB5eOwC2uh3r5A4E/miC5ptH7xb3zfUpgtpRS9Q2QoWiQ 8vqvbODr4U+WcaODI9us1f7I9YgSOOWP6Iw31tJtdVJgAYeroqBLNz8p; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Jul 19, 2007, at 6:05 AM, Philip Matthews wrote: > > I will just note that Saikat implemented port prediction in his TCP > study > and found it worked pretty well. > > http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf > > However, I think his setup was more of > a test setup rather than a production setup. I ddi some testing on port prediction awhile back and it worked out very poorly for me. Port prediction did not really work at all when you have thousands of users behind a single service provider NAT. The rate new flows on the NAT is just too fast. It also runs into serious problems when you starting having a single client behind a NAT but several things happen at the same time on the client. You might think the applications are not correlated but they turned out not to be - right when one was trying to set up nat pinholes at the start of the call was when - even another application - decided to do something else that was triggered by the call. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 29 04:53:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJJ3-0006u0-Pd; Wed, 29 Aug 2007 04:53:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IQJJ2-0006rY-TB for behave-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 04:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJJ2-0006rP-Es for behave@ietf.org; Wed, 29 Aug 2007 04:53:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQJJ0-0000nY-Lh for behave@ietf.org; Wed, 29 Aug 2007 04:53:43 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C61392023D; Wed, 29 Aug 2007 10:53:41 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-f3-46d53415a4b1 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7011620FEA; Wed, 29 Aug 2007 10:53:41 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 10:53:41 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 10:53:41 +0200 Message-ID: <46D53414.5050808@ericsson.com> Date: Wed, 29 Aug 2007 10:53:40 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC References: <136097.58028.qm@web33305.mail.mud.yahoo.com> In-Reply-To: <136097.58028.qm@web33305.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 08:53:41.0200 (UTC) FILETIME=[18F35D00:01C7EA1A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, A couple of comments, but I don't see that we are going anywhere productive. First of all, I can agree with it being regretable that there aren't energy in the WG to document what to consider when designing solutions. But, I can't force people (much) to do things. There need to be sufficient support. It is obvious that people will design applications and protocols that will do hole punching and not use ICE and STUN. Regarding the references, as you presented them earlier, it didn't appear that they where prior art to the IETF work. Although, the common courtesy is to reference where one have gotten the ideas, I think this is not a simple case to find who is first with a idea. There also usually a chain of refinements. Putting that history into a standards document, is bloating it and mostly irrelevant to the one actually implementing something. 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 From behave-bounces@ietf.org Wed Aug 29 11:57:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPuy-000615-GF; Wed, 29 Aug 2007 11:57:20 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IQPux-000610-GT for behave-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 11:57:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPux-00060B-5k for behave@ietf.org; Wed, 29 Aug 2007 11:57:19 -0400 Received: from www.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQPuw-0006sj-RR for behave@ietf.org; Wed, 29 Aug 2007 11:57:19 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 017243A02022; Wed, 29 Aug 2007 08:57:17 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 644943A02020; Wed, 29 Aug 2007 08:56:36 -0700 (PDT) Message-ID: <46D59733.8070703@acm.org> Date: Wed, 29 Aug 2007 08:56:35 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-04 References: <43E08DFF-F4FE-4848-B530-6D7F3CB41DE2@cisco.com> In-Reply-To: <43E08DFF-F4FE-4848-B530-6D7F3CB41DE2@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Rohan Mahy , Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Cullen Jennings wrote: > [snip] > > The redirect to a different server when overloaded seems like a bad > idea. Imagine I have two servers A and B that are both overloaded - > seems like I could have endless redirects. Having the client know about > two servers via DNS then try one and if it is busy try the other makes > more sense to me. > I agree that using the redirect in this case will not really help. My proposal was to send back a domain name instead of an IP address, and to use it in the client in replacement of the current domain used to find the SRV records, but by remembering all the IP addresses already tried and excluding them from the results of the subsequents SRV queries. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 29 18:16:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQVqA-0007Ze-Qq; Wed, 29 Aug 2007 18:16:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IQVq1-0007R1-Rr for behave-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 18:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQVq0-0007OI-PO for behave@ietf.org; Wed, 29 Aug 2007 18:16:36 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQVpz-0004U8-Hz for behave@ietf.org; Wed, 29 Aug 2007 18:16:36 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 Aug 2007 15:16:35 -0700 X-IronPort-AV: i="4.19,323,1183359600"; d="scan'208"; a="208938765:sNHT44377056" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7TMGZ8S004665; Wed, 29 Aug 2007 15:16:35 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l7TMGTYb013222; Wed, 29 Aug 2007 22:16:29 GMT In-Reply-To: <46D59733.8070703@acm.org> References: <43E08DFF-F4FE-4848-B530-6D7F3CB41DE2@cisco.com> <46D59733.8070703@acm.org> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B53CED5-5A4B-488D-8F15-5421E7E5AD8E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-04 Date: Wed, 29 Aug 2007 15:15:03 -0700 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1249; t=1188425795; x=1189289795; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20Comments=20on=20draft-ietf-behave-turn-04 |Sender:=20; bh=335kBAMQz6EROC6xdYOSnk9eYFVVQGFsFjXG8s9GRMg=; b=MeD7crK6Ved/WadKcwnvw5RcUU1I7FePjQDb1kWMKDpz4XGRkbaV65IUUFMKBwTwarQa3I9v Ki+DsMINNRHNnb8vnMN3IqN7rBCQ5emvTTzoDkI5A3D8lun+ADxK6WDWIx72+NmlwVA6U2f9mz E2TumynYzq27D0/3t+CRtxyqE=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Rohan Mahy , Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Ah, I see what you are thinking but seems like it would be better to just start out with the SRV record and never need the redirect. On Aug 29, 2007, at 8:56 AM, Marc Petit-Huguenin wrote: > Cullen Jennings wrote: >> > > [snip] > >> >> The redirect to a different server when overloaded seems like a bad >> idea. Imagine I have two servers A and B that are both overloaded - >> seems like I could have endless redirects. Having the client know >> about >> two servers via DNS then try one and if it is busy try the other >> makes >> more sense to me. >> > > I agree that using the redirect in this case will not really help. My > proposal was to send back a domain name instead of an IP address, > and to > use it in the client in replacement of the current domain used to find > the SRV records, but by remembering all the IP addresses already tried > and excluding them from the results of the subsequents SRV queries. > > > -- > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Aug 29 19:12:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQWiD-0005tY-FP; Wed, 29 Aug 2007 19:12:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IQWiB-0005sh-59 for behave-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 19:12:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQWi8-0005rt-Um for behave@ietf.org; Wed, 29 Aug 2007 19:12:34 -0400 Received: from www.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQWi8-00084F-Bh for behave@ietf.org; Wed, 29 Aug 2007 19:12:32 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 82EA63A02022; Wed, 29 Aug 2007 16:12:29 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 09D523A02020; Wed, 29 Aug 2007 16:12:26 -0700 (PDT) Message-ID: <46D5FD5A.4060003@acm.org> Date: Wed, 29 Aug 2007 16:12:26 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-04 References: <43E08DFF-F4FE-4848-B530-6D7F3CB41DE2@cisco.com> <46D59733.8070703@acm.org> <3B53CED5-5A4B-488D-8F15-5421E7E5AD8E@cisco.com> In-Reply-To: <3B53CED5-5A4B-488D-8F15-5421E7E5AD8E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Rohan Mahy , Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Cullen Jennings wrote: > > Ah, I see what you are thinking but seems like it would be better to > just start out with the SRV record and never need the redirect. Yes, but the redirect permits to do things a little bit more dynamically. Here's an example: Let's say we have 3 data centers, one in London, one in Santa Clara, CA and another in Hong Kong. The initial SRV lookup for the example.com domain returns this: SRV 0 1 3478 redirect.london.example.com. SRV 0 1 3478 redirect.santa-clara.example.com. SRV 0 1 3478 redirect.hong-kong.example.com. All RR have the same priority, so one of them is randomly selected. The client sends the request to the server, the server uses a geoip lookup to detect the closer data center to the client, and sends a redirect with the domain hong-kong.example.com. The client then do a SRV query for hong-kong.example.com, with the following result: SRV 0 1 3478 turn1.hong-kong.example.com. SRV 0 1 3478 turn2.hong-kong.example.com. SRV 1 1 3478 turn1.santa-clara.example.com. SRV 1 1 3478 turn2.santa-clara.example.com. SRV 1 1 3478 turn1.hong-kong.example.com. SRV 1 1 3478 turn2.hong-kong.example.com. The TURN servers in the Hong Kong data center will be tried first, then the TURN servers in the other data centers if they are unreachable. Note that this is just an example, there is better ways to achieve the same result. > > On Aug 29, 2007, at 8:56 AM, Marc Petit-Huguenin wrote: > >> Cullen Jennings wrote: >>> >> >> [snip] >> >>> >>> The redirect to a different server when overloaded seems like a bad >>> idea. Imagine I have two servers A and B that are both overloaded - >>> seems like I could have endless redirects. Having the client know about >>> two servers via DNS then try one and if it is busy try the other makes >>> more sense to me. >>> >> >> I agree that using the redirect in this case will not really help. My >> proposal was to send back a domain name instead of an IP address, and to >> use it in the client in replacement of the current domain used to find >> the SRV records, but by remembering all the IP addresses already tried >> and excluding them from the results of the subsequents SRV queries. >> -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Aug 30 18:22:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQsPG-0006LX-45; Thu, 30 Aug 2007 18:22:30 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IQsPE-0006LS-Gg for behave-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 18:22:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQsPE-0006LK-4D for behave@ietf.org; Thu, 30 Aug 2007 18:22:28 -0400 Received: from submit01.sysedata.no ([195.159.29.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQsPD-0006s2-E8 for behave@ietf.org; Thu, 30 Aug 2007 18:22:27 -0400 Received: from [84.215.127.238] (helo=[10.0.0.8]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1IQsPB-00074A-Jl; Fri, 31 Aug 2007 00:22:25 +0200 Message-ID: <46D74320.60101@db.org> Date: Fri, 31 Aug 2007 00:22:24 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Behave WG , jdrosen@cisco.com, rohan@ekabal.com, huitema@microsoft.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Subject: [BEHAVE] Comments on draft-ietf-behave-turn-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Comments on draft-ietf-behave-turn-04 Technical Review by Alfred E. Heggestad 30. Aug 2007 General: - Did we consider the scenario where the NAT between the TURN client and the TURN server reboots? In such a case both TURN client and server will still send and receive data (such as RTP), and if NAT in between reboots, a new NAT mapping will be created. The TURN server will not be able to update the 5-tuple for the "flow" and the result is no RTP data send/received. If we can use some kind of unique "Session ID" for the TURN allocation, it will still be possible to handle the cases where the NAT reboots. On Allocate Request the client could choose a unique 64-bit session ID, which will be used in all future communications with the server (for that session). Alternatively, the TURN server could keep track of all session IDs, and allocate it for the client (returned in Allocate Response). All sub- sequent TURN messages from the client will then contain this 64-bit session ID, and the TURN server can lookup the allocation (Session) without looking at the Source IP+port. Now, this will probably also introduce some new security issues.. - Why is the FINGERPRINT attribute not mentioned at all in TURN ? - There are still references to "Shared Secret request", in section 6.1.1.1 and 6.1.1.2. This is removed in rfc3489bis-08 and should also be removed in TURN - The BANDWIDTH parameter is a bit problematic, since the TURN allocation is normally done before an SDP Offer is sent. If a user-agent is sending an SDP offer with audio codecs G.711 (64 kbps) and G.729 (8 kbps) it will use the highest bandwidth (64 kbps) to the TURN server. When the call is established with G.729, it should be possible to send an update to the TURN server, telling it that the bandwidth need changed to 8 kbps > Section 4 > > When the TURN client to server communication is over a datagram > protocol (UDP), any datagram received from the active peer that has > the STUN magic cookie is wrapped in a Data Indication. Likewise any > datagram sent by the client that has the STUN magic cookie and is > intended for the active peer is wrapped in a Send Indication. This > wrapping prevents the STUN relay server from inappropriately > interpreting end-to-end data. Does this mean that the TURN client/server has to scan the whole datagram looking for the STUN magic cookie? I think not, and I would assume that it only need to check the 20 first bytes of the datagram. > Section 6.2 > > Response with an appropriate error response code, such as a 431 > (Integrity Failure) or 436 (Unknown User). error codes 431 and 436 are no longer in rfc3489bis-09 > 6.5. Connection Status Indication > > When the TURN to peer leg is TCP, the TURN client needs to be aware > of the status of these TCP connections. The TURN extension defines > application states for a TCP connection as follows: LISTEN, > ESTABLISHED, CLOSED. Consequently, the TURN server sends a Probably a new state should be defined, if the TCP connection failed (host unreachable, port unreachable) > 7.9. CONNECT_STAT > > This attribute is used by... It should be mentioned which TURN Requests/Responses/Indications this attribute is valid for. > 17.2. Informative References > Should be updated: [1] draft-ietf-behave-rfc3489bis-06 -> draft-ietf-behave-rfc3489bis-09 [8] draft-ietf-mmusic-ice-16 -> draft-ietf-mmusic-ice-16 [9] draft-ietf-behave-nat-udp-08 -> RFC 4787 ------------------------------------------------------------------------------ NITS General: There is a mix of "Allocate request" and "Allocate Request" in the document. This term should be consistantly used, and either stick to one of them. > Abstract > > ..Relays around NAT (TURN), is useful for elements behind NATs whose > mapping behavior is address and port dependent. The extension.. ^^^^^^^^^^^^^^^^^^^^^^^^^^ TURN is also useful for elements behind "Address-Dependent Mapping" NATs, right? Ideally this should be written "..whose mapping behavior is NOT Endpoint-Independent Mapping.." Terminology from RFC 4787: - Endpoint-Independent Mapping: - Address-Dependent Mapping: - Address and Port-Dependent Mapping: > 6.1.1.1. Initial Requests > > ... > adajacent pair, even and odd respectively, for compatibility with a ^^^^^^^^^ typo, should be "adjacent" _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Aug 31 18:39:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRF92-0007lS-6P; Fri, 31 Aug 2007 18:39:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IRF8z-0007gD-Qo for behave-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 18:39:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRF8z-0007bt-Cf for behave@ietf.org; Fri, 31 Aug 2007 18:39:13 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRF8y-0004ku-58 for behave@ietf.org; Fri, 31 Aug 2007 18:39:13 -0400 Received: from [192.168.0.3] (cpe-76-183-190-193.tx.res.rr.com [76.183.190.193]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l7VMd6i2032570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2007 17:39:10 -0500 (CDT) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84CA6498-1F9A-4AAF-A19E-6BDD647B55CE@estacado.net> Content-Transfer-Encoding: 7bit From: Brian Hibbard Date: Fri, 31 Aug 2007 17:38:53 -0500 To: behave@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [BEHAVE] Comments on draft-ietf-behave-turn-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org TCP ------ I'm unclear on exactly how the TCP Connect request is supposed to work. I noticed that there is nothing in TURN-04 that says how an allocation enters LISTEN, although previous versions stated that an allocation would enter LISTEN at the time of allocation. If the intent is that simultaneous open is the sole means by which allocations can connect to each other, I have a difficult time believing this is feasible. In order for that to work as true simultaneous open, the SYNs must cross on the wire. Assuming a BSD- ish implementation, if they don't cross on the wire, you have the possibility that a SYN will be received on a socket that is still in the CLOSED pseudo-state. On Mac OSX, the SYN received in CLOSED (socket is bound but not listen()ing ) is silently absorbed and both sides will retransmit until something that looks similar to simultaneous open happens. On Linux, when SYN is received in CLOSED (as before--bound but not listening), an RST is transmitted, and the connection attempt is terminated. Unless there is some means outside of TURN to guarantee that Connect requests are sent such that SYNs literally cross on the wire (so that both receivers are in SYN_SENT and not CLOSED), I don't see how you can expect that mechanism to work well. Of course, there are things one might do to suppress the RST so SYN retransmissions might occur, but an RST to a SYN received in CLOSED doesn't sound wrong to me. Therefore, it looks better to establish a good way to manage whether an allocation is LISTENing, or that it is actively connecting, and that it is not doing both simultaneously. Previously on the BEHAVE list, a way to do both was brought up, but, while interesting, sounds like an exploit and forces an implementation into the dark nether regions of platform-specific behavior. The fact that the socket API doesn't allow a bind() if a socket is already listen()ing is something TURN should respect. Besides, most clients that get retrofitted with TURN probably want to treat TURN as a shim in their transports to the greatest extent possible, and won't be interested in building a bunch of special behavior around TURN's peculiar LISTEN- while-Connect-request capability even if you did manage to solve that issue. Those implementations would simply grab a new port when they want to make a new connection--just like how everyone does today. Also, multiplexing traffic across multiple TCP connections within a single allocation has been brought up on the list before. I agree that it would be powerful and desirable to do that...if you could do it properly. It's the "properly" part that scares me. I think there is a class of use cases that this mechanism could support well. Such cases would be where only one of the connections is sending "lots" of traffic, and the other(s) are sending "little". (Ignore, for the time being, how the TURN server would distinguish this subset of possibilities and allow them while suppressing the others a priori.) This presumes that we have a good way to adjudicate BANDWIDTH control. From the spec, it sounds like BANDWIDTH is meant to cap the traffic on the allocation. Is this for the sum off all permissions, and in both directions? Exactly what the TURN server does to constrain this traffic hasn't been addressed. Discarding chunks of data in TCP could cause a painful loss of framing for higher level protocols, such as SIP. The only other options that are obvious are to throttle reading from the client and all of the allocation's peer connections and let TCP manage the congestion, or tear down with RST. Exactly how you divide the bandwidth between reading each of the connections involved needs a lot of discussion. It would be terrible if the media stream starved the signaling stream, and TURN can't tell the difference. Therefore, I would be greatly relieved if multiple TCP connections on a single allocation were not supported. Set Active Destination ---------------------------------- For UDP, it would be reasonable to suggest that the client start using Send indications shortly before (perhaps as long as one second?) sending a Set Active Destination request to clear the current active destination. This would help the case that some of the packets sent prior to the SAD are processed by the server after the SAD is processed, due to packet ordering. Thanks, Brian Hibbard Estacado Systems _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave