From behave-bounces@ietf.org Sun Apr 01 18:11: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 1HY8Fm-0003AT-4K; Sun, 01 Apr 2007 18:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY8Fk-00032k-0Z for behave@ietf.org; Sun, 01 Apr 2007 18:10:24 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HY8Ff-0004D6-JF for behave@ietf.org; Sun, 01 Apr 2007 18:10:23 -0400 Received: (qmail 11291 invoked by uid 60001); 1 Apr 2007 22:10:19 -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=eCXYqR1ZSq7YUj/nl7g7L4djOzSC2Kma2h//bY2mbBpMmtfaTNJOCgK0ErTVRTFnwn+JruZLN2S8bABZg3KmbiG/G1gj6UhzPfgWEKV5qQ4JPWeKL5It2dVgYXtlJGCoph01GNtz2cmy+dCwgZ/M26a1At1EOwcxrCyS5lBeW0o=; X-YMail-OSG: OHkfm6QVM1nXZzfg8tcT9.OVKbp5x3F2wcC19WmH6jQfPv0KDoCQAEOTUg3TAIkt5xFq_c4CQseTOdJwEenNl7YO9rTWad8Za3s3j0HDg34HdS0- Received: from [209.172.74.45] by web33312.mail.mud.yahoo.com via HTTP; Sun, 01 Apr 2007 15:10:18 PDT Date: Sun, 1 Apr 2007 15:10:18 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: Philip Matthews , David Barrett In-Reply-To: <20D09E88-7BA9-49BD-93C9-2969B3C31F41@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <980067.9532.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Sorry to be late on this thread. I have been swarmed with my day job work past few days. My comments inline below. regards, suresh --- Philip Matthews wrote: > > On 21-Mar-07, at 19:38 , David Barrett wrote: > > > > > Nobody's arguing for the destruction of ICMP. It's a question of > > whether > > BEHAVE mandates that NATs support a minimal subset of protocols > > (ICMP, TCP, > > UDP) or not. > > > > Both positions are reasonable: > > - BEHAVE defines the behavior for several optional protocols > > - BEHAVE defines the behavior for several mandatory protocols > > > > I think I fall in the first camp: if a NAT is going to support ICMP > > (or UDP, > > or TCP) at all, it should support it as BEHAVE dictates. If the > > NAT for > > some reason doesn't support ICMP (or UDP, or TCP), then it need > > only comply > > with BEHAVE for those protocols it chooses to support. > > > > Given that there are more protocols than just ICMP, TCP, and UDP, > > this seems > > the only sustainable path. > > > > I think David raises a very good point that we need to clear up. > Personally, I also fall in the first camp. > [suresh] Right, David puts it well and raises a good point. I agree, the BEHAVE WG is defining requirements for various of the IP protocols But, the point that Fernando raises is that ICMP is a core signaling protocol for IP and is required for the proper operation of all IP transport protocols, not just TCP or UDP. For this reason, it seems, it would not be acceptable to build a NAT that does not support ICMP, whereas it might be OK to build a NAT that does not support a certain transport protocol. My 2c. regards, suresh > Does anyone believe that the WG has already made a decision on this > point? > > - Philip > > > _______________________________________________ > 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 Sun Apr 01 18:14: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 1HY8Ju-0007lX-84; Sun, 01 Apr 2007 18:14:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY8Jt-0007lS-I6 for behave@ietf.org; Sun, 01 Apr 2007 18:14:41 -0400 Received: from sd-green-bigip-83.dreamhost.com ([208.97.132.83] helo=randymail-a9.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY8Jq-0005nW-7e for behave@ietf.org; Sun, 01 Apr 2007 18:14:41 -0400 Received: from delta.rtfm.com (unknown [74.95.2.174]) by randymail-a9.g.dreamhost.com (Postfix) with ESMTP id 57032EF006; Sun, 1 Apr 2007 15:14:37 -0700 (PDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id 49ACA1CC24; Sun, 1 Apr 2007 15:13:08 -0700 (PDT) To: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt References: <980067.9532.qm@web33312.mail.mud.yahoo.com> From: EKR Date: Sun, 01 Apr 2007 15:13:07 -0700 In-Reply-To: <980067.9532.qm@web33312.mail.mud.yahoo.com> (Pyda Srisuresh's message of "Sun, 1 Apr 2007 15:10:18 -0700 (PDT)") Message-ID: <867isv7ngs.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Behave WG , Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Pyda Srisuresh writes: > Sorry to be late on this thread. I have been swarmed with my day job work past > few days. My comments inline below. > > regards, > suresh > > --- Philip Matthews wrote: > >> >> On 21-Mar-07, at 19:38 , David Barrett wrote: >> >> > >> > Nobody's arguing for the destruction of ICMP. It's a question of >> > whether >> > BEHAVE mandates that NATs support a minimal subset of protocols >> > (ICMP, TCP, >> > UDP) or not. >> > >> > Both positions are reasonable: >> > - BEHAVE defines the behavior for several optional protocols >> > - BEHAVE defines the behavior for several mandatory protocols >> > >> > I think I fall in the first camp: if a NAT is going to support ICMP >> > (or UDP, >> > or TCP) at all, it should support it as BEHAVE dictates. If the >> > NAT for >> > some reason doesn't support ICMP (or UDP, or TCP), then it need >> > only comply >> > with BEHAVE for those protocols it chooses to support. >> > >> > Given that there are more protocols than just ICMP, TCP, and UDP, >> > this seems >> > the only sustainable path. >> > >> >> I think David raises a very good point that we need to clear up. >> Personally, I also fall in the first camp. >> > [suresh] Right, David puts it well and raises a good point. I agree, the BEHAVE > WG is defining requirements for various of the IP protocols > > But, the point that Fernando raises is that ICMP is a core signaling protocol > for IP and is required for the proper operation of all IP transport protocols, > not just TCP or UDP. Since lots of Internet firewalls block all ICMP, I think this assertion is arguable at best. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 01 18:28:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY8Wj-0002tg-SP; Sun, 01 Apr 2007 18:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY8Wi-0002tY-5Z for behave@ietf.org; Sun, 01 Apr 2007 18:27:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY8Wg-0002m7-Rh for behave@ietf.org; Sun, 01 Apr 2007 18:27:56 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2007 15:27:54 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l31MRsY4008384; Sun, 1 Apr 2007 15:27:54 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l31MRpA9018259; Sun, 1 Apr 2007 22:27:51 GMT In-Reply-To: <37F0BD4A-FE39-49E2-926A-42A973B4BE45@nokia.com> References: <200703201902.l2KJ29Li011671@venus.xmundo.net> <77310124-63FA-4EA8-8413-F53B7B99A5EF@cisco.com> <200703260431.l2Q4V74Y008254@venus.xmundo.net> <1174894516.5591.29.camel@sioux.systems.cs.cornell.edu> <37F0BD4A-FE39-49E2-926A-42A973B4BE45@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1979944F-E18B-4A7E-8E72-266E8833052F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Sun, 1 Apr 2007 15:27:45 -0700 To: Lars Eggert X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1650; t=1175466474; x=1176330474; c=relaxed/simple; s=sjdkim7002; 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]=20draft-ietf-behave-nat-icmp-03.txt |Sender:=20; bh=VySrpaO7VKeICni1ckmYqv0hn7tRO5aMwRryzvUsGGM=; b=F4LP0EuNhDNVuMVv0fvBhkcMn04Qz2t4WxXEATxwirZLeiXP2PWkiIW9RA3WLOrEfoxEleHc fc02cNNm8n5oq/8yufVGpfY2OoOpwLR0IMz9u4L4+pasAoavgKIRIsvm; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Mar 26, 2007, at 1:13 AM, Lars Eggert wrote: > On 2007-3-26, at 9:35, ext Saikat Guha wrote: >> Allowing or disallowing ICMP on a local network is a policy issue for >> the site. This site policy is out-of-scope of BEHAVE. What IS in >> scope, >> as Cullen said, is specifying how those packets are to be >> translated if >> site policy permits. > > If ICMPs were completely advisory, I'd agree, but they aren't > (yet). Some ICMP messages are needed for the correct operation of > transport protocols (must fragment), others are increasing > efficiency (unreachables, etc.) > > . Completely agree with Lars here - that is why the parts of ICMP that are need to make UDP work are put into the behave document for UDP, and likewise for other transport protocols. They clearly need to be there otherwise we run the risk of the behave documentation around ICMP actually breaking transport protocols which would be clearly not the right path. This ICMP document is to deal with the ICMP applications that are not associated with a transport protocol. I seem to recall that the only two applications that the WG identified were ping and traceroute but perhaps there were more. The general reports from testing NATs seem to be that for clients inside the NAT running an ICMP application to something outside the NAT, the ping and treaceroute applicants seems to work fine. You will note after an long an irritating discussion on this list I actually went and tested ping and traceroute on about 50 nats and published the result in a draft. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 01 18:30: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 1HY8ZA-0004Sf-NX; Sun, 01 Apr 2007 18:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY8Z9-0004Lw-0J for behave@ietf.org; Sun, 01 Apr 2007 18:30:27 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY8Z4-0004GM-6G for behave@ietf.org; Sun, 01 Apr 2007 18:30:26 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2007 15:30:21 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l31MULY0019913; Sun, 1 Apr 2007 15:30:21 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l31MUKwo022725; Sun, 1 Apr 2007 22:30:20 GMT In-Reply-To: <1174869626.21195.43.camel@sioux.systems.cs.cornell.edu> References: <1174513829.4192.60.camel@sioux.systems.cs.cornell.edu> <1174869626.21195.43.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <12C8513D-0A44-472B-8B65-F95B4D1955A2@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] RE: SecDir review of draft-ietf-behave-tcp-05 Date: Sun, 1 Apr 2007 15:30:14 -0700 To: Saikat Guha X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=937; t=1175466621; x=1176330621; c=relaxed/simple; s=sjdkim6002; 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=20SecDir=20review=20of=20draft-ietf- behave-tcp-05 |Sender:=20; bh=9N19/aqC/VbjCvislsnly4/HAeFbwfVHLD8f4R9MMao=; b=mnAiUL2YMnEwYUARUPFhq2W4BXeTMoefoU7p64LvuJdKmdBfWdh+EkCybvr5KihXhgE1pQBz dwD/t0TmNYGJ1A4J/VtzNAbWH2vtEh0afh/NMv8x1U6EBJ39p3+rJYur; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: behave@ietf.org, Pasi.Eronen@nokia.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 Sounds reasonable to me On Mar 25, 2007, at 5:40 PM, Saikat Guha wrote: > On Thu, 2007-03-22 at 10:21 +0200, Pasi.Eronen@nokia.com wrote: >> No, but for translation of TCP to work, NATs are required to handle >> sequence numbers in correct fashion (just like NATs are required to >> handle TCP state machine correctly, REQ-2). > > Fair enough. ALGs aside, not supporting SACK when the NAT is munging > seq# for privacy reasons can be viewed as an information leak. > > Perhaps adding the following sentence to the security section would > help: > > "NAT implementations that modify TCP sequence numbers for privacy > reasons or ALG support must ensure that TCP packets with SACK > notifications are properly handled." > > Thoughts? > > cheers, > -- > Saikat > _______________________________________________ > 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 Sun Apr 01 18:42: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 1HY8l3-0003o5-6b; Sun, 01 Apr 2007 18:42:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY8l1-0003nz-FR for behave@ietf.org; Sun, 01 Apr 2007 18:42:43 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HY8kz-0000KI-VC for behave@ietf.org; Sun, 01 Apr 2007 18:42:43 -0400 Received: from Quinthar ([67.44.173.251]) by quinthar.com for ; Sun, 1 Apr 2007 15:42:26 -0700 From: "David Barrett" To: "'Cullen Jennings'" , "'Lars Eggert'" Subject: RE: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Sun, 1 Apr 2007 17:42:03 -0500 Message-ID: <068701c774af$04959840$6701a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd0rSREX98DfbWWT3q5su/4/T7oxgAAI/fA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1979944F-E18B-4A7E-8E72-266E8833052F@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 2007-3-26, at 9:35, ext Saikat Guha wrote: > >> Allowing or disallowing ICMP on a local network is a policy issue for > >> the site. This site policy is out-of-scope of BEHAVE. What IS in > >> scope, > >> as Cullen said, is specifying how those packets are to be > >> translated if > >> site policy permits. > > > > If ICMPs were completely advisory, I'd agree, but they aren't > > (yet). Some ICMP messages are needed for the correct operation of > > transport protocols (must fragment), others are increasing > > efficiency (unreachables, etc.) > > Completely agree with Lars here - that is why the parts of ICMP that > are need to make UDP work are put into the behave document for UDP, > and likewise for other transport protocols. They clearly need to be > there otherwise we run the risk of the behave documentation around > ICMP actually breaking transport protocols which would be clearly not > the right path. I'm not sure I agree they "clearly" need to be there, or that transport protocols "break" with the absence of ICMP: In my experience UDP works just fine in environments without ICMP -- indeed, you'd be crazy to depend upon it. Every UDP protocol that I've used (including those that I develop) treats ICMP as a nice, but rarely available and totally unreliable perk. Even TCP, so far as I understand it, has well-paved fallbacks for if ICMP is unavailable (indeed, isn't ICMP availability technically a "special case" in the TCP stack?). Sure it might mean longer timeouts, greater packet loss, and smaller MTUs, but that's hardly the same as "correct operation". TCP works "correctly" without ICMP, just differently. So while I totally agree we should encourage ICMP and define the "right" way to support it, I'm not sure it should be made mandatory for BEHAVE compliance. Again, I love ICMP, and I want it. But not everybody loves and wants it as much as me. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 01 19:59: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 1HY9xE-00040U-Ls; Sun, 01 Apr 2007 19:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY9tj-0002X3-LF for behave@ietf.org; Sun, 01 Apr 2007 19:55:47 -0400 Received: from web33305.mail.mud.yahoo.com ([68.142.206.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HY9s7-0007AV-Cw for behave@ietf.org; Sun, 01 Apr 2007 19:54:10 -0400 Received: (qmail 71084 invoked by uid 60001); 1 Apr 2007 23:54:03 -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=ocnER4NaiLDEhfp2lJAn2UtjCscCq0f+EuKzpjo/3lvMSPa50MWGnL+oBF3pUrFufosAo9URphug9RRrEMpOSouOrVgt5KW5qWLb7z8hMEmc2qsJVvAyvDIq0h5kZLeiC7crcDxBuqcKwDvJJdVinzujcizxe/2m/QyzAJTA7qg=; X-YMail-OSG: 8GuZ3z4VM1k6s.APMOXd8CBi2HrY.TEft355WnAHAX2WEbSh3pjcKe6wHUhD_eKjg99oRrDwR6azInK48gR7rm6SNJG0ORkiGMjtkGHXjvYP3Z3o4rs- Received: from [209.172.74.45] by web33305.mail.mud.yahoo.com via HTTP; Sun, 01 Apr 2007 16:54:03 PDT Date: Sun, 1 Apr 2007 16:54:03 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: Cullen Jennings , Lars Eggert In-Reply-To: <1979944F-E18B-4A7E-8E72-266E8833052F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <620620.70588.qm@web33305.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 --- Cullen Jennings wrote: > > On Mar 26, 2007, at 1:13 AM, Lars Eggert wrote: > > > On 2007-3-26, at 9:35, ext Saikat Guha wrote: > >> Allowing or disallowing ICMP on a local network is a policy issue for > >> the site. This site policy is out-of-scope of BEHAVE. What IS in > >> scope, > >> as Cullen said, is specifying how those packets are to be > >> translated if > >> site policy permits. > > > > If ICMPs were completely advisory, I'd agree, but they aren't > > (yet). Some ICMP messages are needed for the correct operation of > > transport protocols (must fragment), others are increasing > > efficiency (unreachables, etc.) > > > > . > > Completely agree with Lars here - that is why the parts of ICMP that > are need to make UDP work are put into the behave document for UDP, > and likewise for other transport protocols. [suresh] Cullen - With the excpetion of UDP document, it has been the consensus of the WG to include ICMP requirements in the ICMP document. For example, In the San Diego meeting, the consensus was to have the ICMP doc specify the translation of ICMP messages, and leave the reaction up to each protocol-specific document. ICMP document is transport protocol agnostic. > They clearly need to be > there otherwise we run the risk of the behave documentation around > ICMP actually breaking transport protocols which would be clearly not > the right path. > [suresh] Right. > This ICMP document is to deal with the ICMP applications that are not > associated with a transport protocol. [suresh] Cullen - We had gone over the scope of ICMP doc before and settled on this. Why are you bringing this up again? If you restricted the scope of ICMP behave docuemnt to applications of ICMP Query messages, the draft adds little value. REQs 3, 4, 5, 7, 8 and 9 are requirements relating to ICMP error messages, - That is 67% of the total requirements in the document. These requirements are not covered in other BEHAVE documents. regards, suresh > I seem to recall that the only > two applications that the WG identified were ping and traceroute but > perhaps there were more. The general reports from testing NATs seem > to be that for clients inside the NAT running an ICMP application to > something outside the NAT, the ping and treaceroute applicants seems > to work fine. You will note after an long an irritating discussion on > this list I actually went and tested ping and traceroute on about 50 > nats and published the result in a draft. > > Cullen > > _______________________________________________ > 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 Sun Apr 01 20:48:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYAhy-0008At-Av; Sun, 01 Apr 2007 20:47:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYAhx-00087q-0r for behave@ietf.org; Sun, 01 Apr 2007 20:47:41 -0400 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYAhu-0007NI-KA for behave@ietf.org; Sun, 01 Apr 2007 20:47:41 -0400 Received: (qmail 90223 invoked by uid 60001); 2 Apr 2007 00:47:36 -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=BsYORomq1Z/rJz+28EBEUCVYTWhEjxDfUDxC6Gtv1tzAxHwqwAw0SRQhhfBJlSzPL5TqNAvPLcvx/mE+HQ43rW+USC3ALE5Ke2VetbzqfcuNPLvkFKJQLv5mftXazykSkD9hcpkARvnGJeJOJ2rNDwL7+BW0FHJWK3L098CXnsE=; X-YMail-OSG: Nw7Ly8UVM1niWKVYVhxVxnWrkdRen3YiaBV5OeWn5m_v1Kx1O6VtzvkfY17AgLoLotodTo6poXZjJF2uoL75ghaPPev3xA4GFpfL2OrN7CJpBh4- Received: from [209.172.74.45] by web33306.mail.mud.yahoo.com via HTTP; Sun, 01 Apr 2007 17:47:36 PDT Date: Sun, 1 Apr 2007 17:47:36 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: David Barrett , 'Cullen Jennings' , 'Lars Eggert' In-Reply-To: <068701c774af$04959840$6701a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <81813.90199.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 --- David Barrett wrote: > > > On 2007-3-26, at 9:35, ext Saikat Guha wrote: > > >> Allowing or disallowing ICMP on a local network is a policy issue for > > >> the site. This site policy is out-of-scope of BEHAVE. What IS in > > >> scope, > > >> as Cullen said, is specifying how those packets are to be > > >> translated if > > >> site policy permits. > > > > > > If ICMPs were completely advisory, I'd agree, but they aren't > > > (yet). Some ICMP messages are needed for the correct operation of > > > transport protocols (must fragment), others are increasing > > > efficiency (unreachables, etc.) > > > > Completely agree with Lars here - that is why the parts of ICMP that > > are need to make UDP work are put into the behave document for UDP, > > and likewise for other transport protocols. They clearly need to be > > there otherwise we run the risk of the behave documentation around > > ICMP actually breaking transport protocols which would be clearly not > > the right path. > > I'm not sure I agree they "clearly" need to be there, or that transport > protocols "break" with the absence of ICMP: > > In my experience UDP works just fine in environments without ICMP -- indeed, > you'd be crazy to depend upon it. Every UDP protocol that I've used > (including those that I develop) treats ICMP as a nice, but rarely available > and totally unreliable perk. > > Even TCP, so far as I understand it, has well-paved fallbacks for if ICMP is > unavailable (indeed, isn't ICMP availability technically a "special case" in > the TCP stack?). Sure it might mean longer timeouts, greater packet loss, > and smaller MTUs, but that's hardly the same as "correct operation". TCP > works "correctly" without ICMP, just differently. > > So while I totally agree we should encourage ICMP and define the "right" way > to support it, I'm not sure it should be made mandatory for BEHAVE > compliance. > > Again, I love ICMP, and I want it. But not everybody loves and wants it as > much as me. > [suresh] David - RFC 1812 mandates that routers generate, interpret and forward ICMP error messages. ICMP signaling is required on all IP routers. The soft requirement you are refering to (TCP works without ICMP, but just differently) comes from the fact that ICMP messages are sent as IP datagrams and IP datagrams are not guaranteed. That is not to say that ICMP support on the routers is optional. As Lars said, without ICMP, the operation of transport protocols will be impeded in correctness and efficiency. regards, suresh > -david > > > _______________________________________________ > 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 Sun Apr 01 20:55:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYApT-0008J2-Cn; Sun, 01 Apr 2007 20:55:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYApS-0008Ix-7H for behave@ietf.org; Sun, 01 Apr 2007 20:55:26 -0400 Received: from web33310.mail.mud.yahoo.com ([68.142.206.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYApQ-00082Q-U1 for behave@ietf.org; Sun, 01 Apr 2007 20:55:26 -0400 Received: (qmail 88000 invoked by uid 60001); 2 Apr 2007 00:55:24 -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=bXwTE2JxDcJPglV96HkNj4ErzOc7dj1DUb7MUBQl5hl/bfD0gwLPACSSOjrxpiv9fQQJFrjWzW/8PJmrI3tkwPuBjHgY50Vi1+Khh7V1+FeM39/hWayec8+v8hJmb67nOwHgi/sgARZmp/kRbGQdX9+7nIIjGnVwLgIqhpSEc0k=; X-YMail-OSG: v29XkroVM1l_2WUUvftnrtOItbmZKr8plkGIPkr1PWn4f55zchr.Hm1t_FLmvuiMuCSpZw-- Received: from [209.172.74.45] by web33310.mail.mud.yahoo.com via HTTP; Sun, 01 Apr 2007 17:55:24 PDT Date: Sun, 1 Apr 2007 17:55:24 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: EKR In-Reply-To: <867isv7ngs.fsf@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <353877.87097.qm@web33310.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Behave WG , Philip Matthews 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 --- EKR wrote: > Pyda Srisuresh writes: > > > Sorry to be late on this thread. I have been swarmed with my day job work > past > > few days. My comments inline below. > > > > regards, > > suresh > > > > --- Philip Matthews wrote: > > > >> > >> On 21-Mar-07, at 19:38 , David Barrett wrote: > >> > >> > > >> > Nobody's arguing for the destruction of ICMP. It's a question of > >> > whether > >> > BEHAVE mandates that NATs support a minimal subset of protocols > >> > (ICMP, TCP, > >> > UDP) or not. > >> > > >> > Both positions are reasonable: > >> > - BEHAVE defines the behavior for several optional protocols > >> > - BEHAVE defines the behavior for several mandatory protocols > >> > > >> > I think I fall in the first camp: if a NAT is going to support ICMP > >> > (or UDP, > >> > or TCP) at all, it should support it as BEHAVE dictates. If the > >> > NAT for > >> > some reason doesn't support ICMP (or UDP, or TCP), then it need > >> > only comply > >> > with BEHAVE for those protocols it chooses to support. > >> > > >> > Given that there are more protocols than just ICMP, TCP, and UDP, > >> > this seems > >> > the only sustainable path. > >> > > >> > >> I think David raises a very good point that we need to clear up. > >> Personally, I also fall in the first camp. > >> > > [suresh] Right, David puts it well and raises a good point. I agree, the > BEHAVE > > WG is defining requirements for various of the IP protocols > > > > But, the point that Fernando raises is that ICMP is a core signaling > protocol > > for IP and is required for the proper operation of all IP transport > protocols, > > not just TCP or UDP. > > Since lots of Internet firewalls block all ICMP, I think this assertion > is arguable at best. [suresh] Are you saying that some firewalls are configured to block all ICMP - ICMP queries and ICMP errors, inbound and outbound? That seems flawed. Is there an IETF document that recommends this setting to administrators? I can understand if some firewalls block inbound ICMP queries. But, why are the ICMP errors blocked? We cannot make recommendations based on what some firewall admins do. There are many admins that block UDP traffci entirely. That does not mean we recommend NATs to not support UDP packets. regards, suresh > > -Ekr > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 01 21:27: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 1HYBKA-00041Z-A9; Sun, 01 Apr 2007 21:27:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYBK9-00041U-Dx for behave@ietf.org; Sun, 01 Apr 2007 21:27:09 -0400 Received: from sd-green-bigip-74.dreamhost.com ([208.97.132.74] helo=randymail-a8.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYBK6-0004HZ-0A for behave@ietf.org; Sun, 01 Apr 2007 21:27:09 -0400 Received: from delta.rtfm.com (unknown [74.95.2.174]) by randymail-a8.g.dreamhost.com (Postfix) with ESMTP id 5CDE2AF583; Sun, 1 Apr 2007 18:26:59 -0700 (PDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id 1D83D1CC24; Sun, 1 Apr 2007 18:25:30 -0700 (PDT) To: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt References: <353877.87097.qm@web33310.mail.mud.yahoo.com> From: EKR Date: Sun, 01 Apr 2007 18:25:29 -0700 In-Reply-To: <353877.87097.qm@web33310.mail.mud.yahoo.com> (Pyda Srisuresh's message of "Sun, 1 Apr 2007 17:55:24 -0700 (PDT)") Message-ID: <86ejn35zzq.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Behave WG , Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Pyda Srisuresh writes: > --- EKR wrote: > >> Pyda Srisuresh writes: >> >> > Sorry to be late on this thread. I have been swarmed with my day job work >> past >> > few days. My comments inline below. >> > >> > regards, >> > suresh >> > >> > --- Philip Matthews wrote: >> > >> >> >> >> On 21-Mar-07, at 19:38 , David Barrett wrote: >> >> >> >> > >> >> > Nobody's arguing for the destruction of ICMP. It's a question of >> >> > whether >> >> > BEHAVE mandates that NATs support a minimal subset of protocols >> >> > (ICMP, TCP, >> >> > UDP) or not. >> >> > >> >> > Both positions are reasonable: >> >> > - BEHAVE defines the behavior for several optional protocols >> >> > - BEHAVE defines the behavior for several mandatory protocols >> >> > >> >> > I think I fall in the first camp: if a NAT is going to support ICMP >> >> > (or UDP, >> >> > or TCP) at all, it should support it as BEHAVE dictates. If the >> >> > NAT for >> >> > some reason doesn't support ICMP (or UDP, or TCP), then it need >> >> > only comply >> >> > with BEHAVE for those protocols it chooses to support. >> >> > >> >> > Given that there are more protocols than just ICMP, TCP, and UDP, >> >> > this seems >> >> > the only sustainable path. >> >> > >> >> >> >> I think David raises a very good point that we need to clear up. >> >> Personally, I also fall in the first camp. >> >> >> > [suresh] Right, David puts it well and raises a good point. I agree, the >> BEHAVE >> > WG is defining requirements for various of the IP protocols >> > >> > But, the point that Fernando raises is that ICMP is a core signaling >> protocol >> > for IP and is required for the proper operation of all IP transport >> protocols, >> > not just TCP or UDP. >> >> Since lots of Internet firewalls block all ICMP, I think this assertion >> is arguable at best. > > [suresh] Are you saying that some firewalls are configured to block > all ICMP - ICMP queries and ICMP errors, inbound and outbound? That > seems flawed. It's quite common, actually. > Is there an IETF document that recommends this setting to > administrators? I can understand if some firewalls block inbound > ICMP queries. But, why are the ICMP errors blocked? Because correlating them to the flows they refer to is a pain and it's easier to block them directly. > We cannot make recommendations based on what some firewall admins do. We certainly can avoid making recommendations that would have the effect of declaring a large number of firewalls nomcompliant. > There are > many admins that block UDP traffci entirely. That does not mean we recommend > NATs to not support UDP packets. Recommending that someone block X is not the same as not requiring that someone not block X. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 02 02:23:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFwQ-00046W-16; Mon, 02 Apr 2007 02:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFwO-00042t-A8 for behave@ietf.org; Mon, 02 Apr 2007 02:22:56 -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 1HYFwM-0000Oc-Rr for behave@ietf.org; Mon, 02 Apr 2007 02:22:56 -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 l326MqwS028544; Mon, 2 Apr 2007 09:22:53 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:52 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:52 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:52 +0300 Received: from esdhcp04149.research.nokia.com (esdhcp04149.research.nokia.com [172.21.41.49]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l326MoJK017075; Mon, 2 Apr 2007 09:22:50 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: EKR , Behave WG Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 09:23:01 +0300 User-Agent: KMail/1.9.6 References: <353877.87097.qm@web33310.mail.mud.yahoo.com> <86ejn35zzq.fsf@delta.rtfm.com> In-Reply-To: <86ejn35zzq.fsf@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704020923.01985.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Apr 2007 06:22:52.0047 (UTC) FILETIME=[57AF71F0:01C774EF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070402092253-6DC22BB0-63A16B69/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Monday 02 April 2007 04:25:29 ext EKR wrote: > > [suresh] Are you saying that some firewalls are configured to block > > all ICMP - ICMP queries and ICMP errors, inbound and outbound? That > > seems flawed. > > It's quite common, actually. It's quite common. Sure. But first, in most case, it blocks pretty much=20 everything else too for security reasons (your typical corporate Intranet=20 with proxies of all types and only outbound NTP and/or DNS or so allowed). And if not, it's completely flawed, whether it exists or not. Saying that t= his=20 is bad by forbidding this in BEHAVE specs actually looks good to me. It's n= ot=20 like the BEHAVE working group will change or remove these firewalls magical= ly=20 by telling they are non compliant. As far as I am concerned, you can still= =20 continue sell thse boxes - so what are you complaining about? > > Is there an IETF document that recommends this setting to > > administrators? I can understand if some firewalls block inbound > > ICMP queries. But, why are the ICMP errors blocked? > > Because correlating them to the flows they refer to is a pain > and it's easieFrom behave-bounces@ietf.org Mon Apr 02 02:23:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFwQ-00046W-16; Mon, 02 Apr 2007 02:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFwO-00042t-A8 for behave@ietf.org; Mon, 02 Apr 2007 02:22:56 -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 1HYFwM-0000Oc-Rr for behave@ietf.org; Mon, 02 Apr 2007 02:22:56 -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 l326MqwS028544; Mon, 2 Apr 2007 09:22:53 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:52 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:52 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:52 +0300 Received: from esdhcp04149.research.nokia.com (esdhcp04149.research.nokia.com [172.21.41.49]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l326MoJK017075; Mon, 2 Apr 2007 09:22:50 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: EKR , Behave WG Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 09:23:01 +0300 User-Agent: KMail/1.9.6 References: <353877.87097.qm@web33310.mail.mud.yahoo.com> <86ejn35zzq.fsf@delta.rtfm.com> In-Reply-To: <86ejn35zzq.fsf@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704020923.01985.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Apr 2007 06:22:52.0047 (UTC) FILETIME=[57AF71F0:01C774EF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070402092253-6DC22BB0-63A16B69/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Monday 02 April 2007 04:25:29 ext EKR wrote: > > [suresh] Are you saying that some firewalls are configured to block > > all ICMP - ICMP queries and ICMP errors, inbound and outbound? That > > seems flawed. > > It's quite common, actually. It's quite common. Sure. But first, in most case, it blocks pretty much=20 everything else too for security reasons (your typical corporate Intranet=20 with proxies of all types and only outbound NTP and/or DNS or so allowed). And if not, it's completely flawed, whether it exists or not. Saying that t= his=20 is bad by forbidding this in BEHAVE specs actually looks good to me. It's n= ot=20 like the BEHAVE working group will change or remove these firewalls magical= ly=20 by telling they are non compliant. As far as I am concerned, you can still= =20 continue sell thse boxes - so what are you complaining about? > > Is there an IETF document that recommends this setting to > > administrators? I can understand if some firewalls block inbound > > ICMP queries. But, why are the ICMP errors blocked? > > Because correlating them to the flows they refer to is a pain > and it's easier to block them directly. That's laughable. The original pristine packet headers are inside ICMP erro= rs=20 messsages. It's actually easier to match an ICMP error to a flow than a rea= l=20 reply packet of some transport protocol. > > We cannot make recommendations based on what some firewall admins do. > We certainly can avoid making recommendations that would have the > effect of declaring a large number of firewalls nomcompliant. We can. We can also not specify anything. Or we can tell the truthm which i= s=20 that this behavior is bad for interactive network usage and application=20 developers. In any case (independant of ICMP BEHAVE), I am very confident that=20 some "security" researchers will soon claim that NATs and firewalls MUST NO= T=20 be BEHAVE-compliant because it allows various kind of traversal scenario to= =20 work. Just look at some NAT implementors happily boasting about their NAT=20 being symmetric to "increase security" (read: prevent everything but HTTP=20 from going through). > > There are > > many admins that block UDP traffci entirely. That does not mean we > > recommend NATs to not support UDP packets. > > Recommending that someone block X is not the same as not requiring > that someone not block X. Recommending that someone does not block X is not the same as passing a law= =20 that someone must not block X. =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 Apr 02 02:23:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFwN-00042o-RR; Mon, 02 Apr 2007 02:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFwM-00042g-Od for behave@ietf.org; Mon, 02 Apr 2007 02:22:54 -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 1HYFwL-0000OW-AZ for behave@ietf.org; Mon, 02 Apr 2007 02:22:54 -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 l326McOJ032640; Mon, 2 Apr 2007 09:22:51 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:49 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:49 +0300 Received: from esdhcp04149.research.nokia.com (esdhcp04149.research.nokia.com [172.21.41.49]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l326MlYr006999; Mon, 2 Apr 2007 09:22:47 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: EKR , Behave WG Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 09:22:58 +0300 User-Agent: KMail/1.9.6 References: <980067.9532.qm@web33312.mail.mud.yahoo.com> <867isv7ngs.fsf@delta.rtfm.com> In-Reply-To: <867isv7ngs.fsf@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704020922.58873.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Apr 2007 06:22:49.0056 (UTC) FILETIME=[55E70E00:01C774EF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070402092251-7E49FBB0-1666BD4D/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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-Por to block them directly. That's laughable. The original pristine packet headers are inside ICMP erro= rs=20 messsages. It's actually easier to match an ICMP error to a flow than a rea= l=20 reply packet of some transport protocol. > > We cannot make recommendations based on what some firewall admins do. > We certainly can avoid making recommendations that would have the > effect of declaring a large number of firewalls nomcompliant. We can. We can also not specify anything. Or we can tell the truthm which i= s=20 that this behavior is bad for interactive network usage and application=20 developers. In any case (independant of ICMP BEHAVE), I am very confident that=20 some "security" researchers will soon claim that NATs and firewalls MUST NO= T=20 be BEHAVE-compliant because it allows various kind of traversal scenario to= =20 work. Just look at some NAT implementors happily boasting about their NAT=20 being symmetric to "increase security" (read: prevent everything but HTTP=20 from going through). > > There are > > many admins that block UDP traffci entirely. That does not mean we > > recommend NATs to not support UDP packets. > > Recommending that someone block X is not the same as not requiring > that someone not block X. Recommending that someone does not block X is not the same as passing a law= =20 that someone must not block X. =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 Apr 02 02:23:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFwN-00042o-RR; Mon, 02 Apr 2007 02:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFwM-00042g-Od for behave@ietf.org; Mon, 02 Apr 2007 02:22:54 -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 1HYFwL-0000OW-AZ for behave@ietf.org; Mon, 02 Apr 2007 02:22:54 -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 l326McOJ032640; Mon, 2 Apr 2007 09:22:51 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:49 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:22:49 +0300 Received: from esdhcp04149.research.nokia.com (esdhcp04149.research.nokia.com [172.21.41.49]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l326MlYr006999; Mon, 2 Apr 2007 09:22:47 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: EKR , Behave WG Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 09:22:58 +0300 User-Agent: KMail/1.9.6 References: <980067.9532.qm@web33312.mail.mud.yahoo.com> <867isv7ngs.fsf@delta.rtfm.com> In-Reply-To: <867isv7ngs.fsf@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704020922.58873.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Apr 2007 06:22:49.0056 (UTC) FILETIME=[55E70E00:01C774EF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070402092251-7E49FBB0-1666BD4D/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Monday 02 April 2007 01:13:07 ext EKR wrote: > > But, the point that Fernando raises is that ICMP is a core signaling > > protocol for IP and is required for the proper operation of all IP > > transport protocols, not just TCP or UDP. > > Since lots of Internet firewalls block all ICMP, I think this assertion > is arguable at best. But then again, if you are serious about isolating your Intranet, you shoul= d=20 use a firewall, but you should NOT user/rely on a NAT. Besides, a firewall can do pretty much anything, so it looks ridicule to me= =20 that we would try to make the spec firewall-compliant (normally, it works t= he=20 other way around). The only way a spec will be compliant with firewalls is= =20 not to specify anything related to computer networking! NATs are meant to allow connectivity in case there are not enough IP=20 addresses; firewall are security devices. It is a purely incidental practic= al=20 thing that both features are often implemented on the same box. At the very minimum, an BEHAVE-compliant box MUST NOT break Path MTU discov= ery=20 (in particular not require TCP MSS clamping, which can only fix TCP anyway)= ,=20 and it MUST let ICMP errors back to not degrade/break interactive=20 connectivity diagnostics -> user experience. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave st: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Monday 02 April 2007 01:13:07 ext EKR wrote: > > But, the point that Fernando raises is that ICMP is a core signaling > > protocol for IP and is required for the proper operation of all IP > > transport protocols, not just TCP or UDP. > > Since lots of Internet firewalls block all ICMP, I think this assertion > is arguable at best. But then again, if you are serious about isolating your Intranet, you shoul= d=20 use a firewall, but you should NOT user/rely on a NAT. Besides, a firewall can do pretty much anything, so it looks ridicule to me= =20 that we would try to make the spec firewall-compliant (normally, it works t= he=20 other way around). The only way a spec will be compliant with firewalls is= =20 not to specify anything related to computer networking! NATs are meant to allow connectivity in case there are not enough IP=20 addresses; firewall are security devices. It is a purely incidental practic= al=20 thing that both features are often implemented on the same box. At the very minimum, an BEHAVE-compliant box MUST NOT break Path MTU discov= ery=20 (in particular not require TCP MSS clamping, which can only fix TCP anyway)= ,=20 and it MUST let ICMP errors back to not degrade/break interactive=20 connectivity diagnostics -> user experience. =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 Apr 02 02:29:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG25-0000kr-5z; Mon, 02 Apr 2007 02:28:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG24-0000ki-60 for behave@ietf.org; Mon, 02 Apr 2007 02:28:48 -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 1HYG22-0001e7-Oa for behave@ietf.org; Mon, 02 Apr 2007 02:28:48 -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 l326SYa0000735 for ; Mon, 2 Apr 2007 09:28:44 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:28:43 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:28:43 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:28:43 +0300 Received: from esdhcp04149.research.nokia.com (esdhcp04149.research.nokia.com [172.21.41.49]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l326SfJ8011803 for ; Mon, 2 Apr 2007 09:28:42 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 09:28:53 +0300 User-Agent: KMail/1.9.6 References: <068701c774af$04959840$6701a8c0@Quinthar> In-Reply-To: <068701c774af$04959840$6701a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704020928.53486.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Apr 2007 06:28:43.0429 (UTC) FILETIME=[29201550:01C774F0] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070402092844-01930BB0-7F1751F7/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 02 April 2007 01:42:03 ext David Barrett wrote: > I'm not sure I agree they "clearly" need to be there, or that transport > protocols "break" with the absence of ICMP: I do. > In my experience UDP works just fine in environments without ICMP -- > indeed, you'd be crazy to depend upon it. Every UDP protocol that I've > used (including those that I develop) treats ICMP as a nice, but rarely > available and totally unreliable perk. In my experience, nothing works without ICMP Packet too big. I happen to ha= ve=20 lived in a country where there is intense use of PPPoA or PPPoE on the last= =20 mile, so that the MTU is lower between the CPE and ISP (typically 1492 byte= s)=20 than on the LAN (1500) and on the Internet (at least 1500). Saying that packet too big can be dropped is like saying you do not care=20 about "talking" with these users (the last ISP router will send Packet too= =20 big if you try to send them a packet). I'm talking *millions* of them here. > Even TCP, so far as I understand it, has well-paved fallbacks for if ICMP > is unavailable (indeed, isn't ICMP availability technically a "special > case" in the TCP stack?). Sure it might mean longer timeouts, greater > packet loss, and smaller MTUs, but that's hardly the same as "correct > operation". TCP works "correctly" without ICMP, just differently. Not at all. TCP does not work at all without ICMP. Because of this, most NA= T=20 boxes have to do MSS clamping to fix it (in the same scenario as above).=20 Otherwise, you get your three-way handshake fine, and then the connection=20 breaks as soon as you send too large a data packet. =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 Apr 02 02:58: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 1HYGTr-00041P-En; Mon, 02 Apr 2007 02:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYGTp-0003uC-GB for behave@ietf.org; Mon, 02 Apr 2007 02:57:29 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYGTl-0000F8-29 for behave@ietf.org; Mon, 02 Apr 2007 02:57:29 -0400 Received: from Quinthar ([201.140.188.144]) by quinthar.com for ; Sun, 1 Apr 2007 23:57:10 -0700 From: "David Barrett" To: =?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?= , Subject: RE: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 01:57:04 -0500 Message-ID: <008f01c774f4$20b6ed90$6b01a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd08DvxSFc+rflrRxSPSKSopbZ/GgAAO8og X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <200704020928.53486.remi.denis-courmont@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] >=20 > > In my experience UDP works just fine in environments without ICMP -- > > indeed, you'd be crazy to depend upon it. Every UDP protocol that = I've > > used (including those that I develop) treats ICMP as a nice, but = rarely > > available and totally unreliable perk. >=20 > In my experience, nothing works without ICMP Packet too big.=20 "Nothing" is a very strong word that you might take more care with. To = list a few, RTP, RTCP, my personal UDP protocols (iGlance -- streaming voice/video/file/screen-sharing, Red Swoosh -- swarming downloads) = don=92t require ICMP. UPnP works without ICMP. DNS does too, so far as I know. Yes, all of these work better *with* it. But to say that nothing works without ICMP seems patently false. > I happen to > have > lived in a country where there is intense use of PPPoA or PPPoE on the > last > mile, so that the MTU is lower between the CPE and ISP (typically 1492 > bytes) > than on the LAN (1500) and on the Internet (at least 1500). All the UDP developers I know use packet sizes smaller than 1492 for precisely this reason. I generally target the 1KB range. UDP = fragmentation from too-large packets leads to high packet loss (and this is true with = or without ICMP), which is why everybody strives to avoid it.=20 Again, I love ICMP. It makes everything work better. But let's not = pretend nothing can function without it. > Saying that packet too big can be dropped is like saying you do not = care > about "talking" with these users (the last ISP router will send Packet = too > big if you try to send them a packet). I'm talking *millions* of them > here. The "secret" is to just send small packets. People who do real-world = UDP protocol design and programming know this, and have already been doing = this for years. ICMP is nice. It's not required. > > Even TCP, so far as I understand it, has well-paved fallbacks for if > ICMP > > is unavailable (indeed, isn't ICMP availability technically a = "special > > case" in the TCP stack?). Sure it might mean longer timeouts, = greater > > packet loss, and smaller MTUs, but that's hardly the same as = "correct > > operation". TCP works "correctly" without ICMP, just differently. >=20 > Not at all. TCP does not work at all without ICMP. Because of this, = most > NAT > boxes have to do MSS clamping to fix it (in the same scenario as = above). > Otherwise, you get your three-way handshake fine, and then the = connection > breaks as soon as you send too large a data packet. Again, that's a very absolute statement that I'm pretty sure is wrong. = TCP *can* function without ICMP. It might require some extra work, extra delays, and extra headaches. But it can and does work every day. I agree BEHAVE should specify how ICMP should be supported, if it's to = be supported. But I disagree it should mandate ICMP be supported, anymore = than it should mandate UPnP be supported merely because "it makes things work better". -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 02 03:34: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 1HYH3E-0003jF-Vf; Mon, 02 Apr 2007 03:34:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYH3D-0003fj-2G for behave@ietf.org; Mon, 02 Apr 2007 03:34:03 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYH3B-0000ZQ-AI for behave@ietf.org; Mon, 02 Apr 2007 03:34:03 -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 l327Xglv004112; Mon, 2 Apr 2007 10:33:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:33:36 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:33:35 +0300 Received: from esdhcp041130.research.nokia.com (esdhcp041130.research.nokia.com [172.21.41.130]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l327XY7U008069; Mon, 2 Apr 2007 10:33:34 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext David Barrett" , behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 10:33:45 +0300 User-Agent: KMail/1.9.6 References: <008f01c774f4$20b6ed90$6b01a8c0@Quinthar> In-Reply-To: <008f01c774f4$20b6ed90$6b01a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704021033.45585.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Apr 2007 07:33:35.0775 (UTC) FILETIME=[3924F2F0:01C774F9] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070402103359-08A99BB0-20B7874C/0-0/0-1 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 Monday 02 April 2007 09:57:04 you wrote: > > Not at all. TCP does not work at all without ICMP. Because of this, most > > NAT > > boxes have to do MSS clamping to fix it (in the same scenario as above). > > Otherwise, you get your three-way handshake fine, and then the connecti= on > > breaks as soon as you send too large a data packet. > > Again, that's a very absolute statement that I'm pretty sure is wrong. T= CP > *can* function without ICMP. It might require some extra work, extra > delays, and extra headaches. But it can and does work every day. Sure, if you the smallest MTU in the path in on the first hop, it works jus= t=20 fine. Otherwise, it times out lamely as soon as the outpout buffer gets=20 bigger than the path MTU, and the TCP stacks keeps retrying to transmit a=20 packet that gets silently dropped (using widespread TCP stacks such as=20 Windows XP and Linux). > I agree BEHAVE should specify how ICMP should be supported, if it's to be > supported. But I disagree it should mandate ICMP be supported, anymore > than it should mandate UPnP be supported merely because "it makes things > work better". It makes some things work at all, which is very different. =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 Apr 02 08:50: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 1HYLyU-0004P5-6u; Mon, 02 Apr 2007 08:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLyS-0004Ia-R2 for behave@ietf.org; Mon, 02 Apr 2007 08:49:28 -0400 Received: from web33304.mail.mud.yahoo.com ([68.142.206.119]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYLyP-0000Pa-Ds for behave@ietf.org; Mon, 02 Apr 2007 08:49:28 -0400 Received: (qmail 49742 invoked by uid 60001); 2 Apr 2007 12:49:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=D6H9zAv3wz5ZN0jeyWRpvPmy/FDle9VMwInEAVZUg9z+8yEGgfFvPh6xMiTjY41sJmIdoTtF4cfoRGWWyiurLFRhY1SQjEhulVM6VAbVd2LqteGVn+3VhaCVhj2CZ7wIXyJ3eGDPmNR6n9lBWanEZ6+Pc7yOYADj2jYs2HMbFJk=; X-YMail-OSG: 4l2R9voVM1mPZrrum3g.QuY.0hML__zx_iAq16QQtdz_GFBEqbbwC1_RaM9SzYI5tsBaWPTvmsetaOZk8VTV6eb_XlGcq1gp4TJ4bmmES_bdrmPWO7TOHlM8xcScEgggvATBap0QMxw- Received: from [69.236.67.182] by web33304.mail.mud.yahoo.com via HTTP; Mon, 02 Apr 2007 05:49:24 PDT Date: Mon, 2 Apr 2007 05:49:24 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: "Rémi" Denis-Courmont , EKR , Behave WG In-Reply-To: <200704020922.58873.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <920356.49053.qm@web33304.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Right. I fully agree with Remi's comments. regards, suresh --- Rémi Denis-Courmont wrote: > On Monday 02 April 2007 01:13:07 ext EKR wrote: > > > But, the point that Fernando raises is that ICMP is a core signaling > > > protocol for IP and is required for the proper operation of all IP > > > transport protocols, not just TCP or UDP. > > > > Since lots of Internet firewalls block all ICMP, I think this assertion > > is arguable at best. > > But then again, if you are serious about isolating your Intranet, you should > use a firewall, but you should NOT user/rely on a NAT. > > Besides, a firewall can do pretty much anything, so it looks ridicule to me > that we would try to make the spec firewall-compliant (normally, it works the > > other way around). The only way a spec will be compliant with firewalls is > not to specify anything related to computer networking! > > NATs are meant to allow connectivity in case there are not enough IP > addresses; firewall are security devices. It is a purely incidental practical > > thing that both features are often implemented on the same box. > > At the very minimum, an BEHAVE-compliant box MUST NOT break Path MTU > discovery > (in particular not require TCP MSS clamping, which can only fix TCP anyway), > and it MUST let ICMP errors back to not degrade/break interactive > connectivity diagnostics -> user experience. > > -- > Rémi 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 Mon Apr 02 09:06: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 1HYMEY-0000I1-Td; Mon, 02 Apr 2007 09:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMEX-0000Hw-SV for behave@ietf.org; Mon, 02 Apr 2007 09:06:05 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYMEW-0005ZC-I8 for behave@ietf.org; Mon, 02 Apr 2007 09:06:05 -0400 Received: (qmail 13234 invoked by uid 60001); 2 Apr 2007 13:06:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=3d7cbxIc5rWUFAQaTsbwishtl5+Lr4TJZioNO7XNNoO1xboCloJe7u1mEVVys478vJY5IMTPkfMV/qKjN0yveimAwL2RHlJpTJv7AtYMux2ZLyt0aYnGUUVB00EegQRJpC2zU9xxZNHrWJha1LyGEy6NcpG6BIsUIWFuIIfRnjU=; X-YMail-OSG: 23JVCxMVM1n4cUnZhY7G7c0upTk6cmMORGe7Jueu4zF0urVkM5pqYoxAqTJ.5z.gZg-- Received: from [69.236.67.182] by web33312.mail.mud.yahoo.com via HTTP; Mon, 02 Apr 2007 06:06:03 PDT Date: Mon, 2 Apr 2007 06:06:03 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: "Rémi" Denis-Courmont , ext David Barrett , behave@ietf.org In-Reply-To: <200704021033.45585.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <967042.12511.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 --- Rémi Denis-Courmont wrote: > On Monday 02 April 2007 09:57:04 you wrote: > > > Not at all. TCP does not work at all without ICMP. Because of this, most > > > NAT > > > boxes have to do MSS clamping to fix it (in the same scenario as above). > > > Otherwise, you get your three-way handshake fine, and then the connection > > > breaks as soon as you send too large a data packet. > > > > Again, that's a very absolute statement that I'm pretty sure is wrong. TCP > > *can* function without ICMP. It might require some extra work, extra > > delays, and extra headaches. But it can and does work every day. > > Sure, if you the smallest MTU in the path in on the first hop, it works just > fine. Otherwise, it times out lamely as soon as the outpout buffer gets > bigger than the path MTU, and the TCP stacks keeps retrying to transmit a > packet that gets silently dropped (using widespread TCP stacks such as > Windows XP and Linux). > [suresh] Exactly. The point is not so much as whether TCP protocol is theoretically resilient to ICMP support in the network. The point, as Remi says, is that applications fail without it. > > I agree BEHAVE should specify how ICMP should be supported, if it's to be > > supported. But I disagree it should mandate ICMP be supported, anymore > > than it should mandate UPnP be supported merely because "it makes things > > work better". > > It makes some things work at all, which is very different. > [suresh] Right. David - RFC1812 mandates routers to generate, interpret and forward ICMP error messages. It is manadatory for a router to support ICMP error messages. Why do you believe ICMP support is not mandatory for a NAT device, whose principal functionality is routing between private and public realms? regards, suresh > -- > Rémi 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 Mon Apr 02 09:20:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMSA-0001mQ-Cf; Mon, 02 Apr 2007 09:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMS9-0001m3-QE for behave@ietf.org; Mon, 02 Apr 2007 09:20:09 -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 1HYMRv-0000hC-RB for behave@ietf.org; Mon, 02 Apr 2007 09:20:09 -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 l32DJBSf010227; Mon, 2 Apr 2007 16:19:21 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 16:19:12 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 16:19:12 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 16:19:12 +0300 Received: from [172.21.34.205] (esdhcp034205.research.nokia.com [172.21.34.205]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l32DJAQ2024733; Mon, 2 Apr 2007 16:19:10 +0300 In-Reply-To: <1979944F-E18B-4A7E-8E72-266E8833052F@cisco.com> References: <200703201902.l2KJ29Li011671@venus.xmundo.net> <77310124-63FA-4EA8-8413-F53B7B99A5EF@cisco.com> <200703260431.l2Q4V74Y008254@venus.xmundo.net> <1174894516.5591.29.camel@sioux.systems.cs.cornell.edu> <37F0BD4A-FE39-49E2-926A-42A973B4BE45@nokia.com> <1979944F-E18B-4A7E-8E72-266E8833052F@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <781F20D4-9E19-45A8-A807-E1C3F044F5FC@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 16:19:05 +0300 To: ext Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 13:19:12.0175 (UTC) FILETIME=[81007BF0:01C77529] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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: , Content-Type: multipart/mixed; boundary="===============1923572299==" Errors-To: behave-bounces@ietf.org --===============1923572299== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10--355749591; protocol="application/pkcs7-signature" --Apple-Mail-10--355749591 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-4-2, at 1:27, ext Cullen Jennings wrote: > On Mar 26, 2007, at 1:13 AM, Lars Eggert wrote: >> On 2007-3-26, at 9:35, ext Saikat Guha wrote: >>> Allowing or disallowing ICMP on a local network is a policy issue >>> for >>> the site. This site policy is out-of-scope of BEHAVE. What IS in >>> scope, >>> as Cullen said, is specifying how those packets are to be >>> translated if >>> site policy permits. >> >> If ICMPs were completely advisory, I'd agree, but they aren't >> (yet). Some ICMP messages are needed for the correct operation of >> transport protocols (must fragment), others are increasing >> efficiency (unreachables, etc.) > > Completely agree with Lars here - that is why the parts of ICMP > that are need to make UDP work are put into the behave document for > UDP, and likewise for other transport protocols. They clearly need > to be there otherwise we run the risk of the behave documentation > around ICMP actually breaking transport protocols which would be > clearly not the right path. > > This ICMP document is to deal with the ICMP applications that are > not associated with a transport protocol. I seem to recall that the > only two applications that the WG identified were ping and > traceroute but perhaps there were more. Ah. It wasn't clear to me that behave-nat-icmp was only focussing on ICMP translation that wasn't somehow related to transport protocols. It'd be very useful to put something like your explanation above into the abstract and introduction of the document. Lars --Apple-Mail-10--355749591 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA0MDIxMzE5MDZaMCMGCSqGSIb3DQEJBDEWBBTKd2W3fSm9z/oR uqM/TT8zQOxttjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAcxtBmZCVvpFQIRMogYTBfb1uUIARIjRt4jgMBz3CpED5GK84978w LwGu/dcfq1RbnS9wdRfvDzLRXDu5jOcKfChpv70swHULwyUfwx0AFsq3Qysl3EXJcYMrK26kigMs 9qB1C+hQFUK72RdymNXULo7JrjziNDyJT3F2UEk85AzkBw1ugGCsUWKE0+7pjrYVUsfACbKVeAk5 UtE8UruhPfZuQSfM55g8s/mU5zVrNSYx+7jCqtBafqeczwcCwNUWXe2AwLYuVpmU0Sn1ky+RWkeE 9q+azxCT6TMxBgY4MJNKMsEF4TY3RFUnETuYJ2knUZ0a+b/SW926yU68HdToqQAAAAAAAA== --Apple-Mail-10--355749591-- --===============1923572299== 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 --===============1923572299==-- From behave-bounces@ietf.org Mon Apr 02 09:24: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 1HYMVd-0003wy-9L; Mon, 02 Apr 2007 09:23:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMVc-0003v5-0t for behave@ietf.org; Mon, 02 Apr 2007 09:23:44 -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 1HYMVa-0006RZ-GU for behave@ietf.org; Mon, 02 Apr 2007 09:23:43 -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 l32DNRb1011739; Mon, 2 Apr 2007 16:23:35 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 16:23:32 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 16:23:28 +0300 Received: from [172.21.34.205] (esdhcp034205.research.nokia.com [172.21.34.205]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l32DNRCN027608; Mon, 2 Apr 2007 16:23:27 +0300 In-Reply-To: <068701c774af$04959840$6701a8c0@Quinthar> References: <068701c774af$04959840$6701a8c0@Quinthar> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 16:23:22 +0300 To: ext David Barrett X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 13:23:28.0945 (UTC) FILETIME=[1A0C7A10:01C7752A] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070402162336-2359EBB0-32C9F914/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: , Content-Type: multipart/mixed; boundary="===============0122051080==" Errors-To: behave-bounces@ietf.org --===============0122051080== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11--355492651; protocol="application/pkcs7-signature" --Apple-Mail-11--355492651 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-4-2, at 1:42, ext David Barrett wrote: > In my experience UDP works just fine in environments without ICMP > -- indeed, > you'd be crazy to depend upon it. Every UDP protocol that I've used > (including those that I develop) treats ICMP as a nice, but rarely > available > and totally unreliable perk. Probably true. > Even TCP, so far as I understand it, has well-paved fallbacks for > if ICMP is > unavailable (indeed, isn't ICMP availability technically a "special > case" in > the TCP stack?). Sure it might mean longer timeouts, greater > packet loss, > and smaller MTUs, but that's hardly the same as "correct > operation". TCP > works "correctly" without ICMP, just differently. Not true - see the Section on black holes in RFC2923. Once hosts implement the new method for PMTUD (RFC4821, just published), things will be different, but that can take a long time. Lars --Apple-Mail-11--355492651 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA0MDIxMzIzMjNaMCMGCSqGSIb3DQEJBDEWBBQLIa/Fth6tYy0t i+9KM+QFCJBPFjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAhAvyJSWo56EYRTmyc2PR00oHLTLyOdt/p/mHWW/gupTP8QmSMPAP p3XuNQtyxEfMuyC5/P/5MgdIr+lA+/snlbCkHl/pMXQrLTVP7KOEbeoY28O47vVgF6I6bvgmIx0q LPnyyDxDJLxVDE7gCdad+Dg+s/X+brSLq1HN5mArSAWqO70T76IyMJR5uZ0VlfMKWFriAgN60sKQ BhDIQ1ye3tR5ulAPsX0IN6gaEaw2Ta/TqtVcTyNMgR6L8t5fXan1XmoA/msrOmObiDLViaGLhKom 3+HihFHV1z9W3V+I+uRLAr4wDY4HZ0Nk+rZ7+upqMiVY3mSUJdcWV78MmlHgZgAAAAAAAA== --Apple-Mail-11--355492651-- --===============0122051080== 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 --===============0122051080==-- From behave-bounces@ietf.org Mon Apr 02 09:50: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 1HYMv5-0004YG-Tt; Mon, 02 Apr 2007 09:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMv4-0004YB-Si for behave@ietf.org; Mon, 02 Apr 2007 09:50:02 -0400 Received: from web33308.mail.mud.yahoo.com ([68.142.206.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYMv3-0000VP-IG for behave@ietf.org; Mon, 02 Apr 2007 09:50:02 -0400 Received: (qmail 4866 invoked by uid 60001); 2 Apr 2007 13:50:00 -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=SzUjBcF2yI17Fo35jWNQr1kiTtcRhdTy0xY8IcdQSVk6qp4hxRBu+YZAc/KS4bqGRmaGqN0F6l6PvUmSxL8roxpBUOUHkkz3dGUON6+fy6r96K6pq/4ellgP8SYpsXNqX8gGlaZimWynbMItH6ChFk5ts/219HwQXdGWGpydWas=; X-YMail-OSG: MovveEMVM1kcuV4u8gf0kUTphx_pq4oj1ENZ2d0nRQ3ETIXcvA.ddIzafjs6d9eHSleENUDc.qh2.uOwCwdEZgmPzsBYoM.lkStPS0BRKFWCMaagryg- Received: from [69.236.67.182] by web33308.mail.mud.yahoo.com via HTTP; Mon, 02 Apr 2007 06:49:59 PDT Date: Mon, 2 Apr 2007 06:49:59 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: Lars Eggert , ext Cullen Jennings In-Reply-To: <781F20D4-9E19-45A8-A807-E1C3F044F5FC@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <943844.4823.qm@web33308.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 --- Lars Eggert wrote: > On 2007-4-2, at 1:27, ext Cullen Jennings wrote: > > On Mar 26, 2007, at 1:13 AM, Lars Eggert wrote: > >> On 2007-3-26, at 9:35, ext Saikat Guha wrote: > >>> Allowing or disallowing ICMP on a local network is a policy issue > >>> for > >>> the site. This site policy is out-of-scope of BEHAVE. What IS in > >>> scope, > >>> as Cullen said, is specifying how those packets are to be > >>> translated if > >>> site policy permits. > >> > >> If ICMPs were completely advisory, I'd agree, but they aren't > >> (yet). Some ICMP messages are needed for the correct operation of > >> transport protocols (must fragment), others are increasing > >> efficiency (unreachables, etc.) > > > > Completely agree with Lars here - that is why the parts of ICMP > > that are need to make UDP work are put into the behave document for > > UDP, and likewise for other transport protocols. They clearly need > > to be there otherwise we run the risk of the behave documentation > > around ICMP actually breaking transport protocols which would be > > clearly not the right path. > > > > This ICMP document is to deal with the ICMP applications that are > > not associated with a transport protocol. I seem to recall that the > > only two applications that the WG identified were ping and > > traceroute but perhaps there were more. > > Ah. It wasn't clear to me that behave-nat-icmp was only focussing on > ICMP translation that wasn't somehow related to transport protocols. > It'd be very useful to put something like your explanation above into > the abstract and introduction of the document. > [suresh] Lars - behave-nat-icmp is transport protocol agnostic and specifies the translation of ICMP messages (Ex: req 3, 4, 5, 7). The specification of how an embedded payload specific to a transport protocol is transalted (or) how a NAT ought to react to a payoad is left to transport protocol specific BEHAVE documents. regards, suresh > Lars > > > > _______________________________________________ > 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 Mon Apr 02 10:49: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 1HYNqQ-0002rc-4a; Mon, 02 Apr 2007 10:49:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNqP-0002rX-Rr for behave@ietf.org; Mon, 02 Apr 2007 10:49:17 -0400 Received: from sd-green-bigip-83.dreamhost.com ([208.97.132.83] helo=randymail-a12.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYNqM-0003XU-Eq for behave@ietf.org; Mon, 02 Apr 2007 10:49:17 -0400 Received: from delta.rtfm.com (unknown [74.95.2.174]) by randymail-a12.g.dreamhost.com (Postfix) with ESMTP id BF3DBA788B; Mon, 2 Apr 2007 07:49:09 -0700 (PDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id DF3201CC6B; Mon, 2 Apr 2007 07:47:35 -0700 (PDT) To: Remi Denis-Courmont Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt References: <353877.87097.qm@web33310.mail.mud.yahoo.com> <86ejn35zzq.fsf@delta.rtfm.com> <200704020923.01985.remi.denis-courmont@nokia.com> From: EKR In-Reply-To: <200704020923.01985.remi.denis-courmont@nokia.com> (Remi Denis-Courmont's message of "Mon, 2 Apr 2007 09:23:01 +0300") User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) Date: Mon, 02 Apr 2007 07:47:35 -0700 Message-ID: <863b3ivnnc.fsf@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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 writes: > On Monday 02 April 2007 04:25:29 ext EKR wrote: >> > [suresh] Are you saying that some firewalls are configured to block >> > all ICMP - ICMP queries and ICMP errors, inbound and outbound? That >> > seems flawed. >> >> It's quite common, actually. > > It's quite common. Sure. But first, in most case, it blocks pretty much= =20 > everything else too for security reasons (your typical corporate Intran= et=20 > with proxies of all types and only outbound NTP and/or DNS or so allowe= d). Not so. It's reasonably common for packet filters to (for instance) pass established TCP but not ICMP. Not all firewalls are proxies. > And if not, it's completely flawed, whether it exists or not. Saying th= at this=20 > is bad by forbidding this in BEHAVE specs actually looks good to me. It= 's not=20 > like the BEHAVE working group will change or remove these firewalls mag= ically=20 > by telling they are non compliant. As far as I am concerned, you can st= ill=20 > continue sell thse boxes - so what are you complaining about? 1. You're making the assumption that I sell such boxes. I don't. 2. What I'm complaining about is that the WG isn't chartered to=20 declare a large swath of the network noncompliant. >> > Is there an IETF document that recommends this setting to >> > administrators? I can understand if some firewalls block inbound >> > ICMP queries. But, why are the ICMP errors blocked? >> >> Because correlating them to the flows they refer to is a pain >> and it's easier to block them directly. > > That's laughable. The original pristine packet headers are inside ICMP = errors=20 > messsages. It's actually easier to match an ICMP error to a flow than a= real=20 > reply packet of some transport protocol. Doing more work is always more work than doing no work, even if the work is inherently easy.=20 >> > There are >> > many admins that block UDP traffci entirely. That does not mean we >> > recommend NATs to not support UDP packets. >> >> Recommending that someone block X is not the same as not requiring >> that someone not block X. > > Recommending that someone does not block X is not the same as passing a= law=20 > that someone must not block X. Yes, but I didn't suggest either of those. Rather, I suggested that the WG *not* require that it pass X.=20 -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 02 10:53: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 1HYNuU-0001Bx-H0; Mon, 02 Apr 2007 10:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNuS-0001Bo-OQ for behave@ietf.org; Mon, 02 Apr 2007 10:53:28 -0400 Received: from sd-green-bigip-81.dreamhost.com ([208.97.132.81] helo=randymail-a8.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYNuR-00047X-Fe for behave@ietf.org; Mon, 02 Apr 2007 10:53:28 -0400 Received: from delta.rtfm.com (unknown [74.95.2.174]) by randymail-a8.g.dreamhost.com (Postfix) with ESMTP id 2E896AF595; Mon, 2 Apr 2007 07:53:20 -0700 (PDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id 2CABD1CC6B; Mon, 2 Apr 2007 07:51:51 -0700 (PDT) To: Remi Denis-Courmont Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt References: <980067.9532.qm@web33312.mail.mud.yahoo.com> <867isv7ngs.fsf@delta.rtfm.com> <200704020922.58873.remi.denis-courmont@nokia.com> From: EKR In-Reply-To: <200704020922.58873.remi.denis-courmont@nokia.com> (Remi Denis-Courmont's message of "Mon, 2 Apr 2007 09:22:58 +0300") User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) Date: Mon, 02 Apr 2007 07:51:51 -0700 Message-ID: <86ejn2u8vs.fsf@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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 writes: > On Monday 02 April 2007 01:13:07 ext EKR wrote: >> > But, the point that Fernando raises is that ICMP is a core signaling >> > protocol for IP and is required for the proper operation of all IP >> > transport protocols, not just TCP or UDP. >> >> Since lots of Internet firewalls block all ICMP, I think this assertio= n >> is arguable at best. > > But then again, if you are serious about isolating your Intranet, you s= hould=20 > use a firewall, but you should NOT user/rely on a NAT. The problem is that as Greg Lebovitz pointed out in Prague, many (most?) NATs now provide some sort of access control functionality. I.e., they are firewalls. > NATs are meant to allow connectivity in case there are not enough IP=20 > addresses;=20 That's far from the only reason people deploy NATs. > firewall are security devices. It is a purely incidental practical=20 > thing that both features are often implemented on the same box. No, it's not. > At the very minimum, an BEHAVE-compliant box MUST NOT break Path MTU > discovery (in particular not require TCP MSS clamping, which can > only fix TCP anyway), and it MUST let ICMP errors back to not > degrade/break interactive connectivity diagnostics -> user > experience. 1. The current draft requires that boxes permit ICMP query apps (see S 3.1.) 2. You're just asserting this, but I don't find the argument behind it very convincing. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 02 11:17: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 1HYOH9-0001o0-Bk; Mon, 02 Apr 2007 11:16:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOH7-0001nE-NR for behave@ietf.org; Mon, 02 Apr 2007 11:16:53 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYOH2-00072E-78 for behave@ietf.org; Mon, 02 Apr 2007 11:16:53 -0400 Received: from Quinthar ([201.140.188.144]) by quinthar.com for ; Mon, 2 Apr 2007 08:16:33 -0700 From: "David Barrett" To: "'Pyda Srisuresh'" , =?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?= , Subject: RE: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 10:15:23 -0500 Message-ID: <016601c77539$e4aa2510$6b01a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd1J64xuZzmWnviQv6GRIdBHIhi9AACjemw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <967042.12511.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 My understanding is BEHAVE-compliance basically means "the protocols supported on this device are correctly translated", and not = "applications will work well with this gateway device". That latter seems like a much bigger and more nebulous topic. So it still sounds like the two approaches are: 1) Mandate all BEHAVE-compliant gateway devices support ICMP 2) Recommend all BEHAVE-compliant gateway devices support ICMP I still favor taking a protocol-by-protocol approach: if you claim to support protocol X, here's the proper way to perform NAT translation. = I'd continue favoring this approach even if it were shown ICMP were truly critical. Fundamentally, the choice of which protocols to support is a filtering decision, which (I think) is out of BEHAVE scope. -david Remi -- As for the XP and Linux TCP stacks, you're saying that when they ramp their transmit window up to larger than the path MTU they will = *never* recover without ICMP? They will never timeout and retry a smaller = packet? Pyda -- As for RFC1812 mandating ICMP, that's great. Then there's no = reason to re-mandate it here. If BEHAVE says "if you support ICMP, do X", and = if everyone is compliant with RFC1812, then everyone will "do X". But if someone doesn't support ICMP, then they're not compliant with RFC1812, = which seems like a bigger deal than whether or not they comply with BEHAVE. Alternatively, let's say for whatever reason RFC1812 were changed to no longer require ICMP. Should BEHAVE supersede that decision and still require it? Why the redundancy? -david =20 > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Monday, April 02, 2007 8:06 AM > To: R=E9mi Denis-Courmont; ext David Barrett; behave@ietf.org > Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt >=20 >=20 > --- R=E9mi Denis-Courmont wrote: >=20 > > On Monday 02 April 2007 09:57:04 you wrote: > > > > Not at all. TCP does not work at all without ICMP. Because of = this, > most > > > > NAT > > > > boxes have to do MSS clamping to fix it (in the same scenario as > above). > > > > Otherwise, you get your three-way handshake fine, and then the > connection > > > > breaks as soon as you send too large a data packet. > > > > > > Again, that's a very absolute statement that I'm pretty sure is = wrong. > TCP > > > *can* function without ICMP. It might require some extra work, = extra > > > delays, and extra headaches. But it can and does work every day. > > > > Sure, if you the smallest MTU in the path in on the first hop, it = works > just > > fine. Otherwise, it times out lamely as soon as the outpout buffer = gets > > bigger than the path MTU, and the TCP stacks keeps retrying to = transmit > a > > packet that gets silently dropped (using widespread TCP stacks such = as > > Windows XP and Linux). > > > [suresh] Exactly. The point is not so much as whether TCP protocol is > theoretically resilient to ICMP support in the network. The point, as = Remi > says, is that applications fail without it. >=20 > > > I agree BEHAVE should specify how ICMP should be supported, if = it's to > be > > > supported. But I disagree it should mandate ICMP be supported, > anymore > > > than it should mandate UPnP be supported merely because "it makes > things > > > work better". > > > > It makes some things work at all, which is very different. > > >=20 > [suresh] Right. >=20 > David - RFC1812 mandates routers to generate, interpret and forward = ICMP > error > messages. It is manadatory for a router to support ICMP error = messages. > Why do > you believe ICMP support is not mandatory for a NAT device, whose > principal > functionality is routing between private and public realms? >=20 > regards, > suresh >=20 >=20 > > -- > > R=E9mi Denis-Courmont > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 02 11:28: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 1HYORo-0001He-FN; Mon, 02 Apr 2007 11:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYORn-0001FS-16 for behave@ietf.org; Mon, 02 Apr 2007 11:27:55 -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 1HYORl-00086N-J6 for behave@ietf.org; Mon, 02 Apr 2007 11:27:55 -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 l32FRUqp022287; Mon, 2 Apr 2007 18:27:51 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 18:27:42 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 18:27:42 +0300 Received: from [172.21.34.205] (esdhcp034205.research.nokia.com [172.21.34.205]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l32FRev9027421; Mon, 2 Apr 2007 18:27:40 +0300 In-Reply-To: <016601c77539$e4aa2510$6b01a8c0@Quinthar> References: <016601c77539$e4aa2510$6b01a8c0@Quinthar> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <1BAA5608-6EFE-45ED-8975-5287B6D25465@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 18:27:35 +0300 To: "ext David Barrett" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 15:27:42.0106 (UTC) FILETIME=[747A97A0:01C7753B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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="===============0763448540==" Errors-To: behave-bounces@ietf.org --===============0763448540== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-16--348039562; protocol="application/pkcs7-signature" --Apple-Mail-16--348039562 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-4-2, at 18:15, ext David Barrett wrote: > My understanding is BEHAVE-compliance basically means "the protocols > supported on this device are correctly translated", and not > "applications > will work well with this gateway device". That latter seems like a > much > bigger and more nebulous topic. > > So it still sounds like the two approaches are: > 1) Mandate all BEHAVE-compliant gateway devices support ICMP > 2) Recommend all BEHAVE-compliant gateway devices support ICMP We discussed another option, too: (3) Recommend that BEHAVE compliant devices that translate transport protocol X also translate ICMP messages Y and Z, because X's correct operation depends on them. (So, if your NAT translates TCP it should translate ICMP "packet too big", because otherwise you can run into blackholes. If it doesn't translate TCP, maybe it doesn't need to translate that ICMP message.) I think that is similar what you describe here: > I still favor taking a protocol-by-protocol approach: if you claim to > support protocol X, here's the proper way to perform NAT translation. It's just that the "proper way" may include translating some ICMP messages. > Remi -- As for the XP and Linux TCP stacks, you're saying that when > they > ramp their transmit window up to larger than the path MTU they will > *never* > recover without ICMP? They will never timeout and retry a smaller > packet? (1) TCP windows are unrelated to segment sizes. (2) There are _many_ end system stacks other than Linux and XP out there. (3) There are TCP implementation techniques (did you look at RFC2923?), but they are not standards recommendations. Lars --Apple-Mail-16--348039562 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA0MDIxNTI3MzZaMCMGCSqGSIb3DQEJBDEWBBSM5FVDdvR0fNne uowj0Q3wwoJrXDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEABDYnveIo6JLtl/AZHXrmT7o9Ux2Axjt0scGA1ErBpvJ/hlYhfdY8 Lm6PgUOXop9+3B5D7wvcT9JJFBMbnFK49eBms2lmPfTbPQRq41ENpfLjfN8bf54HpncJR+rcV6Gu 3X/O1ve4CLbF13fdI8tYXVTaJ3QAAqY1/hjjgdDwJqRx9+ySX5kAqydgJa+AV0FL6MYvIaPF57ij 4CILpIAdwvNdMN9SB4dWfIrpJz+LA4PvmK9nzF5NE/BIb7qhU3k6Ggm+7liZbWI1d5CaXeWdeFbm aJeHLAOfO/0A664BBn+6ErSCY2gUaPYiap9afVtU1GRRU4UncH2Uto2lGJiCrAAAAAAAAA== --Apple-Mail-16--348039562-- --===============0763448540== 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 --===============0763448540==-- From behave-bounces@ietf.org Mon Apr 02 12:04:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYP0T-00048g-2K; Mon, 02 Apr 2007 12:03:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYP0S-00048b-AN for behave@ietf.org; Mon, 02 Apr 2007 12:03:44 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYP0M-0006GA-KC for behave@ietf.org; Mon, 02 Apr 2007 12:03:44 -0400 Received: from Quinthar ([201.140.188.144]) by quinthar.com for ; Mon, 2 Apr 2007 09:03:33 -0700 From: "David Barrett" To: "'Lars Eggert'" Subject: RE: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 2 Apr 2007 11:03:23 -0500 Message-ID: <019001c77540$7518e130$6b01a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd1O31byQqsJDKzRLumvRPyROq3ZgABMCrg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1BAA5608-6EFE-45ED-8975-5287B6D25465@nokia.com> 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 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > > > So it still sounds like the two approaches are: > > 1) Mandate all BEHAVE-compliant gateway devices support ICMP > > 2) Recommend all BEHAVE-compliant gateway devices support ICMP > > We discussed another option, too: > > (3) Recommend that BEHAVE compliant devices that translate transport > protocol X also translate ICMP messages Y and Z, because X's correct > operation depends on them. > > (So, if your NAT translates TCP it should translate ICMP "packet too > big", because otherwise you can run into blackholes. If it doesn't > translate TCP, maybe it doesn't need to translate that ICMP message.) Ah, I like this plan. I'm sorry I didn't catch onto it before. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 03 03:50:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYdma-0002rZ-Re; Tue, 03 Apr 2007 03:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYdma-0002rR-A5 for behave@ietf.org; Tue, 03 Apr 2007 03:50:24 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYdmU-00049T-MM for behave@ietf.org; Tue, 03 Apr 2007 03:50:24 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 21ECB2158D; Tue, 3 Apr 2007 09:50:16 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-44-461207384752 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F39E721580; Tue, 3 Apr 2007 09:50:15 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 09:50:15 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 09:50:15 +0200 Message-ID: <46120737.7020002@ericsson.com> Date: Tue, 03 Apr 2007 09:50:15 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: EKR Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt References: <353877.87097.qm@web33310.mail.mud.yahoo.com> <86ejn35zzq.fsf@delta.rtfm.com> <200704020923.01985.remi.denis-courmont@nokia.com> <863b3ivnnc.fsf@delta.rtfm.com> In-Reply-To: <863b3ivnnc.fsf@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 03 Apr 2007 07:50:15.0250 (UTC) FILETIME=[B74A7B20:01C775C4] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 EKR skrev: > R=E9mi Denis-Courmont writes: >=20 >> On Monday 02 April 2007 04:25:29 ext EKR wrote: >>>> [suresh] Are you saying that some firewalls are configured to block >>>> all ICMP - ICMP queries and ICMP errors, inbound and outbound? That >>>> seems flawed. >>> It's quite common, actually. >> It's quite common. Sure. But first, in most case, it blocks pretty muc= h=20 >> everything else too for security reasons (your typical corporate Intra= net=20 >> with proxies of all types and only outbound NTP and/or DNS or so allow= ed). >=20 > Not so. It's reasonably common for packet filters to (for instance) > pass established TCP but not ICMP. Not all firewalls are proxies. >=20 >=20 >> And if not, it's completely flawed, whether it exists or not. Saying t= hat this=20 >> is bad by forbidding this in BEHAVE specs actually looks good to me. I= t's not=20 >> like the BEHAVE working group will change or remove these firewalls ma= gically=20 >> by telling they are non compliant. As far as I am concerned, you can s= till=20 >> continue sell thse boxes - so what are you complaining about? >=20 > 1. You're making the assumption that I sell such boxes. I don't. > 2. What I'm complaining about is that the WG isn't chartered to=20 > declare a large swath of the network noncompliant. >=20 >=20 >>>> Is there an IETF document that recommends this setting to >>>> administrators? I can understand if some firewalls block inbound >>>> ICMP queries. But, why are the ICMP errors blocked? >>> Because correlating them to the flows they refer to is a pain >>> and it's easier to block them directly. >> That's laughable. The original pristine packet headers are inside ICMP= errors=20 >> messsages. It's actually easier to match an ICMP error to a flow than = a real=20 >> reply packet of some transport protocol. >=20 > Doing more work is always more work than doing no work, even if the > work is inherently easy.=20 >=20 >=20 >=20 >>>> There are >>>> many admins that block UDP traffci entirely. That does not mean we >>>> recommend NATs to not support UDP packets. >>> Recommending that someone block X is not the same as not requiring >>> that someone not block X. >> Recommending that someone does not block X is not the same as passing = a law=20 >> that someone must not block X. >=20 > Yes, but I didn't suggest either of those. Rather, I suggested that > the WG *not* require that it pass X.=20 >=20 EKR and R=E9mi, I guess the problem here is how one writes this up. BEHAVE WG can=20 clearly specify a requirement on forwarding and how to do it for ICMP if=20 one actually get it past the firewall/filtering behavior. But the=20 reality unfortunately is that most ICMP will be filtered away. And I=20 guess we need that disclaimer here. But we can't put requirements on the=20 filtering because that is not BEHAVE's task. What can be done is explain=20 why it is recommend that you forward ICMP messages that clearly can be=20 associated with existing flows being passed through the NAT. 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 Tue Apr 03 04:33:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeRn-0002Pp-Nl; Tue, 03 Apr 2007 04:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeRm-0002Pf-6E for behave@ietf.org; Tue, 03 Apr 2007 04:32:58 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYeRj-00023W-M0 for behave@ietf.org; Tue, 03 Apr 2007 04:32:58 -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 l338WXvr009737; Tue, 3 Apr 2007 11:32:53 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:32:41 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:32:41 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:32:40 +0300 Received: from esdhcp040120.research.nokia.com (esdhcp040120.research.nokia.com [172.21.40.120]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l338WdZv016764; Tue, 3 Apr 2007 11:32:39 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: EKR Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Tue, 3 Apr 2007 11:32:51 +0300 User-Agent: KMail/1.9.6 References: <353877.87097.qm@web33310.mail.mud.yahoo.com> <200704020923.01985.remi.denis-courmont@nokia.com> <863b3ivnnc.fsf@delta.rtfm.com> In-Reply-To: <863b3ivnnc.fsf@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704031132.51900.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Apr 2007 08:32:41.0008 (UTC) FILETIME=[A4AE5300:01C775CA] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Monday 02 April 2007 17:47:35 ext EKR wrote: > Not so. It's reasonably common for packet filters to (for instance) > pass established TCP but not ICMP. Not all firewalls are proxies. However common, not passing Packet too big errors breaks about any currentl= y=20 deployed TCP stack. And not passing other ICMP errors degrade interactive=20 connection diagnostics. A firewall that blocks *ALL* ICMP *IN ANY CASE* is broken. Full point. Yes,= =20 that happens, and frequently. The fact that it is a common mistake does in = no=20 way means that it should be allowed by standards. Besides, it's not like people are going to rush upgrading their firewalls f= or=20 BEHAVE compliance. I would actually expect that (regardless of ICMP) some=20 security "experts" will claim that BEHAVE is insecure. It allows some kind = of=20 firewall evasion, they'll claim. So IT manager should buy this nice=20 symmetric-NAT/firewall combo instead of that BEHAVE-conformant box. And of= =20 course, the first one will also ship various ALGs for all the hype-of-year= =20 protocols, and turn out to be plain broken next year. =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 Apr 03 15:51: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 1HYp1g-00054v-Nd; Tue, 03 Apr 2007 15:50:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp1Y-0004Yj-3E; Tue, 03 Apr 2007 15:50:36 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYp1W-0000RM-JQ; Tue, 03 Apr 2007 15:50:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 05BBE17698; Tue, 3 Apr 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HYp10-0007nv-EK; Tue, 03 Apr 2007 15:50:02 -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: Tue, 03 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-tcp-06.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 : NAT Behavioral Requirements for TCP Author(s) : S. Guha, et al. Filename : draft-ietf-behave-tcp-06.txt Pages : 20 Date : 2007-4-3 This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-06.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-tcp-06.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-tcp-06.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-4-3112309.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-tcp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-tcp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-3112309.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 Apr 04 10:39:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6e1-00046z-2g; Wed, 04 Apr 2007 10:39:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURlx-0007iP-98 for behave@ietf.org; Thu, 22 Mar 2007 14:12:25 -0400 Received: from 67.111.218.99.ptr.us.xo.net ([67.111.218.99] helo=cuda.ubicom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HURlv-0002wv-UZ for behave@ietf.org; Thu, 22 Mar 2007 14:12:25 -0400 X-ASG-Debug-ID: 1174587142-2481000d0000-9RCVFZ X-Barracuda-URL: http://172.18.1.15:80/cgi-bin/mark.cgi X-Barracuda-Connect: stork.scenix.com[10.10.10.30] X-Barracuda-Start-Time: 1174587142 Received: from STORK.scenix.com (stork.scenix.com [10.10.10.30]) by cuda.ubicom.com (Spam Firewall) with ESMTP id 7F74926F83; Thu, 22 Mar 2007 11:12:22 -0700 (PDT) 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 X-ASG-Orig-Subj: RE: [BEHAVE] RE: SecDir review of draft-ietf-behave-tcp-05 Subject: RE: [BEHAVE] RE: SecDir review of draft-ietf-behave-tcp-05 Date: Thu, 22 Mar 2007 11:12:21 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] RE: SecDir review of draft-ietf-behave-tcp-05 Thread-Index: AcdsAvQNop0zd2DzQx+9Ow8WXkFOiQAVmKSgABUB77A= From: "Dave Hudson" To: , , X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at ubicom.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Wed, 04 Apr 2007 10:39:26 -0400 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 * -----Original Message----- * From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 * Sent: 22 March 2007 08:21 * To: saikat@cs.cornell.edu; behave@ietf.org * Subject: [BEHAVE] RE: SecDir review of draft-ietf-behave-tcp-05 *=20 * No, but for translation of TCP to work, NATs are required to=20 * handle sequence numbers in correct fashion (just like NATs=20 * are required to handle TCP state machine correctly, REQ-2).=20 *=20 * I think prohibiting behavior known to break TCP, which is=20 * known to be implemented by some NATs, should be in scope. =20 * NAT implementors may not realize that incorrectly implemented=20 * seq# rewriting actually breaks things... and even if SACK is=20 * handled correctly, it breaks the ability to add certain kinds=20 * of options to TCP later. So actually NOT rewriting TCP seq#=20 * is required for future-proof correct translation of TCP. *=20 * IMHO this document should alert NAT implementors that seq#=20 * rewriting is difficult to implement correctly today, and=20 * impossible to implement correctly in a future-proof way. I'm=20 * not suggesting any extensive changes; five lines or something=20 * should be quite enough. Of course we have to be careful here not to add wording that prevents necessary rewriting of sequence numbers. Many text-based protocol ALGs have to do this (e.g. FTP). Regards, Dave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 04 12:12: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 1HZ868-0002i3-Qj; Wed, 04 Apr 2007 12:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ867-0002ca-BQ for behave@ietf.org; Wed, 04 Apr 2007 12:12:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ864-0004kI-15 for behave@ietf.org; Wed, 04 Apr 2007 12:12:35 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2007 09:12:33 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l34GCVIY008548; Wed, 4 Apr 2007 09:12:31 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l34GCUA8026806; Wed, 4 Apr 2007 16:12:30 GMT From: "Dan Wing" To: "'Saikat Guha'" Subject: RE: [BEHAVE] RE: SecDir review of draft-ietf-behave-tcp-05 Date: Wed, 4 Apr 2007 09:12:30 -0700 Message-ID: <32d801c776d4$0c3d5980$c4f0200a@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: <1174869626.21195.43.camel@sioux.systems.cs.cornell.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdvQGI7o/anC6JnTYe5ctWsB7+nDgHk2tiA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1304; t=1175703151; x=1176567151; c=relaxed/simple; s=sjdkim5002; 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=20SecDir=20review=20of=20draft-ietf- behave-tcp-05 |Sender:=20; bh=KvBpkylfxFrPtbyhUAz1iNGuDFGAXme8Et5siizRevw=; b=Ys2oe4OF5a6cs6lRnuI0CHglw9gxlj1T8CK4T+gzhTi6s3X1ScBjX3ycMga9USGW2mu+4hZZ 85RRm5tgSq5IcRE9HA/a1T3Nc7X+hwXUUyetVegQ7pBUZXjMXvVgGqro; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Pasi.Eronen@nokia.com, 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: Saikat Guha [mailto:saikat@cs.cornell.edu] > Sent: Sunday, March 25, 2007 5:40 PM > To: Pasi.Eronen@nokia.com > Cc: behave@ietf.org > Subject: [BEHAVE] RE: SecDir review of draft-ietf-behave-tcp-05 > > On Thu, 2007-03-22 at 10:21 +0200, Pasi.Eronen@nokia.com wrote: > > No, but for translation of TCP to work, NATs are required to handle > > sequence numbers in correct fashion (just like NATs are required to > > handle TCP state machine correctly, REQ-2). > > Fair enough. ALGs aside, not supporting SACK when the NAT is munging > seq# for privacy reasons can be viewed as an information leak. > > Perhaps adding the following sentence to the security section would > help: > > "NAT implementations that modify TCP sequence numbers for privacy > reasons or ALG support must ensure that TCP packets with SACK > notifications are properly handled." > > Thoughts? Please make the "for privacy reasons" an example, like this: "NAT implementations that modify TCP sequence numbers (e.g., for privacy reasons) or ALG support must ensure that TCP packets with SACK notifications are properly handled." (Sorry for my delay, I just returned from a 10-day vacation.) -d > cheers, > -- > Saikat > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 04 16:56:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCWq-0000BV-RD; Wed, 04 Apr 2007 16:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCWp-000075-WB for behave@ietf.org; Wed, 04 Apr 2007 16:56:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCWm-0001uu-Hx for behave@ietf.org; Wed, 04 Apr 2007 16:56:27 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2007 13:56:23 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l34KuNbn023283; Wed, 4 Apr 2007 13:56:23 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l34KuIwn021478; Wed, 4 Apr 2007 20:56:18 GMT From: "Dan Wing" To: "'Lars Eggert'" , "'ext David Barrett'" Subject: RE: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Wed, 4 Apr 2007 13:56:18 -0700 Message-ID: <379001c776fb$b4084c20$c4f0200a@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: <1BAA5608-6EFE-45ED-8975-5287B6D25465@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd1O41z/lqkHwUcSoGURCadZZtaIABv7qdQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3208; t=1175720183; x=1176584183; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20draft-ietf-behave-nat-icmp-03.txt |Sender:=20; bh=DhOuT1kBFy0hlYvcv8sJPmfNa0lMOIjwDImP2CBCC6M=; b=UsN2Hvf8dlSmATfOJeJu1LNvyjGpERDfElLw3faOZMiar4sxWcx8G7Be/eH/WcVR+ok5lSSo i+GtOWvxVabBDVC6qiTGAu+AnkPq/YHiq2VCCV0c2qcHKkL3DaWG8n3q; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Lars Eggert wrote: > On 2007-4-2, at 18:15, ext David Barrett wrote: > > My understanding is BEHAVE-compliance basically means "the protocols > > supported on this device are correctly translated", and not > > "applications > > will work well with this gateway device". That latter > > seems like a much bigger and more nebulous topic. > > > > So it still sounds like the two approaches are: > > 1) Mandate all BEHAVE-compliant gateway devices support ICMP > > 2) Recommend all BEHAVE-compliant gateway devices support ICMP > > We discussed another option, too: > > (3) Recommend that BEHAVE compliant devices that translate transport > protocol X also translate ICMP messages Y and Z, because X's correct > operation depends on them. > > (So, if your NAT translates TCP it should translate ICMP "packet too > big", because otherwise you can run into blackholes. If it doesn't > translate TCP, maybe it doesn't need to translate that ICMP message.) Yes, and that 3rd option is what our TCP document does. As a specific example of this text, the TCP document says: ... 7. Other Requirements Applicable to TCP A list of general and UDP specific NAT behavioral requirements are described in [BEHAVE-UDP]. A list of ICMP specific NAT behavioral requirements are described in [BEHAVE-ICMP]. The requirements listed below reiterate the requirements from these two documents that directly affect TCP. The following requirements do not relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP]. ... 7.3. ICMP Responses to TCP Packets ICMP responses are used by end-host TCP stacks for Path MTU Discovery and for quick error detection. ICMP messages are rewritten by the NAT (specifically the IP headers and the headers inside the ICMP payload) and forwarded to the appropriate internal or external host. Blocking any ICMP message is discouraged. REQ-9: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or TCP connection for which the ICMP was generated. Justification: This is necessary for reliably performing TCP simultaneous-open where a remote NAT may temporarily signal an ICMP error. It is also useful for MTU discovery. ... Which has been the consensus of the working group. -d > I think that is similar what you describe here: > > > I still favor taking a protocol-by-protocol approach: if you > > claim to support protocol X, here's the proper way to perform > > NAT translation. > > It's just that the "proper way" may include translating some ICMP > messages. > > > Remi -- As for the XP and Linux TCP stacks, you're saying > > that when they > > ramp their transmit window up to larger than the path MTU > > they will *never* > > recover without ICMP? They will never timeout and retry a > > smaller packet? > > (1) TCP windows are unrelated to segment sizes. > (2) There are _many_ end system stacks other than Linux and XP out > there. > (3) There are TCP implementation techniques (did you look at > RFC2923?), but they are not standards recommendations. > > Lars > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 04 19:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFNW-00057O-0b; Wed, 04 Apr 2007 19:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFNV-00057J-Fb for behave@ietf.org; Wed, 04 Apr 2007 19:59:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFNR-0002DL-9Y for behave@ietf.org; Wed, 04 Apr 2007 19:59:01 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2007 16:58:58 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l34NwuvD023975; Wed, 4 Apr 2007 16:58:56 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l34Nwiww022674; Wed, 4 Apr 2007 23:58:56 GMT In-Reply-To: <4607DC3F.8090000@cisco.com> References: <4607DC3F.8090000@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <722515F0-8B41-486A-AC1B-DCA3271A9929@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] STUN error response registry Date: Wed, 4 Apr 2007 12:16:36 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=815; t=1175731136; x=1176595136; c=relaxed/simple; s=sjdkim8002; 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]=20STUN=20error=20response=20registry |Sender:=20; bh=7XhKzaaU1ndq9klyP2m6Mp+nQiEfJ8RlmSK81KCXZ78=; b=o5ifYm/PQlP0Qy51OIdorYgSEwrcLmAZBq2/Ltjxr5tf3w5O2UgpJnkokwZ6UepIa5caV3cW 2+fJgpCnZL0HfouHuUMu6ceItU7nu+xsW8dtDJoh+celoxzbgjsAPdlq; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Mar 26, 2007, at 7:44 AM, Jonathan Rosenberg wrote: > rfc3489bis establishes a registry for attributes and methods but > not responses. We've had trouble with resposnes too, so I suggest a > registry for them also. Unless someone objects I'll add that to the > next revision. sounds good. > > I also suggest that having a working webpage like: > http://www.employees.org/behave/stun-attributes.html I would probably rather not do this - I would be very worried about creating shadow registries to IANA. Thought we have had examples of conflicts in drafts before, it has typically not been a problem in most IETF work. Right now there are non IANA defacto web page registries for some DNS stuff and that example has convinced me there are lots of problems with that path. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 04 19:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFNJ-00054p-Ki; Wed, 04 Apr 2007 19:58:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.orgFrom behave-bounces@ietf.org Wed Apr 04 19:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFNW-00057O-0b; Wed, 04 Apr 2007 19:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFNV-00057J-Fb for behave@ietf.org; Wed, 04 Apr 2007 19:59:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFNR-0002DL-9Y for behave@ietf.org; Wed, 04 Apr 2007 19:59:01 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2007 16:58:58 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l34NwuvD023975; Wed, 4 Apr 2007 16:58:56 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l34Nwiww022674; Wed, 4 Apr 2007 23:58:56 GMT In-Reply-To: <4607DC3F.8090000@cisco.com> References: <4607DC3F.8090000@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <722515F0-8B41-486A-AC1B-DCA3271A9929@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] STUN error response registry Date: Wed, 4 Apr 2007 12:16:36 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=815; t=1175731136; x=1176595136; c=relaxed/simple; s=sjdkim8002; 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]=20STUN=20error=20response=20registry |Sender:=20; bh=7XhKzaaU1ndq9klyP2m6Mp+nQiEfJ8RlmSK81KCXZ78=; b=o5ifYm/PQlP0Qy51OIdorYgSEwrcLmAZBq2/Ltjxr5tf3w5O2UgpJnkokwZ6UepIa5caV3cW 2+fJgpCnZL0HfouHuUMu6ceItU7nu+xsW8dtDJoh+celoxzbgjsAPdlq; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Mar 26, 2007, at 7:44 AM, Jonathan Rosenberg wrote: > rfc3489bis establishes a registry for attributes and methods but > not responses. We've had trouble with resposnes too, so I suggest a > registry for them also. Unless someone objects I'll add that to the > next revision. sounds good. > > I also suggest that having a working webpage like: > http://www.employees.org/behave/stun-attributes.html I would probably rather not do this - I would be very worried about creating shadow registries to IANA. Thought we have had examples of conflicts in drafts before, it has typically not been a problem in most IETF work. Right now there are non IANA defacto web page registries for some DNS stuff and that example has convinced me there are lots of problems with that path. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 04 19:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFNJ-00054p-Ki; Wed, 04 Apr 2007 19:58:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFNI-00054g-Iy for behave@ietf.org; Wed, 04 Apr 2007 19:58:48 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFNF-0002Ci-M4 for behave@ietf.org; Wed, 04 Apr 2007 19:58:48 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2007 16:58:45 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l34Nwieg023914; Wed, 4 Apr 2007 16:58:44 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l34Nwiwo022674; Wed, 4 Apr 2007 23:58:44 GMT In-Reply-To: <620620.70588.qm@web33305.mail.mud.yahoo.com> References: <620620.70588.qm@web33305.mail.mud.yahoo.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] draft-ietf-behave-nat-icmp-03.txt Date: Wed, 4 Apr 2007 09:57:29 -0700 To: Pyda Srisuresh X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1225; t=1175731125; x=1176595125; c=relaxed/simple; s=sjdkim8002; 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]=20draft-ietf-behave-nat-icmp-03.txt |Sender:=20; bh=EYcwWf5AjeHC3sIOqDq5t0dIuVDDgFzzuPyYAnYDidI=; b=f/7o0mONCSgy5qbvX+NdggKbaZDUiUwop6TwP2F0B/jP4MiL9DdHT4uwABmUal0Aa47BaoTa 9Nf5d0l2Kebu6NpVurC4pjdGglpWIZsIOKrxI0uCL15khAmtPAeUbg6B; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Apr 1, 2007, at 4:54 PM, Pyda Srisuresh wrote: > [suresh] Cullen - With the excpetion of UDP document, it has been > the consensus > of the WG to include ICMP requirements in the ICMP document. What you are saying here is not what I was saying and also not my understanding of what the group agreed with it's ADs on. It is true the ICMP document has requirements related to ICMP - however, the requirements about what ICMP needs to do for protocol X, need to be in the protocol X document. Part of the reason the WG went down this path was that if we make ICMP include what is needed for all protocols, it is very hard to know when we can call the ICMP document done. Another reason has to do with the point that the NAT will need to implement the ICMP handling for, say SCTP, when the NAT implements SCTP, not when the NAT developer implements UDP. Another reason had to with he expertise to review the ICMP for protocol X was probably best to review the ICMP for protocol X at the same time as the behave document for protocol X. I don't think anything is changing here - this is roughly my understanding from awhile back. Cullen < with my individual hat on> _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave ) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFNI-00054g-Iy for behave@ietf.org; Wed, 04 Apr 2007 19:58:48 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFNF-0002Ci-M4 for behave@ietf.org; Wed, 04 Apr 2007 19:58:48 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2007 16:58:45 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l34Nwieg023914; Wed, 4 Apr 2007 16:58:44 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l34Nwiwo022674; Wed, 4 Apr 2007 23:58:44 GMT In-Reply-To: <620620.70588.qm@web33305.mail.mud.yahoo.com> References: <620620.70588.qm@web33305.mail.mud.yahoo.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] draft-ietf-behave-nat-icmp-03.txt Date: Wed, 4 Apr 2007 09:57:29 -0700 To: Pyda Srisuresh X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1225; t=1175731125; x=1176595125; c=relaxed/simple; s=sjdkim8002; 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]=20draft-ietf-behave-nat-icmp-03.txt |Sender:=20; bh=EYcwWf5AjeHC3sIOqDq5t0dIuVDDgFzzuPyYAnYDidI=; b=f/7o0mONCSgy5qbvX+NdggKbaZDUiUwop6TwP2F0B/jP4MiL9DdHT4uwABmUal0Aa47BaoTa 9Nf5d0l2Kebu6NpVurC4pjdGglpWIZsIOKrxI0uCL15khAmtPAeUbg6B; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Apr 1, 2007, at 4:54 PM, Pyda Srisuresh wrote: > [suresh] Cullen - With the excpetion of UDP document, it has been > the consensus > of the WG to include ICMP requirements in the ICMP document. What you are saying here is not what I was saying and also not my understanding of what the group agreed with it's ADs on. It is true the ICMP document has requirements related to ICMP - however, the requirements about what ICMP needs to do for protocol X, need to be in the protocol X document. Part of the reason the WG went down this path was that if we make ICMP include what is needed for all protocols, it is very hard to know when we can call the ICMP document done. Another reason has to do with the point that the NAT will need to implement the ICMP handling for, say SCTP, when the NAT implements SCTP, not when the NAT developer implements UDP. Another reason had to with he expertise to review the ICMP for protocol X was probably best to review the ICMP for protocol X at the same time as the behave document for protocol X. I don't think anything is changing here - this is roughly my understanding from awhile back. Cullen < with my individual hat on> _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 04 20:41: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 1HZG29-0007Ci-RL; Wed, 04 Apr 2007 20:41:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZG28-0007C2-RY for behave@ietf.org; Wed, 04 Apr 2007 20:41:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZG27-0006RK-HL for behave@ietf.org; Wed, 04 Apr 2007 20:41:00 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2007 17:40:57 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l350euH5000561; Wed, 4 Apr 2007 17:40:56 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l350etA8003906; Thu, 5 Apr 2007 00:40:56 GMT From: "Dan Wing" To: , , "'Senthil Sivakumar \(ssenthil\)'" , "'Saikat Guha'" Date: Wed, 4 Apr 2007 17:40:55 -0700 Message-ID: <3a0701c7771b$12c5be40$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd3GxIfic8LrAE/S8SA58KEKM1+Rg== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2908; t=1175733656; x=1176597656; c=relaxed/simple; s=sjdkim7002; 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:=20NAT-ICMP=20summary |Sender:=20; bh=JsTAEeFpecqeAXC96onxKfqLLUXRWQV0cfXRxDO+w0o=; b=Td1lK1Lm3ZTarLzyqLEsR++9RhLpEm+oq19hSZPnnzyaVsNKbfQaZeWReEFGn4YvG/ElkdVW o1g9S3TsHDzG7I+/IThy+dQ+BRbfwbJtIPp089BhD81b6eQ6kTl1GhWo; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: behave@ietf.org Subject: [BEHAVE] NAT-ICMP summary 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 just returned from a 10-day vacation and caught up on the nat-icmp thread. To summarize the discussion it seems most of the concern is around some MUSTs in the existing document. What seems needed is "If the device's policy permits doing ___, then do it this way". So I have made proposed changes to three of the requirements in nat-icmp. Please read these and comment back to the list. --- 1. Change to Req-1: OLD: REQ-1: A NAT device MUST permit ICMP query based applications to be initiated from private hosts to the external hosts. NEW: REQ-1: A NAT device SHOULD permit ICMP query based applications to ^^^^^^ be initiated from private hosts to the external hosts. --- 2. Change to Req-4: OLD: REQ-4: If a NAT device receives an ICMP error packet from external realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP error packet. If the the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet. NEW: REQ-4: If a NAT device receives an ICMP error packet from external realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP error packet. If the the NAT has active mapping for the embedded payload, and local policy permits, then the ^^^^^^^^^^^^^^^^^^^^^^^^^ NAT MUST do the following prior to forwarding the packet. --- 3. Change to Req-5: OLD: REQ-5: If a NAT device receives an ICMP error packet from private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP error packet. If the the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet. NEW: REQ-5: If a NAT device receives an ICMP error packet from private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP error packet. If the the NAT has active mapping for the embedded payload, and local policy permits, then the ^^^^^^^^^^^^^^^^^^^^^^^^^ NAT MUST do the following prior to forwarding the packet. --- 4. The Security Considerations section should be amended to briefly discuss what was intended by 'local policy'. I suggest: NEW: Unfortunately, ICMP messages are sometimes blocked at network boundaries due to local security policy. Thus, some of the requirements in this document allow local policy to override the recommendations of this document. Blocking such ICMP messages is known to break some protocol features (most notably Path MTU Discovery) and some applications (e.g., ping, traceroute), and such blocking is NOT RECOMMENDED. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 04 20:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGF7-0001lr-9a; Wed, 04 Apr 2007 20:54:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGF5-0001ig-7S for behave@ietf.org; Wed, 04 Apr 2007 20:54:23 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZGF0-0007jr-OT for behave@ietf.org; Wed, 04 Apr 2007 20:54:23 -0400 Received: from Quinthar ([201.140.188.144]) by quinthar.com for ; Wed, 4 Apr 2007 17:54:13 -0700 From: "David Barrett" To: "'Dan Wing'" , , , "'Senthil Sivakumar \(ssenthil\)'" , "'Saikat Guha'" Subject: RE: [BEHAVE] NAT-ICMP summary Date: Wed, 4 Apr 2007 19:54:03 -0500 Message-ID: <004b01c7771c$ec406020$6401a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd3GxIfic8LrAE/S8SA58KEKM1+RgAAdKkg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <3a0701c7771b$12c5be40$c4f0200a@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 This sounds really good. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, April 04, 2007 7:41 PM > To: srisuresh@yahoo.com; baford@mit.edu; 'Senthil Sivakumar (ssenthil)'; > 'Saikat Guha' > Cc: behave@ietf.org > Subject: [BEHAVE] NAT-ICMP summary > > I just returned from a 10-day vacation and caught up on the nat-icmp > thread. > To summarize the discussion it seems most of the concern is around some > MUSTs in the existing document. What seems needed is "If the device's > policy permits doing ___, then do it this way". So I have made proposed > changes to three of the requirements in nat-icmp. Please read these and > comment back to the list. > > --- > 1. Change to Req-1: > > OLD: > REQ-1: A NAT device MUST permit ICMP query based applications to > be initiated from private hosts to the external hosts. > > NEW: > REQ-1: A NAT device SHOULD permit ICMP query based applications to > ^^^^^^ > be initiated from private hosts to the external hosts. > > > --- > 2. Change to Req-4: > > OLD: > REQ-4: If a NAT device receives an ICMP error packet from external > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If > the the NAT has active mapping for the embedded payload, then the > NAT MUST do the following prior to forwarding the packet. > > NEW: > REQ-4: If a NAT device receives an ICMP error packet from external > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If > the the NAT has active mapping for the embedded payload, > and local policy permits, then the > ^^^^^^^^^^^^^^^^^^^^^^^^^ > NAT MUST do the following prior to forwarding the packet. > > > --- > 3. Change to Req-5: > > OLD: > REQ-5: If a NAT device receives an ICMP error packet from private > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If > the the NAT has active mapping for the embedded payload, then the > NAT MUST do the following prior to forwarding the packet. > > NEW: > REQ-5: If a NAT device receives an ICMP error packet from private > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If > the the NAT has active mapping for the embedded payload, > and local policy permits, then the > ^^^^^^^^^^^^^^^^^^^^^^^^^ > NAT MUST do the following prior to forwarding the packet. > > > --- > 4. The Security Considerations section should be amended to briefly > discuss what was intended by 'local policy'. I suggest: > > NEW: > Unfortunately, ICMP messages are sometimes blocked at network > boundaries due to local security policy. Thus, some of the > requirements in this document allow local policy to override > the recommendations of this document. Blocking such ICMP > messages is known to break some protocol features (most notably > Path MTU Discovery) and some applications (e.g., ping, > traceroute), and such blocking is NOT RECOMMENDED. > > -d > > _______________________________________________ > 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 Apr 04 21:36: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 1HZGth-0000mf-DH; Wed, 04 Apr 2007 21:36:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGtf-0000ly-W4 for behave@ietf.org; Wed, 04 Apr 2007 21:36:19 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGtc-0003t0-LF for behave@ietf.org; Wed, 04 Apr 2007 21:36:19 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2007 18:36:16 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l351aGNf006667; Wed, 4 Apr 2007 18:36:16 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l351a2A8003945; Thu, 5 Apr 2007 01:36:02 GMT From: "Dan Wing" To: "'Jonathan Rosenberg'" Date: Wed, 4 Apr 2007 18:36:02 -0700 Message-ID: <3a2401c77722$cd207bc0$c4f0200a@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: <4607DA95.2030404@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdvtDzoaLAJDr5vQhiGDT6137o7WQHbnNXw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1191; t=1175736976; x=1176600976; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20claiming=20stun=20attributes=200x8029=20and=200x802a= 20for=20ICE |Sender:=20; bh=7oTLws8yC4iLISG47gV3ThBykLvQX+D3O2uh/L/6Njk=; b=DifsV3I7m9lWay2uKcw51pocG5JzEjlY2AcQ2XoczOiC4ckS7xEP6kUEd5jBN7X7P/KegJ3u 0201YQgDDVrJtE4FZUrTrlt3XEw9gq62Mkh3EoP5fH2Mu7tQqPiJeHA1; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'Rohan Mahy' , 'Gonzalo Camarillo' , "'Oscar Novo \(JO/LMF\)'" , behave@ietf.org Subject: [BEHAVE] RE: claiming stun attributes 0x8029 and 0x802a for ICE 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 Done; http://www.employees.org/behave/stun-attributes.html has been updated. -d > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Monday, March 26, 2007 7:37 AM > To: behave@ietf.org; Rohan Mahy; Derek MacDonald; Bruce > Lowekamp; Dan Wing; Gonzalo Camarillo; Oscar Novo (JO/LMF) > Subject: claiming stun attributes 0x8029 and 0x802a for ICE > > Per agreement during the Prague IETF in MMUSIC, I'm adding new > attributes to STUN for the connectivity check usage to support > collisions in controlling/controlled role. These will be: > > 0x8029 ICE-CONTROLLED > 0x802a ICE-CONTROLLING > > Dan, can you please add these to: > http://www.employees.org/behave/stun-attributes.html > > and authors of the other drafts, please do not use them. > > Thanks, > Jonathan R. > -- > 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 Apr 05 08:51:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRQ9-0001l0-Be; Thu, 05 Apr 2007 08:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRQ8-0001ku-Kl for behave@ietf.org; Thu, 05 Apr 2007 08:50:32 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZRQ7-0001VA-4f for behave@ietf.org; Thu, 05 Apr 2007 08:50:32 -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 l35CnfDg014460 for ; Thu, 5 Apr 2007 15:50:23 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 15:50:17 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 15:50:17 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 15:50:17 +0300 Received: from esdhcp04179.research.nokia.com (esdhcp04179.research.nokia.com [172.21.41.79]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l35CoD2b012770 for ; Thu, 5 Apr 2007 15:50:16 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Thu, 5 Apr 2007 15:50:27 +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: <200704051550.27366.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 05 Apr 2007 12:50:17.0543 (UTC) FILETIME=[F651E570:01C77780] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [BEHAVE] STUN IPv4/IPv6 considerations for ALTERNATE-SERVER 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, draft-ietf-behave-rfc3489bis-06 currently makes it explicit that a client m= ust=20 NOT assume that its mapped address is of the same address family than the o= ne=20 it is using to contact the server. In that context, how should a server fill the ALTERNATE-SERVER option if it= =20 needs to? or rather, how should a client handle an ALTERNATE-SERVER option = in=20 a family that does not match it was using (and might not even be able to us= e=20 at all) ? =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 Apr 05 14:07: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 1HZWMr-0001bG-WF; Thu, 05 Apr 2007 14:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWMq-0001b8-J8; Thu, 05 Apr 2007 14:07:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWMn-0003oM-Ur; Thu, 05 Apr 2007 14:07:28 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2007 11:07:25 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l35I7PkO026019; Thu, 5 Apr 2007 11:07:25 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l35I7Own023694; Thu, 5 Apr 2007 18:07:24 GMT From: "Dan Wing" To: , Date: Thu, 5 Apr 2007 11:07:24 -0700 Message-ID: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: Acd3rUMBGcI0xNRnTP+Fkd1y4lbzTQ== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1425; t=1175796445; x=1176660445; c=relaxed/simple; s=sjdkim5002; 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:=20icmp=20type=203,=20code=2013 |Sender:=20; bh=o9VvQWx4GBNA8CyaJHcacRh3TWkbAgc9x750I2z8vYw=; b=o+7GF4xrMpIZJu6eL/AOCncTx3uhcTUbkx3XAY7u8iZlPJPDTa7ADvq2qwgBSWbqxkpiGnWB 6+Q0le4TlxwxbHR9JXm0dk/IMWbsY3IoDOba/j+3r8XYj2y1miOVSLJq; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Faisal Siyavudeen Subject: [BEHAVE] icmp type 3, code 13 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 section 6 of draft-ietf-behave-nat-icmp-03, it is recommended to use ICMP type 3, code 13 to indicate an administratively-prohibited flow. ICMP type 3, code 13 was originally specified in RFC1812: "... 13 = Communication Administratively Prohibited - generated if a router cannot forward a packet due to administrative filtering; ... Routers SHOULD use the newly defined Code 13 (Communication Administratively Prohibited) if they administratively filter packets. Routers MAY have a configuration option that causes Code 13 (Communication Administratively Prohibited) messages not to be generated. When this option is enabled, no ICMP error message is sent in response to a packet that is dropped because its forwarding is administratively prohibited. ..." For the purposes of draft-ietf-behave-nat-icmp, ICMP type 3, code 13 needs to be considered a hard error. However, I am unable to find a reference indicating if ICMP type 3, code 13 is considered a hard error or soft error. Is there such a reference? I doubt existing stacks consider it a hard error, though, as code 13 is not on RFC1122's list of hard errors (which makes sense, as RFC1122 predates RFC1812's publication). (The use of Code 13 was originally my suggestion, but perhaps it is ill-suited if it hasn't been interpreted as a hard error since RFC1812's publication.) -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 05 14:28: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 1HZWgb-0005DV-4W; Thu, 05 Apr 2007 14:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWgY-0005C2-Ej; Thu, 05 Apr 2007 14:27:51 -0400 Received: from dns2-ana.paetec.net ([66.251.33.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWgW-0007U5-Up; Thu, 05 Apr 2007 14:27:50 -0400 Received: from [127.0.0.1] ([63.139.31.103]) by dns2-ana.paetec.net (8.13.6/8.13.6) with ESMTP id l35IRYBC004807; Thu, 5 Apr 2007 14:27:41 -0400 (EDT) Message-ID: <46153F88.3000703@isi.edu> Date: Thu, 05 Apr 2007 11:27:20 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Dan Wing References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> In-Reply-To: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> X-Enigmail-Version: 0.94.1.2.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tcpm@ietf.org, behave@ietf.org, Faisal Siyavudeen Subject: [BEHAVE] Re: [tcpm] icmp type 3, code 13 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="===============0871071103==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0871071103== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF406B0C2508A9DCDF19BCE54" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF406B0C2508A9DCDF19BCE54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, Dan Wing wrote: > In section 6 of draft-ietf-behave-nat-icmp-03, it is recommended to use= ICMP > type 3, code 13 to indicate an administratively-prohibited flow. ICMP = type > 3, code 13 was originally specified in RFC1812: >=20 > "... > 13 =3D Communication Administratively Prohibited - generated if a > router cannot forward a packet due to administrative filtering;= > ... > Routers SHOULD use the newly defined > Code 13 (Communication Administratively Prohibited) if they > administratively filter packets. >=20 > Routers MAY have a configuration option that causes Code 13 > (Communication Administratively Prohibited) messages not to be > generated. When this option is enabled, no ICMP error message is > sent in response to a packet that is dropped because its forwarding > is administratively prohibited. > ..." >=20 > For the purposes of draft-ietf-behave-nat-icmp, ICMP type 3, code 13 ne= eds > to be considered a hard error. However, I am unable to find a referenc= e > indicating if ICMP type 3, code 13 is considered a hard error or soft e= rror. > Is there such a reference? I doubt existing stacks consider it a hard > error, though, as code 13 is not on RFC1122's list of hard errors (whic= h > makes sense, as RFC1122 predates RFC1812's publication). >=20 > (The use of Code 13 was originally my suggestion, but perhaps it is > ill-suited if it hasn't been interpreted as a hard error since RFC1812'= s > publication.) I don't see a place where type 3 code 13 is defined in terms of host behavior. I don't know if you can or should require hard or soft error response to this code. Code 10 - communication with destination host administratively prohibited - is similar in spirit (it's a "won't" rather than a "can't"), and 1122 doesn't require either a hard or soft error on that one. IMO, it's up to the host to decide how to handle that error, just like 12, and that seems reasonable. That said, why are you using code 13, vs code 10? This isn't really because of a router doing administrative filtering; IMO, code 10 is sufficient. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigF406B0C2508A9DCDF19BCE54 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFT+IE5f5cImnZrsRAkV5AJ4pqbWTx31SbZDkXxdBne/Yhjg6lwCfWs6B Dmj3SxHui3wWl3LRVyYJcVQ= =shJq -----END PGP SIGNATURE----- --------------enigF406B0C2508A9DCDF19BCE54-- --===============0871071103== 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 --===============0871071103==-- From behave-bounces@ietf.org Thu Apr 05 20:12: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 1HZc3I-0004br-L4; Thu, 05 Apr 2007 20:11:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZc3H-0004Yi-UX for behave@ietf.org; Thu, 05 Apr 2007 20:11:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZc3G-0005Tw-LA for behave@ietf.org; Thu, 05 Apr 2007 20:11:39 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2007 17:11:38 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l360BcRc017714; Thu, 5 Apr 2007 17:11:38 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l360BbA8009161; Fri, 6 Apr 2007 00:11:37 GMT From: "Dan Wing" To: Date: Thu, 5 Apr 2007 17:11:37 -0700 Message-ID: <071901c777e0$24f25770$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: Acd34CRTbVn1+AbJTXeEgDHklZ1HXg== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=240; t=1175818298; x=1176682298; c=relaxed/simple; s=sjdkim5002; 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=20minutes=20posted |Sender:=20; bh=2szVUFZ6ZWbFaCWAumG2nk0MdO22eSQuQIFwm6bzDWg=; b=vs+znJfMUcN4Tu2VEX3RYpI9WqOHUghteLlQy4K+SjXacpGLTUl2zKWFISQIiel0adGaqOOq TST9WZGSCgHg6I14rhJaCw27+ZNwm+hqaS0BRrxoXsK2pyET29T6sJaj; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [BEHAVE] draft minutes posted 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 A draft version of the minutes is now available at http://www3.ietf.org/proceedings/07mar/minutes/behave.txt Please send me any corrections well before the cutoff (May 9). Thanks to Eric for taking minutes at the meeting. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 09 00:45: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 1HalkQ-0003Mx-Eu; Mon, 09 Apr 2007 00:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HalkP-0003Mm-7F for behave@ietf.org; Mon, 09 Apr 2007 00:44:57 -0400 Received: from web33305.mail.mud.yahoo.com ([68.142.206.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HalkL-0007OF-S3 for behave@ietf.org; Mon, 09 Apr 2007 00:44:57 -0400 Received: (qmail 1775 invoked by uid 60001); 9 Apr 2007 04:44:53 -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=eUwoutWoDiAxqqzSVDb8AWJJ7kHiCWgFIfPruliWfYUlVs6RD7I9juf8OIC+15/pfXJVq/K0rcl9CKNDYS70uYP+vsuJhdwjzU7omXwAzKmGJ0BFkVAwRS2s+hytWsPi9SHh6jRqVk9ggxIgh6cX3jNcb+K7Va24J4GNEMAgZZk=; X-YMail-OSG: JjWcTREVM1l3Kg8te12LEzQBAUMeZO4z8m41iZEc_N00c64vYq7EbctJYk31AYO02IludTTc_g-- Received: from [69.236.67.182] by web33305.mail.mud.yahoo.com via HTTP; Sun, 08 Apr 2007 21:44:53 PDT Date: Sun, 8 Apr 2007 21:44:53 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: Cullen Jennings In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <271144.1646.qm@web33305.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 --- Cullen Jennings wrote: > > On Apr 1, 2007, at 4:54 PM, Pyda Srisuresh wrote: > > > [suresh] Cullen - With the excpetion of UDP document, it has been > > the consensus > > of the WG to include ICMP requirements in the ICMP document. > > What you are saying here is not what I was saying and also not my > understanding of what the group agreed with it's ADs on. It is true > the ICMP document has requirements related to ICMP - however, the > requirements about what ICMP needs to do for protocol X, need to be > in the protocol X document. Part of the reason the WG went down this > path was that if we make ICMP include what is needed for all > protocols, it is very hard to know when we can call the ICMP > document done. Another reason has to do with the point that the NAT > will need to implement the ICMP handling for, say SCTP, when the NAT > implements SCTP, not when the NAT developer implements UDP. Another > reason had to with he expertise to review the ICMP for protocol X > was probably best to review the ICMP for protocol X at the same time > as the behave document for protocol X. > > I don't think anything is changing here - this is roughly my > understanding from awhile back. > [suresh] Right, the ICMP document will not include requirements on what needs done on NAT to react to ICMP messages for specific protocol X. We are on the same page. Thanks. regards, suresh > Cullen < with my individual hat on> _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 09 01:08:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ham6U-0005rh-FP; Mon, 09 Apr 2007 01:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ham6S-0005qe-Ds for behave@ietf.org; Mon, 09 Apr 2007 01:07:44 -0400 Received: from web33311.mail.mud.yahoo.com ([68.142.206.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ham6R-0002wN-12 for behave@ietf.org; Mon, 09 Apr 2007 01:07:44 -0400 Received: (qmail 12514 invoked by uid 60001); 9 Apr 2007 05:07:42 -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=XqiUs79au0cG2Hi61Rb35CFgK5XKXTXw1t4Y3dw1JH4P1oyUD1v5DEFoNSjrYspnkZVemHAIAm9+rbGoYsn78FynlAsF8dkkrufrVMt+5nuQ73sXeGEr3LK3TpxkDLP48KdCRRwBUHasg9ZB8FzsRaloPKVX8FzF29ZgF0LiJNg=; X-YMail-OSG: ZJ_gmgwVM1mh3Hejin3gZ__.Hpcqmy2MQzUFvBkIfZYNnBZX6WjMD.08THYfQmTqW85ESCNpSqnXwPG_Szsyq1BplF_k0A.aulmsiuhe.s97v4o- Received: from [69.236.67.182] by web33311.mail.mud.yahoo.com via HTTP; Sun, 08 Apr 2007 22:07:42 PDT Date: Sun, 8 Apr 2007 22:07:42 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: Dan Wing , 'Lars Eggert' , 'ext David Barrett' In-Reply-To: <379001c776fb$b4084c20$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <650750.10991.qm@web33311.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 I agree. regards, suresh --- Dan Wing wrote: > Lars Eggert wrote: > > > On 2007-4-2, at 18:15, ext David Barrett wrote: > > > My understanding is BEHAVE-compliance basically means "the protocols > > > supported on this device are correctly translated", and not > > > "applications > > > will work well with this gateway device". That latter > > > seems like a much bigger and more nebulous topic. > > > > > > So it still sounds like the two approaches are: > > > 1) Mandate all BEHAVE-compliant gateway devices support ICMP > > > 2) Recommend all BEHAVE-compliant gateway devices support ICMP > > > > We discussed another option, too: > > > > (3) Recommend that BEHAVE compliant devices that translate transport > > protocol X also translate ICMP messages Y and Z, because X's correct > > operation depends on them. > > > > (So, if your NAT translates TCP it should translate ICMP "packet too > > big", because otherwise you can run into blackholes. If it doesn't > > translate TCP, maybe it doesn't need to translate that ICMP message.) > > Yes, and that 3rd option is what our TCP document does. As a specific > example of this text, the TCP document says: > > ... > 7. Other Requirements Applicable to TCP > > A list of general and UDP specific NAT behavioral requirements are > described in [BEHAVE-UDP]. A list of ICMP specific NAT behavioral > requirements are described in [BEHAVE-ICMP]. The requirements listed > below reiterate the requirements from these two documents that > directly affect TCP. The following requirements do not relax any > requirements in [BEHAVE-UDP] or [BEHAVE-ICMP]. > ... > 7.3. ICMP Responses to TCP Packets > > ICMP responses are used by end-host TCP stacks for Path MTU Discovery > and for quick error detection. ICMP messages are rewritten by the > NAT (specifically the IP headers and the headers inside the ICMP > payload) and forwarded to the appropriate internal or external host. > Blocking any ICMP message is discouraged. > > REQ-9: Receipt of any sort of ICMP message MUST NOT terminate the > NAT mapping or TCP connection for which the ICMP was generated. > > Justification: This is necessary for reliably performing TCP > simultaneous-open where a remote NAT may temporarily signal an > ICMP error. It is also useful for MTU discovery. > ... > > Which has been the consensus of the working group. > > -d > > > I think that is similar what you describe here: > > > > > I still favor taking a protocol-by-protocol approach: if you > > > claim to support protocol X, here's the proper way to perform > > > NAT translation. > > > > It's just that the "proper way" may include translating some ICMP > > messages. > > > > > Remi -- As for the XP and Linux TCP stacks, you're saying > > > that when they > > > ramp their transmit window up to larger than the path MTU > > > they will *never* > > > recover without ICMP? They will never timeout and retry a > > > smaller packet? > > > > (1) TCP windows are unrelated to segment sizes. > > (2) There are _many_ end system stacks other than Linux and XP out > > there. > > (3) There are TCP implementation techniques (did you look at > > RFC2923?), but they are not standards recommendations. > > > > Lars > > > > > > > > _______________________________________________ > 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 Mon Apr 09 01:29: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 1HamQx-0001hU-0e; Mon, 09 Apr 2007 01:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HamQw-0001hM-7C for behave@ietf.org; Mon, 09 Apr 2007 01:28:54 -0400 Received: from web33304.mail.mud.yahoo.com ([68.142.206.119]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HamQu-0005f2-RI for behave@ietf.org; Mon, 09 Apr 2007 01:28:54 -0400 Received: (qmail 79619 invoked by uid 60001); 9 Apr 2007 05:28:52 -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=MczmBCjJcYR0eTQ5Xpzgip9ejjnyFNpSVP28+DrPjGTgisTA9UT4BrMn5Piwcu4egi2mG8lRcXI/H/dPv5nLAn+1ltQ54d4lPqGmNCHoXEzsZT76Q6YDu8YdF2EnpfZnAjCrRIhQBMqR/fX1N2iTN1UjDBXkRDljukrz8NUe31o=; X-YMail-OSG: QOYXgF4VM1ljIDhpB2IfHrecvVnjkA5rkjTmi_DhG6Z.NETmn2FjtoLviY1qJJ5ayXz8yw-- Received: from [69.236.67.182] by web33304.mail.mud.yahoo.com via HTTP; Sun, 08 Apr 2007 22:28:52 PDT Date: Sun, 8 Apr 2007 22:28:52 -0700 (PDT) From: Pyda Srisuresh To: Dan Wing , baford@mit.edu, "'Senthil Sivakumar \(ssenthil\)'" , 'Saikat Guha' In-Reply-To: <3a0701c7771b$12c5be40$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <313067.79348.qm@web33304.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: behave@ietf.org Subject: [BEHAVE] Re: NAT-ICMP summary 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, Please see my comments below. regards, suresh --- Dan Wing wrote: > I just returned from a 10-day vacation and caught up on the nat-icmp thread. > To summarize the discussion it seems most of the concern is around some > MUSTs in the existing document. What seems needed is "If the device's > policy permits doing ___, then do it this way". So I have made proposed > changes to three of the requirements in nat-icmp. Please read these and > comment back to the list. > > --- > 1. Change to Req-1: > > OLD: > REQ-1: A NAT device MUST permit ICMP query based applications to > be initiated from private hosts to the external hosts. > > NEW: > REQ-1: A NAT device SHOULD permit ICMP query based applications to > ^^^^^^ > be initiated from private hosts to the external hosts. > [suresh] Dan - I disagree with this change. NATs are supposed to permit outbound flows - TCP , UDP and ICMP. That some firewalls block query messages is not a reason to change the recommendation. Taking cue from your other changes below, perhaps, this could be reworded as follows. NEW': REQ-1: When local policy permits, a NAT device MUST permit ICMP query based applications to be initiated from private hosts to the external hosts. > > --- > 2. Change to Req-4: > > OLD: > REQ-4: If a NAT device receives an ICMP error packet from external > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If > the the NAT has active mapping for the embedded payload, then the > NAT MUST do the following prior to forwarding the packet. > > NEW: > REQ-4: If a NAT device receives an ICMP error packet from external > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If > the the NAT has active mapping for the embedded payload, > and local policy permits, then the > ^^^^^^^^^^^^^^^^^^^^^^^^^ > NAT MUST do the following prior to forwarding the packet. > [suresh] Once again, this seems directly influenced by firewall policies. However, given the caveat you state under security considerations section, I am OK with this. > > --- > 3. Change to Req-5: > > OLD: > REQ-5: If a NAT device receives an ICMP error packet from private > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If > the the NAT has active mapping for the embedded payload, then the > NAT MUST do the following prior to forwarding the packet. > > NEW: > REQ-5: If a NAT device receives an ICMP error packet from private > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If > the the NAT has active mapping for the embedded payload, > and local policy permits, then the > ^^^^^^^^^^^^^^^^^^^^^^^^^ > NAT MUST do the following prior to forwarding the packet. > [suresh] Same as above. > > --- > 4. The Security Considerations section should be amended to briefly > discuss what was intended by 'local policy'. I suggest: > > NEW: > Unfortunately, ICMP messages are sometimes blocked at network > boundaries due to local security policy. Thus, some of the > requirements in this document allow local policy to override > the recommendations of this document. Blocking such ICMP > messages is known to break some protocol features (most notably > Path MTU Discovery) and some applications (e.g., ping, > traceroute), and such blocking is NOT RECOMMENDED. > [suresh] This sounds good. Thanks. > -d > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 09 01:46: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 1Hamhz-0002qa-VA; Mon, 09 Apr 2007 01:46:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hamhy-0002qR-BH for behave@ietf.org; Mon, 09 Apr 2007 01:46:30 -0400 Received: from web33313.mail.mud.yahoo.com ([68.142.206.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hamhw-0007F0-Tw for behave@ietf.org; Mon, 09 Apr 2007 01:46:30 -0400 Received: (qmail 48931 invoked by uid 60001); 9 Apr 2007 05:46:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=V9IJJacPPhp0JRWOtUalTTRg+HqZ0P8rGSQ8fGRx0pjepmg4YfznblQWtGmXk2V1MkoAGihfnwBLMswip6rMmwn6MXsk/GsQps0UWPO9uAVJ2IFrwKmFb7Udfke31UNSqgL6Vl7zwThIdyH33b9mF8qXQpz8BTcS7zzNebhU7dk=; X-YMail-OSG: 1oWyob4VM1krpVCKzZpHJCQo.NWwGvQh_EFvFNbmQ_ZU2OZuiAOG6LYzdioBPP_o7cnBqfs1huU5DerY.PV4VWkRWTYi7fVLAVeh_NIdmvs8_Ss- Received: from [69.236.67.182] by web33313.mail.mud.yahoo.com via HTTP; Sun, 08 Apr 2007 22:46:28 PDT Date: Sun, 8 Apr 2007 22:46:28 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: David Barrett , "'Rémi" Denis-Courmont' , behave@ietf.org In-Reply-To: <016601c77539$e4aa2510$6b01a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <586566.48645.qm@web33313.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 David, Please see my comments inline. regards, suresh --- David Barrett wrote: <... stuff deleted> > Pyda -- As for RFC1812 mandating ICMP, that's great. Then there's no reason > to re-mandate it here. If BEHAVE says "if you support ICMP, do X", and if > everyone is compliant with RFC1812, then everyone will "do X". But if > someone doesn't support ICMP, then they're not compliant with RFC1812, which > seems like a bigger deal than whether or not they comply with BEHAVE. [suresh] Dave - Not all NAT devices confirm to RFC1812 requirements. For example, take the case of honoring the DF bit in an IP header. If the DF bit is set on a packet and NAT cannot forward the packet without packet fragmentation, the NAT MUST send "packet too big (3/4)" message back to sender. Not all NATs do this. Hence the reason to mandate RFC1812 in this document. > Alternatively, let's say for whatever reason RFC1812 were changed to no > longer require ICMP. Should BEHAVE supersede that decision and still > require it? Why the redundancy? [suresh] Firstly, RFC1812 will remain unchanged. However, there may be another RFC that obsoletes/updates RFC1812. In the hypothetical case you have a new RFC1812' that does not mandate ICMP, there may be another hypothetical new ICMP doc as well. regards, suresh > > -david > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > > Sent: Monday, April 02, 2007 8:06 AM > > To: Rémi Denis-Courmont; ext David Barrett; behave@ietf.org > > Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt > > > > > > --- Rémi Denis-Courmont wrote: > > > > > On Monday 02 April 2007 09:57:04 you wrote: > > > > > Not at all. TCP does not work at all without ICMP. Because of this, > > most > > > > > NAT > > > > > boxes have to do MSS clamping to fix it (in the same scenario as > > above). > > > > > Otherwise, you get your three-way handshake fine, and then the > > connection > > > > > breaks as soon as you send too large a data packet. > > > > > > > > Again, that's a very absolute statement that I'm pretty sure is wrong. > > TCP > > > > *can* function without ICMP. It might require some extra work, extra > > > > delays, and extra headaches. But it can and does work every day. > > > > > > Sure, if you the smallest MTU in the path in on the first hop, it works > > just > > > fine. Otherwise, it times out lamely as soon as the outpout buffer gets > > > bigger than the path MTU, and the TCP stacks keeps retrying to transmit > > a > > > packet that gets silently dropped (using widespread TCP stacks such as > > > Windows XP and Linux). > > > > > [suresh] Exactly. The point is not so much as whether TCP protocol is > > theoretically resilient to ICMP support in the network. The point, as Remi > > says, is that applications fail without it. > > > > > > I agree BEHAVE should specify how ICMP should be supported, if it's to > > be > > > > supported. But I disagree it should mandate ICMP be supported, > > anymore > > > > than it should mandate UPnP be supported merely because "it makes > > things > > > > work better". > > > > > > It makes some things work at all, which is very different. > > > > > > > [suresh] Right. > > > > David - RFC1812 mandates routers to generate, interpret and forward ICMP > > error > > messages. It is manadatory for a router to support ICMP error messages. > > Why do > > you believe ICMP support is not mandatory for a NAT device, whose > > principal > > functionality is routing between private and public realms? > > > > regards, > > suresh > > > > > > > -- > > > Rémi 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 Mon Apr 09 03:12: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 1Hao34-0005t7-Vg; Mon, 09 Apr 2007 03:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hao34-0005r4-C2 for behave@ietf.org; Mon, 09 Apr 2007 03:12:22 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hao30-0002BR-2f for behave@ietf.org; Mon, 09 Apr 2007 03:12:22 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 9 Apr 2007 00:12:17 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.25; Mon, 9 Apr 2007 00:12:17 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Apr 2007 00:12:16 -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 Date: Mon, 9 Apr 2007 00:12:11 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064042A9952@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <586566.48645.qm@web33313.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Microsoft releases IGD/NAT testing tool Thread-Index: Acd6apii/c14RcIXR26UYzP9ua7iwgACtx+Q References: <016601c77539$e4aa2510$6b01a8c0@Quinthar> <586566.48645.qm@web33313.mail.mud.yahoo.com> From: Christian Huitema To: X-OriginalArrivalTime: 09 Apr 2007 07:12:17.0074 (UTC) FILETIME=[67DEE920:01C77A76] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [BEHAVE] Microsoft releases IGD/NAT testing tool 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 Microsoft just released a tool that may be interesting for this list: http://www.microsoft.com/windows/using/tools/igd/default.mspx The tool applies various tests against routers to check how they implement NAT, UPNP, or support of various TCP options. It is based on Microsoft's "home networking" requirements for XP and Vista. Arguably, a later version could implement BEHAVE's requirement, when they are published by the IETF. -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 09 12:52:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hax6F-0006Pa-C0; Mon, 09 Apr 2007 12:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hax6D-0006PD-VN for behave@ietf.org; Mon, 09 Apr 2007 12:52:13 -0400 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hax6C-0006Oy-L5 for behave@ietf.org; Mon, 09 Apr 2007 12:52:13 -0400 Received: from cm-84.209.225.083.chello.no ([84.209.225.83] helo=[10.0.0.8]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1Hax6A-0007uE-7f for behave@ietf.org; Mon, 09 Apr 2007 16:52:10 +0000 Message-ID: <461A6F8F.9060905@db.org> Date: Mon, 09 Apr 2007 18:53:35 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [BEHAVE] Comments on turn-ipv6 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 Comments on draft-ietf-behave-turn-ipv6-01.txt this spec mainly defines one new STUN attribute (REQUESTED-ADDRESS-TYPE) and one new STUN response code (440 Address Family not Supported). I would like to suggest that this spec could be merged into the main TURN spec (turn-03). Is there any reason why we need to publish this as a separate document? Section 4.1 Allocating a Binding The length is specified to be 8 bytes. I think this should be 4 bytes, as a STUN attribute specifies the number of bytes in the attribute *payload* excluding the 4 bytes in the STUN attribute. /alfred _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 10 03:22:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbAfh-00026W-2J; Tue, 10 Apr 2007 03:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbAfe-00024K-Tu; Tue, 10 Apr 2007 03:21:42 -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 1HbAfe-0003r4-Et; Tue, 10 Apr 2007 03:21:42 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l3A7LHsN001738; Tue, 10 Apr 2007 10:21:17 +0300 Date: Tue, 10 Apr 2007 10:21:17 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <46153F88.3000703@isi.edu> Message-ID: References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/3058/Mon Apr 9 22:45:50 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org, behave@ietf.org, Faisal Siyavudeen , Dan Wing Subject: [BEHAVE] Re: [tcpm] icmp type 3, code 13 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 Thu, 5 Apr 2007, Joe Touch wrote: ... > I don't know if you can or should require hard or soft error response to > this code. Code 10 - communication with destination host > administratively prohibited - is similar in spirit (it's a "won't" > rather than a "can't"), and 1122 doesn't require either a hard or soft > error on that one. > > IMO, it's up to the host to decide how to handle that error, just like > 12, and that seems reasonable. > > That said, why are you using code 13, vs code 10? This isn't really > because of a router doing administrative filtering; IMO, code 10 is > sufficient. 10 is: 10 Communication with Destination Host is Administratively Prohibited while 13 is: 13 Communication Administratively Prohibited [RFC1812] '10' seems to (at least more strongly) imply that all communication with the destination address is administratively prohibited. 13 is less specific; the same code applies even if you filtered the whole network, just one host, or only one port of a host. -- 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 Tue Apr 10 11: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 1HbI6g-00074w-D0; Tue, 10 Apr 2007 11:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbI6f-00074h-H2; Tue, 10 Apr 2007 11:18:05 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbI6Y-0000ci-F9; Tue, 10 Apr 2007 11:18:05 -0400 Received: from webmail.isi.edu (webmail.isi.edu [128.9.152.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3AFHU49012570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Apr 2007 08:17:30 -0700 (PDT) Received: (from apache@localhost) by webmail.isi.edu (8.12.8/8.12.7) id l3AFHT1o023747; Tue, 10 Apr 2007 08:17:29 -0700 X-Authentication-Warning: webmail.isi.edu: apache set sender to touch@isi.edu using -f Received: from 166.21.12.193 ([166.21.12.193]) by webmail.isi.edu (IMP) with HTTP for ; Tue, 10 Apr 2007 08:17:29 -0700 Message-ID: <1176218249.461baa89926f4@webmail.isi.edu> Date: Tue, 10 Apr 2007 08:17:29 -0700 From: touch@ISI.EDU To: Pekka Savola References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 166.21.12.193 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org, behave@ietf.org, Faisal Siyavudeen , Dan Wing Subject: [BEHAVE] Re: [tcpm] icmp type 3, code 13 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 Quoting Pekka Savola : > On Thu, 5 Apr 2007, Joe Touch wrote: > ... > > I don't know if you can or should require hard or soft error response to > > this code. Code 10 - communication with destination host > > administratively prohibited - is similar in spirit (it's a "won't" > > rather than a "can't"), and 1122 doesn't require either a hard or soft > > error on that one. > > > > IMO, it's up to the host to decide how to handle that error, just like > > 12, and that seems reasonable. > > > > That said, why are you using code 13, vs code 10? This isn't really > > because of a router doing administrative filtering; IMO, code 10 is > > sufficient. > > 10 is: > > 10 Communication with Destination Host is > Administratively Prohibited > > while 13 is: > > 13 Communication Administratively Prohibited [RFC1812] > > '10' seems to (at least more strongly) imply that all communication > with the destination address is administratively prohibited. > > 13 is less specific; the same code applies even if you filtered the > whole network, just one host, or only one port of a host. If the entire network is filtered, 9 should be appropriate: 9 = communication with destination network administratively prohibited If a single port is filtered, a port-unreachable (code 3) should be generated. Administrative prohibition, as indicated in RFC1812, is based on policy: 13 = Communication Administratively Prohibited - generated if a router cannot forward a packet due to administrative filtering; I don't think NATs are considered filters per se, so 13 doesn't seem appropriate regardless. Joe _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 10 12:15: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 1HbJ0T-0000gk-SV; Tue, 10 Apr 2007 12:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJ0R-0000Rt-Ie; Tue, 10 Apr 2007 12:15:43 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJ0Q-0004p5-73; Tue, 10 Apr 2007 12:15:43 -0400 Received: from webmail.isi.edu (webmail.isi.edu [128.9.152.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3AGFC22027543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Apr 2007 09:15:12 -0700 (PDT) Received: (from apache@localhost) by webmail.isi.edu (8.12.8/8.12.7) id l3AGFC88024319; Tue, 10 Apr 2007 09:15:12 -0700 X-Authentication-Warning: webmail.isi.edu: apache set sender to touch@isi.edu using -f Received: from 166.21.12.193 ([166.21.12.193]) by webmail.isi.edu (IMP) with HTTP for ; Tue, 10 Apr 2007 09:15:12 -0700 Message-ID: <1176221712.461bb810b298a@webmail.isi.edu> Date: Tue, 10 Apr 2007 09:15:12 -0700 From: touch@ISI.EDU To: touch@ISI.EDU References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <1176218249.461baa89926f4@webmail.isi.edu> In-Reply-To: <1176218249.461baa89926f4@webmail.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 166.21.12.193 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Faisal Siyavudeen , tcpm@ietf.org, behave@ietf.org, Pekka Savola , Dan Wing Subject: [BEHAVE] Re: [tcpm] icmp type 3, code 13 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 Quoting touch@ISI.EDU: .. > > '10' seems to (at least more strongly) imply that all communication > > with the destination address is administratively prohibited. > > > > 13 is less specific; the same code applies even if you filtered the > > whole network, just one host, or only one port of a host. Let me be more specific: If you care that the source host acts with a hard error, you need to use an ICMP message that indicates that further attempts are not useful (codes 2-4). Other codes imply that there might be a change - e.g., administrative responses may differ later - and so should not be taken as a hard error. I disagree that 13 is less specific than 9 or 10; it's more specific, indicating that the reason for prohibition is filtering, vs. other administrative reasons. At the very least, draft-ietf-behave-nat-icmp-03.txt should be updated to indicate that 13 is used because of a *filter* based restriction. If this is not filter-based, then I think 9 or 10 is more appropriate. So, to get back to Dan's original issue and to summarize: - type 3 code 13 is NOT a hard error - nor, however, are corresponding type 3 codes 9 or 10 - if you want a hard error, use an existing one (safest) or define a new one with hard error behavior (IMO, more appropriate if that's your goal) - if we're talking about filtering, draft-ietf-behave-nat-icmp-03.txt needs to be updated where it discusses code 13 ICMP errors - if this isn't filtering, then code 9 or 10 should be used Joe _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 10 12:35: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 1HbJJ4-0002lC-TG; Tue, 10 Apr 2007 12:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJJ4-0002l2-Ar; Tue, 10 Apr 2007 12:34:58 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJIx-0007ih-DL; Tue, 10 Apr 2007 12:34:58 -0400 Received: from [127.0.0.1] (125.sub-75-209-178.myvzw.com [75.209.178.125]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3AGXwsN002001; Tue, 10 Apr 2007 09:34:03 -0700 (PDT) Message-ID: <461BBC60.6000906@isi.edu> Date: Tue, 10 Apr 2007 09:33:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Faisal Siyavudeen (fsiyavud)" References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" Subject: [BEHAVE] Re: [tcpm] icmp type 3, code 13 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="===============0448294649==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0448294649== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A18ADA2DB552AD487C8A716" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A18ADA2DB552AD487C8A716 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Faisal Siyavudeen (fsiyavud) wrote: > | '10' seems to (at least more strongly) imply that all=20 > | communication with the destination address is=20 > | administratively prohibited. >=20 > Does NAT administrative filtering referred to by > draft-ietf-behave-nat-icmp-03 cover filtering of application traffic > based on destination port? If yes, what error would be generated by a > NAT filtering out a certain type of application traffic to a certain se= t > of hosts? In that case, code 10 would not be the right one, as the host= > might still be reachable on a different port. I feel that the actual > choice of error code would vary - it could be code 10 or code 13 > depending on the type of filtering. I don't see that difference; code 10 just says administratively prohibited, and code 13 says administratively prohibited because of filtering. In either case, other ports could be reachable. Joe --------------enig0A18ADA2DB552AD487C8A716 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGG7xkE5f5cImnZrsRAj8RAKC2kTistK0upJx7a2Bjq3kFaEMbowCguhkF c+3qYg4PwSmSzIxF6++NUeQ= =E1a3 -----END PGP SIGNATURE----- --------------enig0A18ADA2DB552AD487C8A716-- --===============0448294649== 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 --===============0448294649==-- From behave-bounces@ietf.org Tue Apr 10 13:33: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 1HbKDC-0001Q7-3X; Tue, 10 Apr 2007 13:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKDA-0001Py-KA; Tue, 10 Apr 2007 13:32:56 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbKD6-0004G9-4T; Tue, 10 Apr 2007 13:32:56 -0400 Received: from [127.0.0.1] ([128.9.176.75]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3AHWAmM018076; Tue, 10 Apr 2007 10:32:15 -0700 (PDT) Message-ID: <461BCA0B.3010706@isi.edu> Date: Tue, 10 Apr 2007 10:31:55 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Faisal Siyavudeen (fsiyavud)" References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <461BBC60.6000906@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" Subject: [BEHAVE] Re: [tcpm] icmp type 3, code 13 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="===============0569860528==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0569860528== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2F3997FA8D0AA29E9075454C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F3997FA8D0AA29E9075454C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Faisal Siyavudeen (fsiyavud) wrote: > | > it could be code 10 or code 13 depending on the type of filtering. > |=20 > | I don't see that difference; code 10 just says=20 > | administratively prohibited, and code 13 says=20 > | administratively prohibited because of filtering. In either=20 > | case, other ports could be reachable. > |=20 >=20 > I agree. >=20 > I am sorry I was not clear - my point was that 10 cannot be used where > other ports on the hosts are still accessible, while 13 can be used in > any of these cases. BTW, the following note in RFC 1812 makes me wonder= > if NAT devices can send code 10 at all as they are more like routers: Uh, routers decrement the TTL. NATs do not. I don't think NATs behave like routers per se. > > Codes 9 and 10 were intended for use by end-to-end encryption devices > used by U.S military agencies. Routers SHOULD use the newly defined Cod= e > 13 (Communication Administratively Prohibited) if they administratively= > filter packets. > That argues that NATs should generate their own codes. This is NOT router administrative filtering either. Joe > | -----Original Message----- > | From: Joe Touch [mailto:touch@ISI.EDU]=20 > | Sent: Tuesday, April 10, 2007 10:04 PM > | To: Faisal Siyavudeen (fsiyavud) > | Cc: Pekka Savola; Dan Wing (dwing); tcpm@ietf.org;=20 > | behave@ietf.org; Mahesh Govind (mgovind) > | Subject: Re: [tcpm] icmp type 3, code 13 > |=20 > |=20 > |=20 > | Faisal Siyavudeen (fsiyavud) wrote: > | > | '10' seems to (at least more strongly) imply that all=20 > | communication=20 > | > | with the destination address is administratively prohibited. > | >=20 > | > Does NAT administrative filtering referred to by > | > draft-ietf-behave-nat-icmp-03 cover filtering of=20 > | application traffic=20 > | > based on destination port? If yes, what error would be=20 > | generated by a=20 > | > NAT filtering out a certain type of application traffic to=20 > | a certain=20 > | > set of hosts? In that case, code 10 would not be the right=20 > | one, as the=20 > | > host might still be reachable on a different port. I feel that the = > | > actual choice of error code would vary - it could be code=20 > | 10 or code=20 > | > 13 depending on the type of filtering. > |=20 > | I don't see that difference; code 10 just says=20 > | administratively prohibited, and code 13 says=20 > | administratively prohibited because of filtering. In either=20 > | case, other ports could be reachable. > |=20 > | Joe > |=20 > |=20 --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig2F3997FA8D0AA29E9075454C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGG8oME5f5cImnZrsRAquLAJ97Hl5DA3y+u5pQ1x+CSKLKPjbjgwCcCdqD CAKtAG6iY2F9kFhoBSALvB8= =YA8q -----END PGP SIGNATURE----- --------------enig2F3997FA8D0AA29E9075454C-- --===============0569860528== 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 --===============0569860528==-- From behave-bounces@ietf.org Tue Apr 10 13:55: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 1HbKYP-0003YQ-PH; Tue, 10 Apr 2007 13:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKYP-0003Wb-31; Tue, 10 Apr 2007 13:54:53 -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 1HbKYO-0000hJ-JV; Tue, 10 Apr 2007 13:54:53 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l3AHshQH015544; Tue, 10 Apr 2007 20:54:43 +0300 Date: Tue, 10 Apr 2007 20:54:43 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <461BCA0B.3010706@isi.edu> Message-ID: References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <461BBC60.6000906@isi.edu> <461BCA0B.3010706@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/3058/Mon Apr 9 22:45:50 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org, "Faisal Siyavudeen \(fsiyavud\)" , behave@ietf.org, "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" Subject: [BEHAVE] Re: [tcpm] icmp type 3, code 13 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, 10 Apr 2007, Joe Touch wrote: > Faisal Siyavudeen (fsiyavud) wrote: >> | > it could be code 10 or code 13 depending on the type of filtering. >> | >> | I don't see that difference; code 10 just says >> | administratively prohibited, and code 13 says >> | administratively prohibited because of filtering. In either >> | case, other ports could be reachable. >> | >> >> I agree. >> >> I am sorry I was not clear - my point was that 10 cannot be used where >> other ports on the hosts are still accessible, while 13 can be used in >> any of these cases. BTW, the following note in RFC 1812 makes me wonder >> if NAT devices can send code 10 at all as they are more like routers: > > Uh, routers decrement the TTL. NATs do not. I don't think NATs behave > like routers per se. YMMV but all NATs I have seen and used do decrement TTL. (I've heard reports about ones that don't, but never seen one myself.) I'd be interested in knowing in which conditions access to a network, host, or a subset of a host should be considered "administratively prohibited", but that administrative prohibition is not due to filtering (be it a firewall rule, access list, configuration toggle, or whatever). -- 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 Tue Apr 10 15:01:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLaL-0006Q8-49; Tue, 10 Apr 2007 15:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLaJ-0006Pz-VR; Tue, 10 Apr 2007 15:00:55 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbLaI-0001ss-Jo; Tue, 10 Apr 2007 15:00:55 -0400 Received: from [127.0.0.1] (125.sub-75-209-178.myvzw.com [75.209.178.125]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3AIxkjU010705; Tue, 10 Apr 2007 11:59:53 -0700 (PDT) Message-ID: <461BDE8E.9000307@isi.edu> Date: Tue, 10 Apr 2007 11:59:26 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pekka Savola References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <461BBC60.6000906@isi.edu> <461BCA0B.3010706@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tcpm@ietf.org, "Faisal Siyavudeen \(fsiyavud\)" , behave@ietf.org, "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" Subject: [BEHAVE] Re: [tcpm] icmp type 3, code 13 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="===============1779667327==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1779667327== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA98BF530091599C50B05215F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA98BF530091599C50B05215F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: =2E.. >> Uh, routers decrement the TTL. NATs do not. I don't think NATs behave >> like routers per se. >=20 > YMMV but all NATs I have seen and used do decrement TTL. (I've heard > reports about ones that don't, but never seen one myself.) One of the nasty things about NATs (or the people who design them) is that anything that makes them visible is likely to be disabled by some subset, in the hopes of making it 'transparent'. Although many NATs do decrement the TTL, there is no such requirement. RFC3022 (traditional NATs, informational) doesn't even mention it, and RFC2766 (NAT proposed standard) talks about setting TTL to 0 for DNS, but says specifically that TTLs are not decremented for statically mapped addresses (and has nothing to say about dynamic ones). Other docs (MIDCOM, arch implications of NATs) don't require TTL decrement either. > I'd be interested in knowing in which conditions access to a network, > host, or a subset of a host should be considered "administratively > prohibited", but that administrative prohibition is not due to filterin= g > (be it a firewall rule, access list, configuration toggle, or whatever)= =2E source address/reverse path validation comes to mind. Yes, it might be set with a toggle, but it's not what most people consider when then talk about packet filtering (at least IMO). IMO, because a NAT behaves like an endpoint (to the Internet side), it should send ICMPs like one, and issue ICMP host/port unreachables, not administrative filtering that routers would send. That would also 'do the right thing' by making the ICMPs result in hard errors. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigA98BF530091599C50B05215F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGG96OE5f5cImnZrsRAjPaAJ9CW78ReSSQimSicqAQISXnWXvl1gCeKst7 lBAUO0svufS+nvmIadJdFY4= =I6N+ -----END PGP SIGNATURE----- --------------enigA98BF530091599C50B05215F-- --===============1779667327== 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 --===============1779667327==-- From behave-bounces@ietf.org Wed Apr 11 11: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 1HbeYY-0007a5-Fw; Wed, 11 Apr 2007 11:16:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHHg-0007iA-CV; Tue, 10 Apr 2007 10:25:24 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHHe-0000rB-Pp; Tue, 10 Apr 2007 10:25:24 -0400 Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 11 Apr 2007 08:45:14 +0530 X-IronPort-AV: i="4.14,390,1170613800"; d="scan'208"; a="78160491:sNHT116431338" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3AEPKhY019349; Tue, 10 Apr 2007 19:55:20 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3AEPFEQ022857; Tue, 10 Apr 2007 14:25:18 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 19:55:14 +0530 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 Date: Tue, 10 Apr 2007 19:55:14 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] icmp type 3, code 13 Thread-Index: Acd7QOLql+D5V3OzTzyKSZUe8OFmkgANcn4A References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> From: "Faisal Siyavudeen \(fsiyavud\)" To: "Pekka Savola" , "Joe Touch" , "Dan Wing \(dwing\)" X-OriginalArrivalTime: 10 Apr 2007 14:25:14.0909 (UTC) FILETIME=[0E47B4D0:01C77B7C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2711; t=1176215120; x=1177079120; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fsiyavud@cisco.com; z=From:=20=22Faisal=20Siyavudeen=20\(fsiyavud\)=22=20 |Subject:=20RE=3A=20[tcpm]=20icmp=20type=203,=20code=2013 |Sender:=20; bh=QgnGUBiCHwAOk3c9va/ATbQswhIyA0XyYF8+I1Ir8ho=; b=wxJIhvYuREoOvMiSyFVAOQGD9ihslts0PB4w6e8LX34W1Fn65IlJ/xrEmk2pzvuhhm7daakB 8560RhgJJvJCDjhJ6MHKHZgYyrvT+/uPEoRUlZmDhTBgiol4Q/8YXuxT; Authentication-Results: ind-dkim-2; header.From=fsiyavud@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-Mailman-Approved-At: Wed, 11 Apr 2007 11:16:20 -0400 Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" Subject: [BEHAVE] RE: [tcpm] icmp type 3, code 13 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 | '10' seems to (at least more strongly) imply that all=20 | communication with the destination address is=20 | administratively prohibited. Does NAT administrative filtering referred to by draft-ietf-behave-nat-icmp-03 cover filtering of application traffic based on destination port? If yes, what error would be generated by a NAT filtering out a certain type of application traffic to a certain sFrom behave-bounces@ietf.org Wed Apr 11 11: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 1HbeYY-0007a5-Fw; Wed, 11 Apr 2007 11:16:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHHg-0007iA-CV; Tue, 10 Apr 2007 10:25:24 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHHe-0000rB-Pp; Tue, 10 Apr 2007 10:25:24 -0400 Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 11 Apr 2007 08:45:14 +0530 X-IronPort-AV: i="4.14,390,1170613800"; d="scan'208"; a="78160491:sNHT116431338" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3AEPKhY019349; Tue, 10 Apr 2007 19:55:20 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3AEPFEQ022857; Tue, 10 Apr 2007 14:25:18 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 19:55:14 +0530 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 Date: Tue, 10 Apr 2007 19:55:14 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] icmp type 3, code 13 Thread-Index: Acd7QOLql+D5V3OzTzyKSZUe8OFmkgANcn4A References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> From: "Faisal Siyavudeen \(fsiyavud\)" To: "Pekka Savola" , "Joe Touch" , "Dan Wing \(dwing\)" X-OriginalArrivalTime: 10 Apr 2007 14:25:14.0909 (UTC) FILETIME=[0E47B4D0:01C77B7C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2711; t=1176215120; x=1177079120; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fsiyavud@cisco.com; z=From:=20=22Faisal=20Siyavudeen=20\(fsiyavud\)=22=20 |Subject:=20RE=3A=20[tcpm]=20icmp=20type=203,=20code=2013 |Sender:=20; bh=QgnGUBiCHwAOk3c9va/ATbQswhIyA0XyYF8+I1Ir8ho=; b=wxJIhvYuREoOvMiSyFVAOQGD9ihslts0PB4w6e8LX34W1Fn65IlJ/xrEmk2pzvuhhm7daakB 8560RhgJJvJCDjhJ6MHKHZgYyrvT+/uPEoRUlZmDhTBgiol4Q/8YXuxT; Authentication-Results: ind-dkim-2; header.From=fsiyavud@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-Mailman-Approved-At: Wed, 11 Apr 2007 11:16:20 -0400 Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" Subject: [BEHAVE] RE: [tcpm] icmp type 3, code 13 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 | '10' seems to (at least more strongly) imply that all=20 | communication with the destination address is=20 | administratively prohibited. Does NAT administrative filtering referred to by draft-ietf-behave-nat-icmp-03 cover filtering of application traffic based on destination port? If yes, what error would be generated by a NAT filtering out a certain type of application traffic to a certain set of hosts? In that case, code 10 would not be the right one, as the host might still be reachable on a different port. I feel that the actual choice of error code would vary - it could be code 10 or code 13 depending on the type of filtering. What is the reason why we recommend NATs to generate a 'hard' ICMP error response? Is it to help hosts to stop generating traffic that would get dropped? It might not even be appropriate to send a hard error, as IP packets may take different routes, and a NAT in one route should not cause the entire flow to stop. rgds Faisal | -----Original Message----- | From: Pekka Savola [mailto:pekkas@netcore.fi]=20 | Sent: Tuesday, April 10, 2007 12:51 PM | To: Joe Touch | Cc: Dan Wing (dwing); tcpm@ietf.org; behave@ietf.org; Faisal=20 | Siyavudeen (fsiyavud) | Subject: Re: [tcpm] icmp type 3, code 13 |=20 | On Thu, 5 Apr 2007, Joe Touch wrote: | ... | > I don't know if you can or should require hard or soft=20 | error response=20 | > to this code. Code 10 - communication with destination host | > administratively prohibited - is similar in spirit (it's=20 | a "won't" | > rather than a "can't"), and 1122 doesn't require either a=20 | hard or soft=20 | > error on that one. | > | > IMO, it's up to the host to decide how to handle that=20 | error, just like=20 | > 12, and that seems reasonable. | > | > That said, why are you using code 13, vs code 10? This isn't really=20 | > because of a router doing administrative filtering; IMO, code 10 is=20 | > sufficient. |=20 | 10 is: |=20 | 10 Communication with Destination Host is | Administratively Prohibited |=20 | while 13 is: |=20 | 13 Communication Administratively Prohibited =20 | [RFC1812] |=20 | '10' seems to (at least more strongly) imply that all=20 | communication with the destination address is=20 | administratively prohibited. |=20 | 13 is less specific; the same code applies even if you=20 | filtered the whole network, just one host, or only one port of a host. |=20 | --=20 | Pekka Savola "You each name yourselves king, yet the | Netcore Oy kingdom bleeds." | Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings |=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 11 11: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 1HbeYZ-0007aB-80; Wed, 11 Apr 2007 11:16:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbK6l-000469-Qv; Tue, 10 Apr 2007 13:26:19 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbK6k-0002eH-8K; Tue, 10 Apr 2007 13:26:19 -0400 Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 11 Apr 2007 11:46:10 +0530 X-IronPort-AV: i="4.14,390,1170613800"; d="scan'208"; a="78167187:sNHT72131384" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3AHQDS0007976; Tue, 10 Apr 2007 22:56:13 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3AHQBEQ004837; Tue, 10 Apr 2007 17:26:12 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 22:56:10 +0530 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 Date: Tue, 10 Apr 2007 22:56:09 +0530 Message-ID: In-Reply-To: <461BBC60.6000906@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] icmpet of hosts? In that case, code 10 would not be the right one, as the host might still be reachable on a different port. I feel that the actual choice of error code would vary - it could be code 10 or code 13 depending on the type of filtering. What is the reason why we recommend NATs to generate a 'hard' ICMP error response? Is it to help hosts to stop generating traffic that would get dropped? It might not even be appropriate to send a hard error, as IP packets may take different routes, and a NAT in one route should not cause the entire flow to stop. rgds Faisal | -----Original Message----- | From: Pekka Savola [mailto:pekkas@netcore.fi]=20 | Sent: Tuesday, April 10, 2007 12:51 PM | To: Joe Touch | Cc: Dan Wing (dwing); tcpm@ietf.org; behave@ietf.org; Faisal=20 | Siyavudeen (fsiyavud) | Subject: Re: [tcpm] icmp type 3, code 13 |=20 | On Thu, 5 Apr 2007, Joe Touch wrote: | ... | > I don't know if you can or should require hard or soft=20 | error response=20 | > to this code. Code 10 - communication with destination host | > administratively prohibited - is similar in spirit (it's=20 | a "won't" | > rather than a "can't"), and 1122 doesn't require either a=20 | hard or soft=20 | > error on that one. | > | > IMO, it's up to the host to decide how to handle that=20 | error, just like=20 | > 12, and that seems reasonable. | > | > That said, why are you using code 13, vs code 10? This isn't really=20 | > because of a router doing administrative filtering; IMO, code 10 is=20 | > sufficient. |=20 | 10 is: |=20 | 10 Communication with Destination Host is | Administratively Prohibited |=20 | while 13 is: |=20 | 13 Communication Administratively Prohibited =20 | [RFC1812] |=20 | '10' seems to (at least more strongly) imply that all=20 | communication with the destination address is=20 | administratively prohibited. |=20 | 13 is less specific; the same code applies even if you=20 | filtered the whole network, just one host, or only one port of a host. |=20 | --=20 | Pekka Savola "You each name yourselves king, yet the | Netcore Oy kingdom bleeds." | Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings |=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 11 11: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 1HbeYZ-0007aB-80; Wed, 11 Apr 2007 11:16:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbK6l-000469-Qv; Tue, 10 Apr 2007 13:26:19 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbK6k-0002eH-8K; Tue, 10 Apr 2007 13:26:19 -0400 Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 11 Apr 2007 11:46:10 +0530 X-IronPort-AV: i="4.14,390,1170613800"; d="scan'208"; a="78167187:sNHT72131384" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3AHQDS0007976; Tue, 10 Apr 2007 22:56:13 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3AHQBEQ004837; Tue, 10 Apr 2007 17:26:12 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 22:56:10 +0530 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 Date: Tue, 10 Apr 2007 22:56:09 +0530 Message-ID: In-Reply-To: <461BBC60.6000906@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] icmp type 3, code 13 Thread-Index: Acd7jjPj27jZJwImSf66UHyBDxFXvAABHKFA References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <461BBC60.6000906@isi.edu> From: "Faisal Siyavudeen \(fsiyavud\)" To: "Joe Touch" X-OriginalArrivalTime: 10 Apr 2007 17:26:10.0734 (UTC) FILETIME=[54DB24E0:01C77B95] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2223; t=1176225973; x=1177089973; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fsiyavud@cisco.com; z=From:=20=22Faisal=20Siyavudeen=20\(fsiyavud\)=22=20 |Subject:=20RE=3A=20[tcpm]=20icmp=20type=203,=20code=2013 |Sender:=20; bh=XSDHQfUFq1/ZOwtVXCYmKtXQPEa2v3+g2CwIQ3y9PBI=; b=e8rNMNj314hKzEs3gKfrQf/NBlEdHJupsDY8Z4a7xlDdA8JQrFqZZq85033TBzxr9O+Ww5Jl 0eYVsthqh1hOg2a3zgpAelhtlVEuRpSDTk+NOjqnNvRmY0/fMYQxmIc5; Authentication-Results: ind-dkim-2; header.From=fsiyavud@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Wed, 11 Apr 2007 11:16:20 -0400 Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" Subject: [BEHAVE] RE: [tcpm] icmp type 3, code 13 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 | > it could be code 10 or code 13 depending on the type of filtering. |=20 | I don't see that difference; code 10 just says=20 | administratively prohibited, and code 13 says=20 | administratively prohibited because of filtering. In either=20 | case, other ports could be reachable. |=20 I agree. I am sorry I was not clear - my point was that 10 cannot be used where other ports on the hosts are still accessible, while 13 can be used in any of these cases. BTW, the following note in RFC 1812 makes me wonder if NAT devices can send code 10 at all as they are more like routers: Codes 9 and 10 were intended for use by end-to-end encryption devices used by U.S military agencies. Routers SHOULD use the newly defined Code 13 (Communication Administratively Prohibited) if they administratively filter packets. rgds Faisal | -----Original Message----- | From: Joe Touch [mailto:touch@ISI.EDU]=20 | Sent: Tuesday, April 10, 2007 10:04 PM | To: Faisal Siyavudeen (fsiyavud) | Cc: Pekka Savola; Dan Wing (dwing); tcpm@ietf.org;=20 | behave@ietf.org; Mahesh Govind (mgovind) | Subject: Re: [tcpm] icmp type 3, code 13 |=20 |=20 |=20 | Faisal Siyavudeen (fsiyavud) wrote: | > | '10' seems to (at least more strongly) imply that all=20 | communication=20 | > | with the destination address is administratively prohibited. | >=20 | > Does NAT administrative filtering referred to by | > draft-ietf-behave-nat-icmp-03 cover filtering of=20 | application traffic=20 | > based on destination port? If yes, what error would be=20 | generated by a=20 | > NAT filtering out a certain type of application traffic to=20 | a certain=20 | > set of hosts? In that case, code 10 would not be the right=20 | one, as the=20 | > host might still be reachable on a different port. I feel that the=20 | > actual choice of error code would vary - it could be code=20 | 10 or code=20 | > 13 depending on the type of filtering. |=20 | I don't see that difference; code 10 just says=20 | administratively prohibited, and code 13 says=20 | administrativ type 3, code 13 Thread-Index: Acd7jjPj27jZJwImSf66UHyBDxFXvAABHKFA References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <461BBC60.6000906@isi.edu> From: "Faisal Siyavudeen \(fsiyavud\)" To: "Joe Touch" X-OriginalArrivalTime: 10 Apr 2007 17:26:10.0734 (UTC) FILETIME=[54DB24E0:01C77B95] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2223; t=1176225973; x=1177089973; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fsiyavud@cisco.com; z=From:=20=22Faisal=20Siyavudeen=20\(fsiyavud\)=22=20 |Subject:=20RE=3A=20[tcpm]=20icmp=20type=203,=20code=2013 |Sender:=20; bh=XSDHQfUFq1/ZOwtVXCYmKtXQPEa2v3+g2CwIQ3y9PBI=; b=e8rNMNj314hKzEs3gKfrQf/NBlEdHJupsDY8Z4a7xlDdA8JQrFqZZq85033TBzxr9O+Ww5Jl 0eYVsthqh1hOg2a3zgpAelhtlVEuRpSDTk+NOjqnNvRmY0/fMYQxmIc5; Authentication-Results: ind-dkim-2; header.From=fsiyavud@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Wed, 11 Apr 2007 11:16:20 -0400 Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" Subject: [BEHAVE] RE: [tcpm] icmp type 3, code 13 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 | > it could be code 10 or code 13 depending on the type of filtering. |=20 | I don't see that difference; code 10 just says=20 | administratively prohibited, and code 13 says=20 | administratively prohibited because of filtering. In either=20 | case, other ports could be reachable. |=20 I agree. I am sorry I was not clear - my point was that 10 cannot be used where other ports on the hosts are still accessible, while 13 can be used in any of these cases. BTW, the following note in RFC 1812 makes me wonder if NAT devices can send code 10 at all as they are more like routers: Codes 9 and 10 were intended for use by end-to-end encryption devices used by U.S military agencies. Routers SHOULD use the newly defined Code 13 (Communication Administratively Prohibited) if they administratively filter packets. rgds Faisal | -----Original Message----- | From: Joe Touch [mailto:touch@ISI.EDU]=20 | Sent: Tuesday, April 10, 2007 10:04 PM | To: Faisal Siyavudeen (fsiyavud) | Cc: Pekka Savola; Dan Wing (dwing); tcpm@ietf.org;=20 | behave@ietf.org; Mahesh Govind (mgovind) | Subject: Re: [tcpm] icmp type 3, code 13 |=20 |=20 |=20 | Faisal Siyavudeen (fsiyavud) wrote: | > | '10' seems to (at least more strongly) imply that all=20 | communication=20 | > | with the destination address is administratively prohibited. | >=20 | > Does NAT administrative filtering referred to by | > draft-ietf-behave-nat-icmp-03 cover filtering of=20 | application traffic=20 | > based on destination port? If yes, what error would be=20 | generated by a=20 | > NAT filtering out a certain type of application traffic to=20 | a certain=20 | > set of hosts? In that case, code 10 would not be the right=20 | one, as the=20 | > host might still be reachable on a different port. I feel that the=20 | > actual choice of error code would vary - it could be code=20 | 10 or code=20 | > 13 depending on the type of filtering. |=20 | I don't see that difference; code 10 just says=20 | administratively prohibited, and code 13 says=20 | administratively prohibited because of filtering. In either=20 | case, other ports could be reachable. |=20 | Joe |=20 |=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave ely prohibited because of filtering. In either=20 | case, other ports could be reachable. |=20 | Joe |=20 |=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 11 20:42: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 1HbnOB-0004ig-Q0; Wed, 11 Apr 2007 20:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbnO9-0004hl-Ml for behave@ietf.org; Wed, 11 Apr 2007 20:42:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbnO7-0004j8-M9 for behave@ietf.org; Wed, 11 Apr 2007 20:42:13 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 11 Apr 2007 17:42:11 -0700 X-IronPort-AV: i="4.14,397,1170662400"; d="scan'208"; a="410502131:sNHT43160104" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3C0gBJc028222; Wed, 11 Apr 2007 17:42:11 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3C0gAwn002453; Thu, 12 Apr 2007 00:42:10 GMT From: "Dan Wing" To: Date: Wed, 11 Apr 2007 17:42:11 -0700 Message-ID: <037c01c77c9b$690b93d0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd8m2iA/njyH8DfQhuU/KqlrWe/aQ== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=732; t=1176338531; x=1177202531; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20removing=20application=20milestone |Sender:=20; bh=ZYyk7eTvH3+rWVHgXzeuO+LsAMg4CBZXFP4XICj53OE=; b=hcrE7blaG5/D5+j6NKK0xbdQx+cqQbVIIWG7BYSwwRzXTqj+/0ux2nzigUOPNtdb4AddpJgC O3IQcoRTK/vb4QYlCrnBnh36POMB6cpr7Wh/0K3XDW2n1xttWu0zlYYC; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: draft-ford-behave-app@tools.ietf.org Subject: [BEHAVE] removing application milestone 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 At the BEHAVE meeting in Prague there was strong consensus to remove the milestone: "Submit informational that discusses current NAT traversal techniques used by applications" from our charter, and to not adopt draft-ford-behave-app to meet that milestone. If the mailing list doesn't have a substantial disagreement with the consensus from the Prague meeting, I will remove that milestone from our charter. Also during the meeting there were some ideas around adding a new milestone for a document which might discuss when an application might choose UNSAF (STUN), Bonjour/UPnP, or other NAT traversal techniques. If a candidate document emerges we can consider creating such a milestone. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 12 08:43: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 1HbyeE-0004Vh-9S; Thu, 12 Apr 2007 08:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbyeD-0004Of-21 for behave@ietf.org; Thu, 12 Apr 2007 08:43:33 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbye9-0007mQ-8t for behave@ietf.org; Thu, 12 Apr 2007 08:43:33 -0400 Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3CChSjh027129; Thu, 12 Apr 2007 05:43:28 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 4BACF3044A; Thu, 12 Apr 2007 05:43:28 -0700 (PDT) X-AuditID: 11807125-a0320bb0000007e5-39-461e296f2de3 Received: from [17.219.197.61] (unknown [17.219.197.61]) by relay7.apple.com (Apple SCV relay) with ESMTP id CFDE130006; Thu, 12 Apr 2007 05:43:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: quoted-printable Message-Id: <11629D3E-E998-4E53-A48C-696388BFF72E@apple.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed To: IETF V6OPS WG , IETF BEHAVE WG From: james woodyatt Date: Thu, 12 Apr 2007 05:43:25 -0700 X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: Subject: [BEHAVE] common issues in BEHAVE and V6OPS 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 everyone-- An issue with the NAP draft in the V6OPS group arose recently, and =20 Christian Huitema suggested that the BEHAVE group is a better place =20 to hold the discussion about it. Having read the BEHAVE group's =20 charter and all of its documents, I'm not so sure he's right, so I'm =20 now posting this to both V6OPS and BEHAVE. Hopefully, the =20 distribution of the discussion will be narrower once everyone agrees =20 on the appropriate venue. For those who haven't been following the discussion in V6OPS, I =20 recommend beginning with my message here: Here's an edited version: > Today, Apple released the following article "About the security =20 > content of Firmware Update 7.1 for AirPort Extreme Base Station =20 > with 802.11n" > > > > Here's the relevant section: > >> CVE-ID: CVE-2007-1338 >> >> Available for: AirPort Extreme Base Station with 802.11n* >> >> Impact: AirPort Extreme Base Station with 802.11n* allows incoming =20= >> IPv6 connections >> >> Description: The default configuration of an AirPort Extreme Base =20 >> Station with 802.11n* allows incoming IPv6 connections. This may =20 >> expose network services on hosts connected through an AirPort =20 >> Extreme Base Station with 802.11n* to remote attackers. This =20 >> update addresses the issue by changing the default setting to =20 >> limit inbound IPv6 traffic to the local network. This issue only =20 >> affects AirPort Extreme Base Station with 802.11n*, and not other =20 >> versions of the Base Station. >> [...] > > [...] > One concern I've been asked to think about is that the product =20 > doesn't offer any mechanism for nodes on the local network to =20 > request the opening of a pinhole in the stateful packet filter. =20 > This function is performed in the IPv4 case by NAT-PMP (which Apple =20= > has tried to advance within IETF without much success), but there =20 > is no equivalent function for IPv6. This was a deliberate decision =20 > on our part, but now we're left reconsidering it. > [...] > As far as I know, there is no current or pending IETF standard for =20 > nodes to use in requesting open pinholes through the stateful =20 > packet filter in a residential IPv6 gateway. In light of the IETF =20 > consensus noted earlier in this thread, doesn't that seem like a =20 > serious oversight? Isn't this function something that rightfully =20 > belongs in ICMP6? If not, do we really think extending NAT-PMP and =20 > UPnP IGD to support IPv6 network boundary filters is a good idea? =20 > (A month ago, I would have found that hard to believe, but I've =20 > made some embarrassing mistakes lately, so I'm gun-shy about what I =20= > don't believe anymore.) > > Incidentally, for those interested in the IPv6 behavior of this =20 > product, be advised that most IPv6 applications won't work in the =20 > default mode, i.e. with the stateful packet filter turned on. For =20 > example, active mode FTP from the local network won't work, because =20= > the inbound TCP connection for the data will be blocked by the =20 > filter. We haven't written any application layer gateways for the =20 > IPv6 filter in the AirPort Extreme base station, so things like =20 > SIP, RTSP, IPsec/IKE, etc. simply will not work at all. I can't say =20= > when enhancements to support any of those application protocols =20 > will be available. They'll have to be written one by one, and until =20= > recently, we mistakenly thought that the whole point of IPv6 was to =20= > make that unnecessary. (Yeah, that'll teach me not to stay abreast =20 > of developments in the IETF.) This message is the start of a thread in which I later wrote this: > On Apr 10, 2007, at 12:13, R=E9mi Denis-Courmont wrote: >> [...] >> I am not so sure there is a "consensus" around the use of stateful =20= >> firewalls for SOHO CPEs. As I understand v6ops-nap, it says: "if =20 >> you want security equivalent to that of a NAT, you can use a =20 >> stateful firewall, and hence you should not be afraid of IPv6". It =20= >> does not say "you shall use a stateful firewall in any case". [...] > > As I noted earlier in this thread, section 4.2 of tools.ietf.org/wg/v6ops/draft-ietf-v6ops-nap-06/> says: > >>>> To implement simple security for IPv6 in, for example a DSL or =20 >>>> Cable Modem connected home network, the broadband gateway/router =20= >>>> should be equipped with stateful firewall capabilities. These =20 >>>> should provide a default configuration where incoming traffic is =20= >>>> limited to return traffic resulting from outgoing packets =20 >>>> (sometimes known as reflective session state). There should =20 >>>> also be an easy interface which allows users to create inbound =20 >>>> 'pinholes' for specific purposes such as online-gaming. > > At first, I thought this recommendation belonged in a BCP (i.e. =20 > that "may" would be better here than "should"). I was mistaken. > > We have now heard from a member of the IESG that the paragraph =20 > quoted above represents the hard-fought consensus opinion of the =20 > IETF community, and I see no reason to question his authority on =20 > the matter. Especially, since that opinion is completely in =20 > concurrence with similar recommendations from Microsoft, the U.S. =20 > Department of Homeland Security, and now my employers as well. In =20 > addition, I have searched the last six months of mail archives of =20 > the V6OPS and IPV6 working groups, as well as the archive of the =20 > IETF discussion group, and I have seen no sign of any controversy =20 > on this issue. > > As far as I can see, the debate has concluded and the issue is =20 > settled. > > Residential IPv6 gateways *will* implement stateful packet filters =20 > in their default configurations. I'm not interested in reopening a =20= > debate over that proposition. It's done. All I need now is to =20 > figure out how to make IPv6 do what IPv4/NAT can do today by using =20 > either NAT-PMP or UPnP. > > [...] > I wasn't involved in the drafting of the original NAT-PMP =20 > specification, but I was present for the reviews before it was =20 > published. At the time, we didn't envision NAT-PMP as anything =20 > more than a transition mechanism for use only with IPv4. To that =20 > end, we deliberately avoided making the protocol easily extended to =20= > support more than the limited functionality we felt was necessary =20 > to facilitate an orderly transition toward IPv6. > > See section 4.2, which says: > >>>> Any client making use of this protocol SHOULD implement IPv6 =20 >>>> support. If a client supports IPv6 and is running on a device =20 >>>> with a global IPv6 address, that IPv6 address SHOULD be =20 >>>> preferred to the IPv4 public address using this NAT mapping =20 >>>> protocol. In case other clients do not have IPv6 connectivity, =20 >>>> both the IPv4 and IPv6 addresses SHOULD be registered with =20 >>>> whatever form of directory server is used. Preference SHOULD be =20 >>>> given to IPv6 addresses when available. By implementing support =20 >>>> for IPv6 and using this protocol for IPv4, vendors can ship =20 >>>> products today that will work under both scenarios. As IPv6 is =20 >>>> more widely deployed, clients of this protocol following these =20 >>>> recommendations will transparently make use of IPv6. > > Alas, we are now revisiting whether this was a realistic transition =20= > plan in light of the consensus that IPv6 gateways will encompass =20 > stateful packet filters that need to be solicited for pinholes just =20= > like an IPv4/NAT gateway does. > > If extending NAT-PMP to support IPv6 is what needs to be done, then =20= > deliberately crippling the extensibility of the protocol to prevent =20= > it from being useful with transports and extension header types not =20= > currently defined is an obviously bad idea. I feel safe assuring =20 > the working group that Apple is committed to the IETF process for =20 > advancing a standard protocol that the entire community supports. > > This is why I am starting in the V6OPS working group. If the =20 > membership here agrees that an operational problem exists that =20 > needs a standards effort to solve, then this is the place to make =20 > the basic decisions about where to begin. Perhaps, extending ICMP =20 > is the right choice, in which case we should go to the IPV6 working =20= > group to begin. Otherwise, perhaps NAT-PMP could be used as a =20 > template for devising a new and separate IPV6-PMP specification. =20 > I'm not sure what working group would be the best choice for that =20 > work. > > If IETF doesn't think a standard protocol is necessary, then Apple =20 > will probably be left to do something non-standard. I hope that =20 > won't be necessary. > [...] That covers the parts of the thread that I think are worth =20 highlighting for the members of the BEHAVE group. Given that stateful packet filters (which interfere in IPv6 flows in =20 almost the same way as the stateful translating filters of IPv4/NAT) =20 will be as ubiquitous in IPv6 as NAT is today in IPv4, the following =20 questions remain open: + Of probably the highest and most immediate concern, how can we keep =20= the stateful packet filters in IPv6 gateways from completely =20 destroying the utility of IPsec in IPv6. We need to specify the =20 behavior of an ISAKMP proxy immediately. + Where is the appropriate venue for this discussion? BEHAVE or =20 V6OPS? Does BEHAVE need a new charter to deal with this? + Do we really expect that deploying new applications on IPv6 should =20 require field upgrades to the stateful packet filters throughout the =20 Internet? + Or, do we instead want to explore alternatives that allow nodes to =20 solicit the creation of filtering state automatically? + If so, how do we wish to proceed? - Start with an existing non-standard protocol, e.g. UPnP IGD, NAT-=20= PMP, etc. - Extend ICMP. - An original design not using ICMP. I have some other, more controversial problems to explore with both =20 BEHAVE and V6OPS, later, when the discussion moves on to scaling the =20 stateful packet filtering function up from small residential gateways =20= to large enterprise deployments. I'll leave those hanging in the air =20= for now, because I think the problems I'm surfacing here are enough =20 trouble for the next year or two. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 12 10:36: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 1Hc0PA-0001G6-AF; Thu, 12 Apr 2007 10:36:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc0P8-0001Fu-Ar for behave@ietf.org; Thu, 12 Apr 2007 10:36:06 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hc0Oy-0008K1-9s for behave@ietf.org; Thu, 12 Apr 2007 10:36:06 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB21F20FE3; Thu, 12 Apr 2007 16:35:54 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-d7-461e43ca1690 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DD0352052D; Thu, 12 Apr 2007 16:35:54 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 16:35:54 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 16:35:54 +0200 Message-ID: <461E43CA.9050100@ericsson.com> Date: Thu, 12 Apr 2007 16:35:54 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: james woodyatt Subject: Re: [BEHAVE] common issues in BEHAVE and V6OPS References: <11629D3E-E998-4E53-A48C-696388BFF72E@apple.com> In-Reply-To: <11629D3E-E998-4E53-A48C-696388BFF72E@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 14:35:54.0165 (UTC) FILETIME=[E021EE50:01C77D0F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF V6OPS WG , IETF 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 james woodyatt skrev: >> As far as I know, there is no current or pending IETF standard for >> nodes to use in requesting open pinholes through the stateful packet >> filter in a residential IPv6 gateway. In light of the IETF consensus >> noted earlier in this thread, doesn't that seem like a serious >> oversight? Isn't this function something that rightfully belongs in >> ICMP6? If not, do we really think extending NAT-PMP and UPnP IGD to >> support IPv6 network boundary filters is a good idea? (A month ago, I >> would have found that hard to believe, but I've made some embarrassing >> mistakes lately, so I'm gun-shy about what I don't believe anymore.) >> There are two pending solutions within the IETF for opening pinholes in NATs. There is one in the MIDCOM WG using SNMP and a MIB. http://tools.ietf.org/html/draft-ietf-midcom-mib-09.txt Then there is anpther solution developed by the NSIS WG: http://tools.ietf.org/html/draft-ietf-nsis-nslp-natfw-14.txt 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 Thu Apr 12 13:17: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 1Hc2vc-0001e8-2I; Thu, 12 Apr 2007 13:17:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc2va-0001bG-ET for behave@ietf.org; Thu, 12 Apr 2007 13:17:46 -0400 Received: from mx5-4.spamtrap.magma.ca ([209.217.78.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc2vW-0003fY-5B for behave@ietf.org; Thu, 12 Apr 2007 13:17:46 -0400 Received: from mail3.magma.ca (mail3.internal.magma.ca [10.0.10.13]) by mx5-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3CHHcZx018037; Thu, 12 Apr 2007 13:17:38 -0400 Received: from [10.0.1.3] ([24.139.16.154]) (authenticated bits=0) by mail3.magma.ca (Magma's Mail Server) with ESMTP id l3CHHa2A016128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Apr 2007 13:17:38 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Thu, 12 Apr 2007 13:17:33 -0400 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Behave WG Subject: [BEHAVE] Proposed WG milestone on choice of NAT traversal technique 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 11-Apr-07, at 20:42 , Dan Wing wrote: > > Also during the meeting there were some ideas around adding a new > milestone > for a document which might discuss when an application might choose > UNSAF > (STUN), Bonjour/UPnP, or other NAT traversal techniques. If a > candidate > document emerges we can consider creating such a milestone. > I would like to suggest that http://www.jdrosen.net/papers/draft-iab-nat-traversal- considerations-00.txt is a good starting point for this milestone. This document was originally an IAB-sponsored I-D, but was allowed to expire. I believe this document needs work. However, I like the classification scheme used in the document and believe that a balanced discussion of the pros and cons of each technique using this classification scheme would be very helpful. I personally see a frequent need for this document. We are seeing more and more protocols that want to add NAT Traversal, and people always ask: how should I do this? In fact, this topic came up once again just yesterday when someone asked me what the transition scheme would be from an ICE-based scheme to a MIDCOM- based scheme for NAT traversal. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 12 13:57: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 1Hc3Xm-0001SD-KF; Thu, 12 Apr 2007 13:57:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3Xl-0001R6-3X for behave@ietf.org; Thu, 12 Apr 2007 13:57:13 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc3Xj-0000Qu-ND for behave@ietf.org; Thu, 12 Apr 2007 13:57:13 -0400 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3CHvBlO021373 for ; Thu, 12 Apr 2007 10:57:11 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 2C94A40477 for ; Thu, 12 Apr 2007 10:57:11 -0700 (PDT) X-AuditID: 11807126-9ed4dbb0000007ff-85-461e72f7fbe4 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay8.apple.com (Apple SCV relay) with ESMTP id 230F84007A for ; Thu, 12 Apr 2007 10:57:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <461E43CA.9050100@ericsson.com> References: <11629D3E-E998-4E53-A48C-696388BFF72E@apple.com> <461E43CA.9050100@ericsson.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] common issues in BEHAVE and V6OPS Date: Thu, 12 Apr 2007 10:57:08 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Apr 12, 2007, at 07:35, Magnus Westerlund wrote: > james woodyatt skrev: >>> As far as I know, there is no current or pending IETF standard >>> for nodes to use in requesting open pinholes through the stateful >>> packet filter in a residential IPv6 gateway. In light of the IETF >>> consensus noted earlier in this thread, doesn't that seem like a >>> serious oversight? Isn't this function something that rightfully >>> belongs in ICMP6? If not, do we really think extending NAT-PMP >>> and UPnP IGD to support IPv6 network boundary filters is a good >>> idea? (A month ago, I would have found that hard to believe, but >>> I've made some embarrassing mistakes lately, so I'm gun-shy about >>> what I don't believe anymore.) > > There are two pending solutions within the IETF for opening > pinholes in NATs. There is one in the MIDCOM WG using SNMP and a MIB. > http://tools.ietf.org/html/draft-ietf-midcom-mib-09.txt This seems to support IPv6 well enough, but I'm not enthusiastic about using SNMP for this protocol, particularly with the recommendation that SNMP be used in conjunction with authPriv. That's human interface nightmare waiting to happen. > Then there is anpther solution developed by the NSIS WG: > http://tools.ietf.org/html/draft-ietf-nsis-nslp-natfw-14.txt Alas, this one would need to be amended for use with IPv6 stateful packet filters. ---- A more pressing problem is simply identifying the recommended behavior of IPv6 stateful packet filters, particularly with respect for ISAKMP and IKE. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 12 14:14: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 1Hc3os-0002ww-Ic; Thu, 12 Apr 2007 14:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3om-0002lU-VB for behave@ietf.org; Thu, 12 Apr 2007 14:14:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc3lZ-0004iX-B0 for behave@ietf.org; Thu, 12 Apr 2007 14:11:30 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 12 Apr 2007 11:11:02 -0700 X-IronPort-AV: i="4.14,403,1170662400"; d="scan'208"; a="410854072:sNHT7535614910" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3CIB1Y9025972; Thu, 12 Apr 2007 11:11:01 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3CIB0A8026235; Thu, 12 Apr 2007 18:11:00 GMT From: "Dan Wing" To: "'james woodyatt'" Subject: RE: [BEHAVE] common issues in BEHAVE and V6OPS Date: Thu, 12 Apr 2007 11:11:00 -0700 Message-ID: <011b01c77d2d$ed1587c0$c4f0200a@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9LAY8mWUVP/MISBaQMt07iDxh+wAANCSw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=904; t=1176401461; x=1177265461; c=relaxed/simple; s=sjdkim7002; 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]=20common=20issues=20in=20BEHAVE=20and=20V6OP S |Sender:=20; bh=H7uoePYO+ol6x/DgLgexdOvvMC6xg5WFqpFeEUmjHaA=; b=UytZJVIfZaMQ7phzJlEGd/DD6pBfZ6nr/3/c7GIN4pGh/4kty9q/oc4e3hTxC1xtWPEkUtMG q0YReCqWHanz4XdvatVLn4fIrV20PzgZgIMtSQxI6PCbwd6OVO1izQJs; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'IETF 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 > A more pressing problem is simply identifying the recommended > behavior of IPv6 stateful packet filters, particularly with respect > for ISAKMP and IKE. Could you encapsulate over UDP (RFC3948), and use a STUN-like technique to both (a) open the incoming permission and (b) to learn your UDP port? To your earlier thread: a problem with UPnP or NAT-PMP is opening permissions if you're behind multiple NATs (in IPv4) or behind multiple stateful packet filters (in IPv6 and in IPv4). In IPv6, I could imagine an upstream Ipv6 provider (your enterprise or your ISP) might deploy a stateful packet filter to protect your access link from saturation. (In IPv4, ISPs and enterprises often provide NATed IP addresses to their users, creating a similar layered stateful packet filtering situation, which also breaks UPnP and NAT-PMP). -d (as individual contributor) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 12 14:34: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 1Hc47Q-00068i-U4; Thu, 12 Apr 2007 14:34:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc47P-00066x-V9 for behave@ietf.org; Thu, 12 Apr 2007 14:34:03 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc47O-000678-JM for behave@ietf.org; Thu, 12 Apr 2007 14:34:03 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3CIY19J028297 for ; Thu, 12 Apr 2007 11:34:02 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id E2F553042F for ; Thu, 12 Apr 2007 11:34:01 -0700 (PDT) X-AuditID: 11807125-a0b21bb0000007e5-91-461e7b994f56 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay7.apple.com (Apple SCV relay) with ESMTP id C95FC3004A for ; Thu, 12 Apr 2007 11:34:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <011b01c77d2d$ed1587c0$c4f0200a@amer.cisco.com> References: <011b01c77d2d$ed1587c0$c4f0200a@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12CD98C6-8EF0-4C07-A62F-87911C56191F@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] common issues in BEHAVE and V6OPS Date: Thu, 12 Apr 2007 11:33:59 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Apr 12, 2007, at 11:11, Dan Wing wrote: > [I wrote:] >> >> A more pressing problem is simply identifying the recommended >> behavior of IPv6 stateful packet filters, particularly with respect >> for ISAKMP and IKE. > > Could you encapsulate over UDP (RFC3948), and use a STUN-like > technique to both (a) open the incoming permission and (b) to > learn your UDP port? How will the packet filter learn which inbound IPsec ESP packets to pass without inspecting the ISAKMP exchange and filtering on the SPI in the ESP header? Or consider this: how will it decide when to *stop* passing packets? This problem is analagous to the one in IPv4/ NAT for IPsec VPN passthrough prior to the adoption of NAT-traversal extensions. (Those extensions won't work in the absence of NAT, so they're not a suitable template for extending to IPv6.) More importantly, what behavior can an IPv6 node expect in the stateful packet filter in its default gateway. What does it have to do to keep the state for its IPsec SA alive in the gateway? I don't think any of that is well defined. It should be. > To your earlier thread: a problem with UPnP or NAT-PMP is > opening permissions if you're behind multiple NATs (in IPv4) > or behind multiple stateful packet filters (in IPv6 and in IPv4). We deliberately designed NAT-PMP so that it could be applied recursively, much like NSLP does. None of Apple's current implementations of NAT-PMP do that, but we've considered it as possible future direction. At the moment, we're still trying to teach our customers that they should use only one NAT at a time in residential networks, c.f. the following thread on the Apple Discussions forum: If this strategy doesn't work, we're going to have to try something more radical. As I've said before, we mistakenly thought NAT-PMP was merely a transition mechanism, and nothing like it would be necessary with IPv6. Oops. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 12 14: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 1Hc4RE-0002M2-6e; Thu, 12 Apr 2007 14:54:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4RC-0002Lv-Pu for behave@ietf.org; Thu, 12 Apr 2007 14:54:30 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc4RA-0004zm-B7 for behave@ietf.org; Thu, 12 Apr 2007 14:54:30 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 12 Apr 2007 11:54:27 -0700 X-IronPort-AV: i="4.14,403,1170662400"; d="scan'208"; a="410874064:sNHT225438944" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3CIsNsk012331; Thu, 12 Apr 2007 11:54:23 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3CIsNwn014880; Thu, 12 Apr 2007 18:54:23 GMT From: "Dan Wing" To: "'james woodyatt'" , "'IETF BEHAVE WG'" Subject: RE: [BEHAVE] common issues in BEHAVE and V6OPS Date: Thu, 12 Apr 2007 11:54:22 -0700 Message-ID: <014201c77d33$fc6d63e0$c4f0200a@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: <12CD98C6-8EF0-4C07-A62F-87911C56191F@apple.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9MSm1gC+VApP3Qv6w7aBsp5EkegAAKuzw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4307; t=1176404064; x=1177268064; c=relaxed/simple; s=sjdkim5002; 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]=20common=20issues=20in=20BEHAVE=20and=20V6OP S |Sender:=20; bh=mo4TmiLVCEHVJ+Kf3zLU800IlpCQjH4fojvQ20UzeeM=; b=wUFUxiR/jb7EOLVuo2nmHMgoxOV+KqPryczuAaMC0xGpKDE+d4DEwzePCxMGx6M87zAQMU6+ qkajlpSSb3aF4bG2TxpE1lCY9CGG14mGt3J9QbO1b7V2FifenClKC5E5; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Apr 12, 2007, at 11:11, Dan Wing wrote: > > [I wrote:] > >> > >> A more pressing problem is simply identifying the recommended > >> behavior of IPv6 stateful packet filters, particularly with respect > >> for ISAKMP and IKE. > > > > Could you encapsulate over UDP (RFC3948), and use a STUN-like > > technique to both (a) open the incoming permission and (b) to > > learn your UDP port? > > How will the packet filter learn which inbound IPsec ESP packets to > pass without inspecting the ISAKMP exchange and filtering on the SPI > in the ESP header? If it's all over UDP, the packet filter only knows it's a UDP flow that was initiated from the 'inside'. > Or consider this: how will it decide when to > *stop* passing packets? A timeout. > This problem is analagous to the one in IPv4/ > NAT for IPsec VPN passthrough prior to the adoption of NAT-traversal > extensions. "NAT-traversal extensions" = RFC3948? > (Those extensions won't work in the absence of NAT, so > they're not a suitable template for extending to IPv6.) RFC3948 doesn't work without a NAT? > More importantly, what behavior can an IPv6 node expect in the > stateful packet filter in its default gateway. What does it have to > do to keep the state for its IPsec SA alive in the gateway? I don't > think any of that is well defined. It should be. I agree it isn't defined at all. The IETF has long considered describing firewall (stateful packet inspection) behavior out of scope because they interfere with IETF's end-to-end principle. > > To your earlier thread: a problem with UPnP or NAT-PMP is > > opening permissions if you're behind multiple NATs (in IPv4) > > or behind multiple stateful packet filters (in IPv6 and in IPv4). > > We deliberately designed NAT-PMP so that it could be applied > recursively, much like NSLP does. None of Apple's current > implementations of NAT-PMP do that, but we've considered it as > possible future direction. I wasn't aware of that; sorry for my misunderstanding. > At the moment, we're still trying to > teach our customers that they should use only one NAT at a time in > residential networks, c.f. the following thread on the Apple > Discussions forum: > > It is my understanding that Microsoft makes a similar recommendation to NAT vendors -- they encourage NAT vendors to have their devices bridge (rather than NAT) if the NAT obtains a DHCP address that is an RFC1918 address (because that implies there is an upstream NAT). This sounds similar to what that URL describes the Apple Airports are doing. This recommendation seems suitable for the case of a home (or fraternity) with nested NATs. However, with IPv6, it's not possible to discern if there are multiple stateful packet filters upstream of you (you can't use RFC1918 addresses to make that determination like you can with NATs). So I don't know how IPv6 could recover from this situation. Additionally, subscribers cannot control what their ISPs do. One of the large cable companies in Germany NATs their subscribers (although last I heard, you could request a non-NATed IP address from them without additional cost). I understand it is routine for ISPs in South Korea to NAT their subscribers. In those cases, I expect only STUN (RFC3489/draft-ietf-behave-rfc3489bis) will be effective at traversing those layered NATs; UPnP and NAT-PMP won't be able to learn about the layered NAT or will make an inaccurate suggestion that NATing should be disabled (if the ISP provides an RFC1918 address to the subscriber). > If this strategy doesn't work, we're going to have to try > something more radical. As I've said before, we mistakenly > thought NAT-PMP was merely a transition mechanism, and > nothing like it would be necessary with IPv6. Oops. If you haven't already, you might look at draft-wing-behave-nat-control-stun-usage-01.txt. We are interested in moving this forward if there is industry support for the idea raised in that I-D. This won't be done inside of the BEHAVE working group, though; rather, we would have a BoF at the upcoming IETF in Chicago. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 12 15:02: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 1Hc4ZL-0000Pd-Ck; Thu, 12 Apr 2007 15:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4ZK-0000PV-23 for behave@ietf.org; Thu, 12 Apr 2007 15:02:54 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc4ZI-00031y-NU for behave@ietf.org; Thu, 12 Apr 2007 15:02:54 -0400 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3CJ2qx4024127 for ; Thu, 12 Apr 2007 12:02:52 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 1733D1008D for ; Thu, 12 Apr 2007 12:02:52 -0700 (PDT) X-AuditID: 11807124-9dd77bb0000007e5-ad-461e825cc47c Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay6.apple.com (Apple SCV relay) with ESMTP id 0FC5210022 for ; Thu, 12 Apr 2007 12:02:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <014201c77d33$fc6d63e0$c4f0200a@amer.cisco.com> References: <014201c77d33$fc6d63e0$c4f0200a@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D5A1AC9-7CAD-4EDD-B265-1F53E090F886@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] common issues in BEHAVE and V6OPS Date: Thu, 12 Apr 2007 12:02:49 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Apr 12, 2007, at 11:54, Dan Wing wrote: > > RFC3948 doesn't work without a NAT? I guess it could work without a NAT. However, it's an encapsulation for IPsec ESP only. What about AH? This works for IPsec ESP tunnel mode, but transport mode is still broken, isn't it? -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 12 15:09: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 1Hc4fr-0001OZ-14; Thu, 12 Apr 2007 15:09:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4fp-0001OU-KR for behave@ietf.org; Thu, 12 Apr 2007 15:09:37 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc4fn-0007sd-93 for behave@ietf.org; Thu, 12 Apr 2007 15:09:37 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3CJ9YXX025171 for ; Thu, 12 Apr 2007 12:09:34 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id AD44C29C003 for ; Thu, 12 Apr 2007 12:09:34 -0700 (PDT) X-AuditID: 11807123-9e3e6bb000000b42-0d-461e83ee2f47 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay5.apple.com (Apple SCV relay) with ESMTP id 93CAB30400B for ; Thu, 12 Apr 2007 12:09:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4D5A1AC9-7CAD-4EDD-B265-1F53E090F886@apple.com> References: <014201c77d33$fc6d63e0$c4f0200a@amer.cisco.com> <4D5A1AC9-7CAD-4EDD-B265-1F53E090F886@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] common issues in BEHAVE and V6OPS Date: Thu, 12 Apr 2007 12:09:31 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Apr 12, 2007, at 12:02, james woodyatt wrote: > On Apr 12, 2007, at 11:54, Dan Wing wrote: >> >> RFC3948 doesn't work without a NAT? > > I guess it could work without a NAT. However, it's an > encapsulation for IPsec ESP only. What about AH? This works for > IPsec ESP tunnel mode, but transport mode is still broken, isn't it? My mistake. Both tunnel and transport mode ESP work. We can probably forget about AH, because the packet filter will probably just jump through to the next header when it sees an AH extension header. So that would mean we would see packets that look like this a lot: [ IPv6 | AH | UDP | ESP | payload... ] Yuck, but it works. Okay, I think we can do without having to implement the ISAKMP proxy now. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 13 03:25: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 1HcG9n-0003YO-Uv; Fri, 13 Apr 2007 03:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcG9m-0003YC-L3 for behave@ietf.org; Fri, 13 Apr 2007 03:25:18 -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 1HcG9m-0006cH-5v for behave@ietf.org; Fri, 13 Apr 2007 03:25:18 -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 l3D7P9FL007447 for ; Fri, 13 Apr 2007 10:25:16 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:24:46 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:24:46 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:24:46 +0300 Received: from esdhcp04096.research.nokia.com (esdhcp04096.research.nokia.com [172.21.40.96]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3D7Oi0u019111 for ; Fri, 13 Apr 2007 10:24:44 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] common issues in BEHAVE and V6OPS Date: Fri, 13 Apr 2007 10:24:45 +0300 User-Agent: KMail/1.9.6 References: <11629D3E-E998-4E53-A48C-696388BFF72E@apple.com> <461E43CA.9050100@ericsson.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: <200704131024.45334.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 13 Apr 2007 07:24:46.0181 (UTC) FILETIME=[D0069150:01C77D9C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070413102516-17A24BB0-03AF6D4B/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 12 April 2007 20:57:08 ext james woodyatt wrote: > > There are two pending solutions within the IETF for opening > > pinholes in NATs. There is one in the MIDCOM WG using SNMP and a MIB. > > http://tools.ietf.org/html/draft-ietf-midcom-mib-09.txt > > This seems to support IPv6 well enough, but I'm not enthusiastic > about using SNMP for this protocol, particularly with the > recommendation that SNMP be used in conjunction with authPriv. > That's human interface nightmare waiting to happen. Yup. I'd rather the system piggybacks on the IPv6 ND autoconf & trust model= ,=20 than require any extra configuration or credentials: trust everybody on lin= k.=20 This can be enforced by only sending and receiving packets with HopLimit=3D= 255=20 and ICMPv6 (which non-privileged applications cannot use on most systems). This means transmitting data upstream is done from inside to outside, contr= ary=20 to STUN NAT control. I reckon STUN control is designed with backward=20 compatibility and NAT traversal in mind, which should be non-issues here.=20 Also, while there's certainly some stuff to keep from STUN, there are two=20 reasons why it should not be MUXED with the actual data: 1/ it's going to get very tricky if the actual media flow uses STUN (e.g.=20 ICE-TCP) on top of the pinholing mechanism, 2/ use of ICMPv6 rather than UDP allows (but does not require) implementati= on=20 lower in the stack, so it can more easily be commoditized across a running= =20 system - in fact it can become transparent to the BSD socket API. Back to security, if better than trust-link is ever required, perhaps it co= uld=20 piggyback on the IPv6 SEND stuff. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 13 10:39: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 1HcMwK-0007u3-1f; Fri, 13 Apr 2007 10:39:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMwI-0007tp-Cl for behave@ietf.org; Fri, 13 Apr 2007 10:39:50 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcMwH-0004SS-21 for behave@ietf.org; Fri, 13 Apr 2007 10:39:50 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3DEdjYN022549; Fri, 13 Apr 2007 10:39:45 -0400 (EDT) Received: from [192.168.1.105] (pool-151-199-61-176.bos.east.verizon.net [151.199.61.176]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3DEdgit019442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Apr 2007 10:39:43 -0400 (EDT) Subject: Re: [BEHAVE] common issues in BEHAVE and V6OPS From: Bryan Ford To: =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont In-Reply-To: <200704131024.45334.remi.denis-courmont@nokia.com> References: <11629D3E-E998-4E53-A48C-696388BFF72E@apple.com> <461E43CA.9050100@ericsson.com> <200704131024.45334.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=utf-8 Organization: Massachusetts Institute of Technology Date: Fri, 13 Apr 2007 10:39:50 -0400 Message-Id: <1176475190.4842.16.camel@slack> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by biscayne-one-station.mit.edu id l3DEdjYN022549 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Fri, 2007-04-13 at 10:24 +0300, R=C3=A9mi Denis-Courmont wrote: > On Thursday 12 April 2007 20:57:08 ext james woodyatt wrote: > > > There are two pending solutions within the IETF for opening > > > pinholes in NATs. There is one in the MIDCOM WG using SNMP and a MI= B. > > > http://tools.ietf.org/html/draft-ietf-midcom-mib-09.txt > > > > This seems to support IPv6 well enough, but I'm not enthusiastic > > about using SNMP for this protocol, particularly with the > > recommendation that SNMP be used in conjunction with authPriv. > > That's human interface nightmare waiting to happen. >=20 > Yup. I'd rather the system piggybacks on the IPv6 ND autoconf & trust m= odel,=20 > than require any extra configuration or credentials: trust everybody on= link.=20 > This can be enforced by only sending and receiving packets with HopLimi= t=3D255=20 > and ICMPv6 (which non-privileged applications cannot use on most system= s). Unfortunately this latter property (that non-privileged applications cannot use ICMP) is also a disadvantage to an ICMP mechanism at least in terms of near-term deployment. Applications would have to wait for their host OS to be upgraded with support for this mechanism (or else be distributed with kernel patches that have to be installed by a privileged user) in order to take advantage of it. Whereas applications that use an ordinary UDP-based protocol like NAT-PMP can just request the pinholes they need directly from their unprivileged application contexts. This issue wouldn't necessarily be a major concern, as long as the hypothetical ICMPv6-based hole punching mechanism becomes a MANDATORY component of IPv6 protocol stacks (with its use subject to local security policies of course) by the time IPv6 firewalls start really proliferating. But that would add considerable time pressure to the design and standardization process for such an ICMPv6 extension, given that as we can see this proliferation has already begun. And I for one don't have too much confidence in the ability of the IETF working group process to design, standardize, and deploy anything NAT/firewall-related "quickly". If it takes too long for the ICMPv6-based pinholing extension to become standardized and widely implemented and usable by applications, then applications and middlebox vendors will just use something else, such as an IPv6 adaptation of UPnP or NAT-PMP, or else applications will simply avoid supporting IPv6 at all for now because IPv4 works for them and IPv6 doesn't. Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 13 14:58:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQyf-0007a2-4Y; Fri, 13 Apr 2007 14:58:33 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HcQyd-0007Zc-CS for behave-confirm+ok@megatron.ietf.org; Fri, 13 Apr 2007 14:58:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQyd-0007ZU-2x for behave@ietf.org; Fri, 13 Apr 2007 14:58:31 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcQyL-0001ae-B5 for behave@ietf.org; Fri, 13 Apr 2007 14:58:31 -0400 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3DIwCgA018126 for ; Fri, 13 Apr 2007 11:58:12 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 9F35440012 for ; Fri, 13 Apr 2007 11:58:12 -0700 (PDT) X-AuditID: 11807126-9ed4dbb0000007ff-d2-461fd2c47d28 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay8.apple.com (Apple SCV relay) with ESMTP id 8EC4E40557 for ; Fri, 13 Apr 2007 11:58:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <1176475190.4842.16.camel@slack> References: <11629D3E-E998-4E53-A48C-696388BFF72E@apple.com> <461E43CA.9050100@ericsson.com> <200704131024.45334.remi.denis-courmont@nokia.com> <1176475190.4842.16.camel@slack> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3EA26439-812A-4A79-83CD-BAD41F693C30@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] common issues in BEHAVE and V6OPS Date: Fri, 13 Apr 2007 11:58:09 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Apr 13, 2007, at 07:39, Bryan Ford wrote: > > Unfortunately this latter property (that non-privileged > applications cannot use ICMP) is also a disadvantage to an ICMP > mechanism at least in terms of near-term deployment. [...] This is true, but we're not talking about a transition mechanism anymore. Whatever we do to solve this problem will be with us for the next thousand years. Short-term considerations *must* be prioritized accordingly. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 15 00:23: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 1HcwHG-0001JO-Hb; Sun, 15 Apr 2007 00:23:50 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HcwHF-0001JJ-4i for behave-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 00:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcwHE-0001JB-PH for behave@ietf.org; Sun, 15 Apr 2007 00:23:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcwHC-0007iA-EB for behave@ietf.org; Sun, 15 Apr 2007 00:23:48 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2007 21:23:44 -0700 X-IronPort-AV: i="4.14,411,1170662400"; d="scan'208"; a="411571243:sNHT44525140" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3F4NhXL020627; Sat, 14 Apr 2007 21:23:43 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l3F4Ngwo017322; Sun, 15 Apr 2007 04:23:42 GMT In-Reply-To: <46013A17.5070309@db.org> References: <46013A17.5070309@db.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D954ED1-FC1B-434C-B75A-51FC9FDEE1FC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] duplicated STUN attributes Date: Sat, 14 Apr 2007 21:23:13 -0700 To: "Alfred E. Heggestad" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=823; t=1176611023; x=1177475023; c=relaxed/simple; s=sjdkim8002; 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]=20duplicated=20STUN=20attributes |Sender:=20; bh=yYvz61u6pcZxuKGJlhROCMep9Gc5OKRChzXRX7wLRHA=; b=ZZxcHHrWLVuVoxytmF5F2wMxnvqpnm8pG3kjXETHHm1pFg3miQ1uiiC759RYC4cfH5rIEaI6 HKM87YxOo1q2umqpFcRjS8Kpj5uK5lyimDXrjCMNyRYrT0N0ntL26K8g; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Another excellent example of why we should let IANA run this registry. On Mar 21, 2007, at 6:58 AM, Alfred E. Heggestad wrote: > hi > > I would just like to point out that there are some duplicated > STUN attributes on the "STUN Attributes" homepage: > > PADDING 0x0026 > PADDING 0x8026 > > http://www.employees.org/behave/stun-attributes.html > > > > request to authors of STUN usage documents: please review the > list of STUN attribute values (both tables) *before* submitting > the I-D, and make sure that it does not conflict with itself > or any other STUN usages. > > this would make the life of STUN implementors easier. > > > /alfred > > _______________________________________________ > 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 Sun Apr 15 00:41: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 1HcwYV-0002Fm-1z; Sun, 15 Apr 2007 00:41:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HcwYT-0002Fe-LD for behave-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 00:41:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcwYT-0002FW-Bf for behave@ietf.org; Sun, 15 Apr 2007 00:41:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcwYS-0001bD-2C for behave@ietf.org; Sun, 15 Apr 2007 00:41:37 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2007 21:41:35 -0700 X-IronPort-AV: i="4.14,411,1170662400"; d="scan'208"; a="136055677:sNHT69612147" 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 l3F4fZrf009561; Sat, 14 Apr 2007 21:41: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 l3F4fXEj012226; Sun, 15 Apr 2007 04:41:33 GMT In-Reply-To: <3a0701c7771b$12c5be40$c4f0200a@amer.cisco.com> References: <3a0701c7771b$12c5be40$c4f0200a@amer.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] NAT-ICMP summary Date: Sat, 14 Apr 2007 21:41:04 -0700 To: Dan Wing X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1501; t=1176612095; x=1177476095; 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]=20NAT-ICMP=20summary |Sender:=20; bh=/QOLnb8cfT1qU4ErMbmpINHNnKhrgoxC5QNYGBrcGnE=; b=aDi6Ro8jfcZY5xxLi76hutH6p82tJF41dGvf4K1piPd5LGtQz28/erPD7wXh/lzlkMqNbnKx HBspdWm+/dfCr9j19Euc02yW/A95WnEDpjVzRrXzSTdIozbjKkBrZYRF+oPdUphdo4BW/j5hNU ip0kpaIiKps8WZPmMFfLoU0ME=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Apr 4, 2007, at 5:40 PM, Dan Wing wrote: > NEW: > Unfortunately, ICMP messages are sometimes blocked at network > boundaries due to local security policy. Thus, some of the > requirements in this document allow local policy to override > the recommendations of this document. Blocking such ICMP > messages is known to break some protocol features (most notably > Path MTU Discovery) and some applications (e.g., ping, > traceroute), and such blocking is NOT RECOMMENDED. Just commenting on this one part of the proposed changes - this did not seem to this did not seem to reflect the subtle of what I could pull out of the meeting recording and list traffic but I was not in the meeting so who knows ... I think you are stepping into controversial areas here that can easily be avoided by just tighten this up a bit. Many people feel that blocking some ICMP messages is recommended - just not ones that break things. Now the what should be blocked is a firewall issue out of scope of this WG but we would like to not automatically make firewall non compliant with this. I think that what you should say here is that this draft recommends particular ICMP messages in particular situations that the NAT SHOULD NOT block. The recommendation of what ICMP message need to work for UDP and TCP our covered in theses documents - here you should just have the stuff for the ICMP applications. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 15 00:41:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcwYn-0002JR-9m; Sun, 15 Apr 2007 00:41:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HcwYm-0002JJ-Ax for behave-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 00:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcwYm-0002JB-1M for behave@ietf.org; Sun, 15 Apr 2007 00:41:56 -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 1HcwYk-0001jz-PF for behave@ietf.org; Sun, 15 Apr 2007 00:41:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2007 21:41:54 -0700 X-IronPort-AV: i="4.14,411,1170662400"; d="scan'208"; a="369855828:sNHT44510454" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3F4fslI013067; Sat, 14 Apr 2007 21:41:54 -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 l3F4fXEk012226; Sun, 15 Apr 2007 04:41:53 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <285C82A6-F1D9-4088-9B16-A40593F5E651@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sat, 14 Apr 2007 21:41:29 -0700 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=647; t=1176612114; x=1177476114; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20MIDCOM=20&=20ICE |Sender:=20; bh=/PVZ+UyablfO2ERFnak8xjQFdW/nDyV64xTzT0cn3ks=; b=eQAFoQgMlWfjcLIize0FRWS8OyCDiMT595sXs6J2LwJG7PoF83m1CpOYt3gZ80MOn2LfHrhX FvD7Xbj4tYjXprligQDrQah/MFXFq79H5ioufFDgpYPtoQMkN7CCC8Pd; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.4 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Behave WG , Dan Wing Subject: [BEHAVE] MIDCOM & ICE 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 Apr 12, 2007, at 10:17 AM, Philip Matthews wrote: > In fact, this topic came up once again just yesterday when someone > asked me what > the transition scheme would be from an ICE-based scheme to a MIDCOM- > based > scheme for NAT traversal. Assuming the MIDCOM FW/NAT trusts the UA (or B2BUA), which as far as I can tell is the only deployable MIDCOM architecture, MIDCOM would be just another candidate address in the ICE lists. I don't think there would be a transition from ICE to MIDCOM. ICE is the approach by which you might be able to use MIDCOM alongside other things. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 15 12: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 1Hd7fX-0002q6-TW; Sun, 15 Apr 2007 12:33:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hd7fW-0002py-Uq for behave-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 12:33:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd7fW-0002pq-LM for behave@ietf.org; Sun, 15 Apr 2007 12:33:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd7fV-0008F3-9P for behave@ietf.org; Sun, 15 Apr 2007 12:33:38 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2007 09:33:36 -0700 X-IronPort-AV: i="4.14,412,1170662400"; d="scan'208"; a="136140805:sNHT53044992" 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 l3FGXawJ002365; Sun, 15 Apr 2007 09:33:36 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3FGXXMF009992; Sun, 15 Apr 2007 16:33:36 GMT From: "Dan Wing" To: "'Cullen Jennings'" , "'Alfred E. Heggestad'" Subject: RE: [BEHAVE] duplicated STUN attributes Date: Sun, 15 Apr 2007 09:33:32 -0700 Message-ID: <012801c77f7b$d0bc1300$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <0D954ED1-FC1B-434C-B75A-51FC9FDEE1FC@cisco.com> Thread-Index: Acd/Fez3PiCJZRQtTcyOHZTN4+xMVQAZZN0g DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1637; t=1176654816; x=1177518816; 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[BEHAVE]=20duplicated=20STUN=20attributes |Sender:=20; bh=DA33r4kkwFrJi3YJ1e2B7V+0xQNvnQQhcRx5Divu3Og=; b=ITnpPg/xSGCutm6qqZUfxZjcyeLwmkYdOBSrwo6qHwdfrAtQNFajJFgBwJ9gSGOg7fAybU2E Z/nZDQAlR5xOVblD8pCbMwZGql78JdKY7zuh478y5NW1QJjhqcdZLj+ApJiCWaHZMIyPzqpe// clZV7e4qMX/KjrGo2bPtxZxnQ=; 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: f4c2cf0bccc868e4cc88dace71fb3f44 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 The reason the employees.org page lists both of those values is because they're both defined by -nat-behavior-discovery: > grep "26.*PADDING" draft-ietf-behave-nat-behavior-discovery-00.txt 0x8026: PADDING 0x0026: PADDING I agree IANA needs to run this, once these documents are RFCs -- an IANA registry wouldn't be effective for Internet Drafts. -d > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Saturday, April 14, 2007 9:23 PM > To: Alfred E. Heggestad > Cc: Behave WG > Subject: Re: [BEHAVE] duplicated STUN attributes > > > Another excellent example of why we should let IANA run this registry. > > On Mar 21, 2007, at 6:58 AM, Alfred E. Heggestad wrote: > > > hi > > > > I would just like to point out that there are some duplicated > > STUN attributes on the "STUN Attributes" homepage: > > > > PADDING 0x0026 > > PADDING 0x8026 > > > > http://www.employees.org/behave/stun-attributes.html > > > > > > > > request to authors of STUN usage documents: please review the > > list of STUN attribute values (both tables) *before* submitting > > the I-D, and make sure that it does not conflict with itself > > or any other STUN usages. > > > > this would make the life of STUN implementors easier. > > > > > > /alfred > > > > _______________________________________________ > > 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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 15 13:19: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 1Hd8O0-0002ba-VU; Sun, 15 Apr 2007 13:19:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hd8Ny-0002bV-UV for behave-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 13:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd8Ny-0002bN-L2 for behave@ietf.org; Sun, 15 Apr 2007 13:19:34 -0400 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd8Nw-00087d-4I for behave@ietf.org; Sun, 15 Apr 2007 13:19:34 -0400 Received: from [84.209.225.83] (helo=[10.0.0.4]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1Hd8Nu-0003W6-DR; Sun, 15 Apr 2007 17:19:30 +0000 Message-ID: <46225EA1.7070204@db.org> Date: Sun, 15 Apr 2007 19:19:29 +0200 From: "Alfred E. Heggestad" User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] duplicated STUN attributes References: <012801c77f7b$d0bc1300$c4f0200a@amer.cisco.com> In-Reply-To: <012801c77f7b$d0bc1300$c4f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Hi Dan I think the employees.org page helps alot co-ordinating these values while the spec is under development (i.e. internet-draft). at the moment we have at least these specs under development; rfc3489bis, turn, natbd and ice. I would suggest that attribute values are only mentioned once in the spec, to avoid conflicts, also I hope that the authors can check the values against employees.org before publishing.. /alfred Dan Wing wrote: > The reason the employees.org page lists both of those values is because > they're both defined by -nat-behavior-discovery: > > > grep "26.*PADDING" draft-ietf-behave-nat-behavior-discovery-00.txt > 0x8026: PADDING > 0x0026: PADDING > > > I agree IANA needs to run this, once these documents are RFCs -- an IANA > registry wouldn't be effective for Internet Drafts. > > -d > > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Saturday, April 14, 2007 9:23 PM >> To: Alfred E. Heggestad >> Cc: Behave WG >> Subject: Re: [BEHAVE] duplicated STUN attributes >> >> >> Another excellent example of why we should let IANA run this registry. >> >> On Mar 21, 2007, at 6:58 AM, Alfred E. Heggestad wrote: >> >>> hi >>> >>> I would just like to point out that there are some duplicated >>> STUN attributes on the "STUN Attributes" homepage: >>> >>> PADDING 0x0026 >>> PADDING 0x8026 >>> >>> http://www.employees.org/behave/stun-attributes.html >>> >>> >>> >>> request to authors of STUN usage documents: please review the >>> list of STUN attribute values (both tables) *before* submitting >>> the I-D, and make sure that it does not conflict with itself >>> or any other STUN usages. >>> >>> this would make the life of STUN implementors easier. >>> >>> >>> /alfred >>> >>> _______________________________________________ >>> 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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 16 12:06: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 1HdTiX-0003aw-7u; Mon, 16 Apr 2007 12:06:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdTiW-0003ar-89 for behave-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 12:06:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTiV-0003aj-Us for behave@ietf.org; Mon, 16 Apr 2007 12:06:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTiT-0006CV-II for behave@ietf.org; Mon, 16 Apr 2007 12:06:11 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Apr 2007 09:06:09 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="769107919:sNHT85266782" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3GG67Mi015825; Mon, 16 Apr 2007 09:06:07 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3GG66ZT005787; Mon, 16 Apr 2007 16:06:06 GMT From: "Dan Wing" To: "'Alfred E. Heggestad'" Subject: RE: [BEHAVE] duplicated STUN attributes Date: Mon, 16 Apr 2007 09:06:05 -0700 Message-ID: <025701c78041$23eea360$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46225EA1.7070204@db.org> Thread-Index: Acd/gkTLRgfvSMJsTB6QdaaaG86GogAvtpbQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2689; t=1176739567; x=1177603567; 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]=20duplicated=20STUN=20attributes |Sender:=20; bh=inQe0hIdp5wT1mIPlXLBAxIG7NEuR0U/Z7dTrBjVKWQ=; b=r3+TC7cxE545OsVRDelfVPPj0EDLTH/uMvKFLQoi8+3X9rOnkZ4IboS3v85zNcF1SFMLEaVm TKsGVhI5ECHgYAedyo6Pum5bleJUpPOWimx0yTO3YEucqBnww6jozw2G; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Yes, agreed. -d > -----Original Message----- > From: Alfred E. Heggestad [mailto:aeh@db.org] > Sent: Sunday, April 15, 2007 10:19 AM > To: Dan Wing > Cc: 'Behave WG' > Subject: Re: [BEHAVE] duplicated STUN attributes > > Hi Dan > > I think the employees.org page helps alot co-ordinating these values > while the spec is under development (i.e. internet-draft). at the > moment we have at least these specs under development; rfc3489bis, > turn, natbd and ice. > > I would suggest that attribute values are only mentioned once in > the spec, to avoid conflicts, also I hope that the authors can check > the values against employees.org before publishing.. > > > /alfred > > Dan Wing wrote: > > The reason the employees.org page lists both of those > values is because > > they're both defined by -nat-behavior-discovery: > > > > > grep "26.*PADDING" > draft-ietf-behave-nat-behavior-discovery-00.txt > > 0x8026: PADDING > > 0x0026: PADDING > > > > > > I agree IANA needs to run this, once these documents are > RFCs -- an IANA > > registry wouldn't be effective for Internet Drafts. > > > > -d > > > > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Saturday, April 14, 2007 9:23 PM > >> To: Alfred E. Heggestad > >> Cc: Behave WG > >> Subject: Re: [BEHAVE] duplicated STUN attributes > >> > >> > >> Another excellent example of why we should let IANA run > this registry. > >> > >> On Mar 21, 2007, at 6:58 AM, Alfred E. Heggestad wrote: > >> > >>> hi > >>> > >>> I would just like to point out that there are some duplicated > >>> STUN attributes on the "STUN Attributes" homepage: > >>> > >>> PADDING 0x0026 > >>> PADDING 0x8026 > >>> > >>> http://www.employees.org/behave/stun-attributes.html > >>> > >>> > >>> > >>> request to authors of STUN usage documents: please review the > >>> list of STUN attribute values (both tables) *before* submitting > >>> the I-D, and make sure that it does not conflict with itself > >>> or any other STUN usages. > >>> > >>> this would make the life of STUN implementors easier. > >>> > >>> > >>> /alfred > >>> > >>> _______________________________________________ > >>> 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 > > > > > _______________________________________________ > 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 Tue Apr 17 07:10: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 1Hdla8-0000ub-U6; Tue, 17 Apr 2007 07:10:44 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hdla7-0000uA-Gc for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 07:10:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdla7-0000tc-6A for behave@ietf.org; Tue, 17 Apr 2007 07:10:43 -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 1Hdla6-0002wt-MN for behave@ietf.org; Tue, 17 Apr 2007 07:10:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3HBAX76029008 for ; Tue, 17 Apr 2007 14:10:40 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 14:10:34 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 14:10:29 +0300 Received: from esdhcp04070.research.nokia.com (esdhcp04070.research.nokia.com [172.21.40.70]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3HBASZ4025725; Tue, 17 Apr 2007 14:10:28 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] common issues in BEHAVE and V6OPS Date: Tue, 17 Apr 2007 14:10:27 +0300 User-Agent: KMail/1.9.6 References: <011b01c77d2d$ed1587c0$c4f0200a@amer.cisco.com> In-Reply-To: <011b01c77d2d$ed1587c0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704171410.27677.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Apr 2007 11:10:29.0749 (UTC) FILETIME=[02460A50:01C780E1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 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 Thursday 12 April 2007 21:11:00 ext Dan Wing wrote: > > A more pressing problem is simply identifying the recommended > > behavior of IPv6 stateful packet filters, particularly with respect > > for ISAKMP and IKE. > > Could you encapsulate over UDP (RFC3948), and use a STUN-like > technique to both (a) open the incoming permission and (b) to > learn your UDP port? I have been thinking about STUN, STUN NAT control and so... I believe STUN NAT control is unfortunately something completely different.= =20 STUN NAT control is really -currently- biased toward controlling NATs rathe= r=20 than firewalls... In particular, it's guessing the middlebox address from t= he=20 MAPPED-ADDRESS attribute of a request to an external STUN server, and then= =20 chain requests to "more inner" NATs until MAPPED-ADDRESS =3D socket address. In the IPv6 firewall case, the problem is supposedly reversed. First, you=20 probably do not want to depend on an external STUN server; second, you cann= ot=20 assume that each firewalling middlebox will be a NAT (in fact, they should= =20 probably NOT be NATs). That's not to say STUN message cannot be used, but i= t=20 would be yet another usage. In particular, it would probably go from inner = to=20 outer box rather than from outer to inner box (??). There are other reasons why handling IPv6 would be fairly different on the= =20 middlebox: =2D It has to handle/skip IPv6 extensions headers properly; it cannot simpl= y=20 extract the transport protocol from the IP header as in IPv4, =2D Also, learning from the mistakes of IPv4 NATs and firewalls, it should= =20 probably handle protocols that do not have ports numbers (so that, e.g. the= =20 client node can ask for ESP to pass through), =2D Similarly, it probably should have a generic UDP/timer-based handling f= or=20 transport protocols which it does not know how to properly track (UDP-Lite,= =20 DCCP and SCTP are the current ones, but better make this generic anyway). A= t=20 least in the unmanaged case, this ought to work. So the request could probably look like something with: - one byte for the transport protocol (with ext headers IANA values=20 explicitly forbidden), - an optional port parameter (e.g. used for TCP, but not ESP), - hole refresh timer, - an optional allowed remote address (not specified =3D requesting that an= y=20 peer traffic be transmitted, though local policy might deny the request). A successful response would need to specify the accepted hole refresh timer= ,=20 and an optional "upstream" firewall to also be notified. I am not sure how to give notification if a middlebox reboots... if it's th= e=20 first hop, it can send a multicast message (as with NAT-PMP). > To your earlier thread: a problem with UPnP or NAT-PMP is > opening permissions if you're behind multiple NATs (in IPv4) > or behind multiple stateful packet filters (in IPv6 and in IPv4). > > In IPv6, I could imagine an upstream Ipv6 provider (your > enterprise or your ISP) might deploy a stateful packet filter > to protect your access link from saturation. Yes. So you then you actually need to tell the ISP what you want to receive. > (In IPv4, ISPs and enterprises often provide NATed IP addresses > to their users, creating a similar layered stateful packet > filtering situation, which also breaks UPnP and NAT-PMP). =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 Apr 17 16:42: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 1HduVk-0003hx-Cb; Tue, 17 Apr 2007 16:42:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HduVj-0003hm-TY for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 16:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HduVj-0003he-K5 for behave@ietf.org; Tue, 17 Apr 2007 16:42:47 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HduVh-00018i-6J for behave@ietf.org; Tue, 17 Apr 2007 16:42:47 -0400 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3HKgiUI027298 for ; Tue, 17 Apr 2007 13:42:44 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 85C1B404FC for ; Tue, 17 Apr 2007 13:42:44 -0700 (PDT) X-AuditID: 11807126-9fd4fbb0000007ff-52-46253144dd65 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay8.apple.com (Apple SCV relay) with ESMTP id 683FE404E3 for ; Tue, 17 Apr 2007 13:42:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <200704171410.27677.remi.denis-courmont@nokia.com> References: <011b01c77d2d$ed1587c0$c4f0200a@amer.cisco.com> <200704171410.27677.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <47ED8FFB-10B7-4E36-9D67-C140A9D08289@apple.com> Content-Transfer-Encoding: quoted-printable From: james woodyatt Date: Tue, 17 Apr 2007 13:42:39 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [BEHAVE] soliciting firewalls for inbound flows 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 Apr 17, 2007, at 04:10, R=E9mi Denis-Courmont wrote: > > Yes. So you then you actually need to tell the [firewall] what you =20 > want to receive. This is one of the peculiar parts of the problem. I was discussing this matter with Stuart Cheshire yesterday =20 afternoon, and he agreed with me that a straightforward adaptation of =20= NAT-PMP to IPv6 is a very bad idea. He reiterated to me that NAT-PMP =20= was always regarded as a very limited protocol, suitable only for =20 allowing us to limp along with IPv4/NAT until the glorious =20 restoration of end-to-end connectivity could be achieved with the =20 transition to IPv6. Now that IPv6 end-to-end connectivity has been =20 crippled by the commercial rollout of residential gateways that block =20= inbound flow initiations in their factory default configurations, we =20 need a new mechanism designed from the ground up that we can live =20 with happily for all time. But, there's a problem. You actually need to tell the firewall what =20 you want to receive. Let me explain why we have that problem. The interesting thing about =20= NAT-PMP (and UPnP, too) is that applications written to the proper =20 API will automatically solicit the state required in the firewall to =20 pass inbound flow initiations to them just by calling the moral =20 equivalent of listen() on a socket. So, why not extend the IPv6 =20 stack so that when listen() is called on an IPv6 TCP socket (or a UDP =20= socket is bound, or or or), it results in the request to create the =20 state in the firewall to allow connections to be received? Some people I've talked with have said, why not dispense with the =20 requests and just have the firewall send the initiating packets =20 encapsulated in an ICMP header after they pass the static portion of =20 the firewall rule set? The answer turns out that the security =20 concern is only addressed when the endpoint node is the one =20 soliciting the creation of state in the firewall. When we shipped AirPort Extreme 802.11n earlier this year, the =20 factory default configuration was 1) NAT-PMP enabled and serving =20 requests, and 2) IPv6 stateful packet filter disabled. It wasn't long before security experts reviewed the device and raised =20= an unholy ruckus about the IPv6 filter not being enabled. They =20 didn't care at all about the NAT-PMP service, and they still don't. =20 (Few people seem to regard UPnP IGD as an unacceptable security risk =20 when it's enabled by default in residential gateways. Earlier =20 versions of AirPort Extreme shipped with NAT-PMP configured to refuse =20= mapping requests, but this drew complaints when compared against the =20 similar UPnP IGD function in competing products.) The distinction that makes all the difference in both these cases is =20 that endpoint nodes are required to solicit the firewall before =20 inbound flow initiations will be delivered. With unfiltered IPv6, =20 those flow initiations pass unimpeded whether the endpoint nodes =20 requests them or not. It's the presence of *unsolicited* traffic on =20 the local network that raises all the security concerns. Strange, =20 but true. So, yes-- you actually need to tell your firewalls what you want to =20 receive. Firewalls want to know about all your listening sockets, =20 and they expect you to comply with policy. If they don't approve of =20 what you're doing, then you don't get service. That's how the world =20 works, bunky. Cope. As a result, the design for an IPv6 functional equivalent of NAT-PMP =20 and UPnP IGD will have to rely on endpoint nodes explicitly =20 soliciting firewalls when they initiate a passive communication =20 endpoint. Now, I think that endpoint nodes should do this by sending =20= unicast ICMP messages to firewalls they learn about using a multicast =20= discovery protocol, but others are still resisting the idea. They =20 think the discovery part is too complicated, and that firewalls =20 should just encapsulate inbound flow initiations in ICMP messages =20 that would otherwise be dropped for being unsolicited. I think =20 encapsulation will peeve network administrators who are expecting =20 firewalls not to pass unsolicited inbound packets. Accordingly, I'm =20 proceeding with designs for an application listener discovery =20 protocol, that allows endpoints to discover firewalls and solicit the =20= state required to pass inbound flow initiations. It's a curious problem. What do people here think? -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 17:28: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 1HdvDb-0005ii-4O; Tue, 17 Apr 2007 17:28:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdvDa-0005i0-1u for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 17:28:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdvDZ-0005hr-OW for behave@ietf.org; Tue, 17 Apr 2007 17:28:05 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdvDY-000055-E2 for behave@ietf.org; Tue, 17 Apr 2007 17:28:05 -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.685.24; Tue, 17 Apr 2007 14:28:03 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Tue, 17 Apr 2007 14:28:01 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Apr 2007 14:28:00 -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] soliciting firewalls for inbound flows Date: Tue, 17 Apr 2007 14:27:36 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064043E3569@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <47ED8FFB-10B7-4E36-9D67-C140A9D08289@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] soliciting firewalls for inbound flows Thread-Index: AceBMQAbRp45gPlvSR2mvI8SLwzFigABKTcQ References: <011b01c77d2d$ed1587c0$c4f0200a@amer.cisco.com><200704171410.27677.remi.denis-courmont@nokia.com> <47ED8FFB-10B7-4E36-9D67-C140A9D08289@apple.com> From: Christian Huitema To: james woodyatt , IETF BEHAVE WG X-OriginalArrivalTime: 17 Apr 2007 21:28:00.0535 (UTC) FILETIME=[46435270:01C78137] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 > But, there's a problem. You actually need to tell the firewall what =20 > you want to receive. Yes, that is a real problem. There are two classes of solutions: requiring port openings though an explicit signaling protocol between the host and the firewall; or using a side effect of the firewall design to let the connection go through without explicit exchange.=20 STUN/ICE is an example of the second class of solutions. Hosts can use STUN to determine their external IPv4 address and UDP port numbers. They can then exchange these addresses through some external service, e.g. a SIP exchange or an IM service. Then, they send a couple of sacrificial packets to open the firewall or NAT at each side. After that, UDP packets flow freely. It is fairly easy to see how the same solutions could apply to IPv6/UDP, without even a need for STUN. In fact, with IPv6, you might even be able to use simultaneous connect and set up TCP connections. You still need to explicitly open holes if you want to provide generic servers, e.g. open port 80 if you want to run a web server in your home network. But my experience is that solutions that don't involve signaling protocols are much easier to deploy. -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 18:54:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdwYo-00083z-Tb; Tue, 17 Apr 2007 18:54:06 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdwYo-00083u-4A for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 18:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdwYn-00083m-Qr for behave@ietf.org; Tue, 17 Apr 2007 18:54:05 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdwYn-0005m8-IH for behave@ietf.org; Tue, 17 Apr 2007 18:54:05 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3HMs1OI011479; Tue, 17 Apr 2007 18:54:01 -0400 (EDT) Received: from [128.30.5.245] (30-5-245.wireless.csail.mit.edu [128.30.5.245]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3HMs0jP016358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 18:54:00 -0400 (EDT) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064043E3569@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <011b01c77d2d$ed1587c0$c4f0200a@amer.cisco.com><200704171410.27677.remi.denis-courmont@nokia.com> <47ED8FFB-10B7-4E36-9D67-C140A9D08289@apple.com> <70C6EFCDFC8AAD418EF7063CD132D064043E3569@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: From: Bryan Ford Subject: Re: [BEHAVE] soliciting firewalls for inbound flows Date: Tue, 17 Apr 2007 18:53:59 -0400 To: Christian Huitema X-Mailer: Apple Mail (2.752.3) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF 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 Apr 17, 2007, at 5:27 PM, Christian Huitema wrote: >> But, there's a problem. You actually need to tell the firewall what >> you want to receive. > > Yes, that is a real problem. There are two classes of solutions: > requiring port openings though an explicit signaling protocol between > the host and the firewall; or using a side effect of the firewall > design > to let the connection go through without explicit exchange. > > STUN/ICE is an example of the second class of solutions. [...] Unfortunately, this "second class of solutions" (implicit hole punching) is and will forever be inadequate to solve the needs of many applications, because of the BEHAVE group's decision a while ago to recommend endpoint-dependent filtering behavior (Restricted Cone NAT in the old terminology) as the default behavior for all NATs. Some may remember me fighting tooth and nail some time ago, both on the BEHAVE mailing list and at the IETF meeting in Paris, in favor of recommending endpoint-independent filtering behavior (Full Cone NAT) as the default filtering behavior unless local security policy dictates otherwise. Doing so would have given applications the functionality they need through implicit hole punching - namely, the ability to open a firewall pinhole through which they may accept new incoming connections without the (further) help of an external third party. But by deciding in favor of endpoint-dependent filtering, the BEHAVE group effectively castrated the usefulness of implicit hole punching (STUN/ICE) techniques for any application that actually needs a public network port on which it can accept new incoming connections without help from an external third party. Many such applications exist - including practically all self-organizing P2P- style protocols such as distributed hash tables for example. (Some smart applications like Skype can and do get by - for now - by dividing the participating nodes into "first-class" (e.g., supernodes) that can accept incoming connections, and "second-class" nodes that cannot. But as the percentage of nodes behind BEHAVE- compliant middleboxes with endpoint-dependent filtering behavior tends toward 100% in the future, the small set of "first-class" nodes available to help the increasingly numerous "second-class" nodes punch the connections they require will diminish toward zero, gradually overloading the first-class nodes and eventually causing even these smart protocols to fail unless someone bolsters the network with a bunch of dedicated first-class servers.) Since self-organizing applications cannot now, and because of the BEHAVE group's decision, will never be able to rely on implicit hole punching to get the type of firewall pinholes they need, their only alternative is to rely on some form of explicit communication with the firewall - i.e., something like NAT-PMP. So unless this group wants to reverse that decision (I know, fat chance), an IPv6 functional equivalent to NAT-PMP is needed now and will continue to be needed forever (or at least as long as firewalls continue to exist), so we might as well get comfortable with the idea. Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 18:57: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 1HdwcC-0002NY-GN; Tue, 17 Apr 2007 18:57:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdwcA-0002NT-7O for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 18:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdwc9-0002NL-U1 for behave@ietf.org; Tue, 17 Apr 2007 18:57:33 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdwc8-0006sg-Io for behave@ietf.org; Tue, 17 Apr 2007 18:57:33 -0400 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3HMvVDG013521 for ; Tue, 17 Apr 2007 15:57:31 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 672E6404E3 for ; Tue, 17 Apr 2007 15:57:31 -0700 (PDT) X-AuditID: 11807126-a0550bb0000007ff-1b-462550db1092 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay8.apple.com (Apple SCV relay) with ESMTP id 556DE40470 for ; Tue, 17 Apr 2007 15:57:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064043E3569@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <011b01c77d2d$ed1587c0$c4f0200a@amer.cisco.com> <200704171410.27677.remi.denis-courmont@nokia.com> <47ED8FFB-10B7-4E36-9D67-C140A9D08289@apple.com> <70C6EFCDFC8AAD418EF7063CD132D064043E3569@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] soliciting firewalls for inbound flows Date: Tue, 17 Apr 2007 15:57:27 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Apr 17, 2007, at 14:27, Christian Huitema wrote: > > You still need to explicitly open holes if you want to provide generic > servers, e.g. open port 80 if you want to run a web server in your > home > network. Yes. The STUN/ICE class of solutions depends on there being a well- defined behavior for stateful IPv6 packet filters. They also require peer-to-peer applications to rely on some external 3rd-party service to participate in the signaling required to exploit the side effect in firewalls. > But my experience is that solutions that don't involve signaling > protocols are much easier to deploy. I might be in a better position than you to deploy something that does what I'm proposing. Also: I disagree with the characterization of my proposal as a "signaling" protocol. It's an "application listener discovery" protocol for firewalls. I contend that application endpoints receiving inbound flows ought to be just as visible to the policy enforcement engines in firewalls as those that initiate outbound flows. I don't see why this should be a controversial proposal. It needn't even be a required feature of IPv6 nodes. Nodes that don't support "application listener discovery" will simply not be able to receive inbound flows on networks where one or more firewalls require nodes to solicit them explicitly. They will still continue to function normally on networks where no such discovery is necessary (in the increasingly unlikely event such networks ever exist in the real world). -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 19:33: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 1HdxBK-0004rV-Kf; Tue, 17 Apr 2007 19:33:54 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdxBJ-0004rQ-TP for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 19:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdxBJ-0004rI-K0 for behave@ietf.org; Tue, 17 Apr 2007 19:33:53 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdxBH-0000xC-0Y for behave@ietf.org; Tue, 17 Apr 2007 19:33:53 -0400 Received: from Quinthar ([68.26.110.112]) by quinthar.com for ; Tue, 17 Apr 2007 16:33:45 -0700 From: "David Barrett" To: "'Bryan Ford'" , "'Christian Huitema'" Date: Tue, 17 Apr 2007 16:33:23 -0700 Message-ID: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> 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: AceBQ1AZux0A7qyNRYy68povtosB+wAAJ98Q In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'IETF BEHAVE WG' Subject: [BEHAVE] Endpoint-independent filtering is the way to go. 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: Bryan Ford [mailto:baford@MIT.EDU] > > ... because of the BEHAVE group's decision a while ago > to recommend endpoint-dependent filtering behavior (Restricted Cone > NAT in the old terminology) as the default behavior for all NATs. Oh, wow, seriously? I completely agree with Bryan on this one. Endpoint-independent is the only sensible solution, unless BEHAVE is actively seeking to make the internet inhospitable to self-organizing P2P clouds (like Skype or P2P-SIP). Can anyone summarize for me (off list) why we made this disastrous decision? Alternatively, can anyone offer any pointers back into the list archive as to when this decision was made so I can catch up on the reasoning? The best I can find is this, from 2005: http://list.sipfoundry.org/archive/ietf-behave/msg00696.html In that thread, at least, it doesn't sound like a decision was made, though everybody but Cullen seemed in favor of endpoint-dependent. Indeed, I've yet to see any actual P2P developer come out against endpoint-independent (and as the lead P2P developer at Akamai, I can unquestionably say I support endpoint-independent filtering by default). -david (hoping to not derail the discussion) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 19:44: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 1HdxLO-0002e6-3c; Tue, 17 Apr 2007 19:44:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdxLN-0002aj-E7 for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 19:44:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdxLN-0002aC-4Q for behave@ietf.org; Tue, 17 Apr 2007 19:44:17 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdxLL-0006tR-Ql for behave@ietf.org; Tue, 17 Apr 2007 19:44:17 -0400 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3HNiDLM021081 for ; Tue, 17 Apr 2007 16:44:13 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 3C03829C005 for ; Tue, 17 Apr 2007 16:44:13 -0700 (PDT) X-AuditID: 11807123-9e3e6bb000000b42-c2-46255bcda13f Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay5.apple.com (Apple SCV relay) with ESMTP id 2F57E30400D for ; Tue, 17 Apr 2007 16:44:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] Endpoint-independent filtering is the way to go. Date: Tue, 17 Apr 2007 16:44:08 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Apr 17, 2007, at 16:33, David Barrett wrote: > > Oh, wow, seriously? I completely agree with Bryan on this one. > Endpoint-independent is the only sensible solution, unless BEHAVE is > actively seeking to make the internet inhospitable to self- > organizing P2P > clouds (like Skype or P2P-SIP). [...] Apple's AirPort base station products have always done endpoint- independent mapping since their first generation was introduced over five years ago. This was quite deliberate, and I doubt Apple will reverse that decision unless it receives pressure from the community of Internet security experts. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 20:53: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 1HdyQT-00058N-Tz; Tue, 17 Apr 2007 20:53:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdyQS-0004zc-IU for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 20:53:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdyQS-0004xr-8A for behave@ietf.org; Tue, 17 Apr 2007 20:53:36 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdyQP-0007NN-TT for behave@ietf.org; Tue, 17 Apr 2007 20:53:35 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3I0rUFW010548; Tue, 17 Apr 2007 20:53:30 -0400 (EDT) Received: from [192.168.1.106] (pool-151-199-61-176.bos.east.verizon.net [151.199.61.176]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3I0rSQN010011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 20:53:29 -0400 (EDT) In-Reply-To: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: From: Bryan Ford Date: Tue, 17 Apr 2007 20:53:26 -0400 To: "David Barrett" X-Mailer: Apple Mail (2.752.3) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'IETF BEHAVE WG' Subject: [BEHAVE] Re: Endpoint-independent filtering is the way to go. 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 Apr 17, 2007, at 7:33 PM, David Barrett wrote: >> -----Original Message----- >> From: Bryan Ford [mailto:baford@MIT.EDU] >> >> ... because of the BEHAVE group's decision a while ago >> to recommend endpoint-dependent filtering behavior (Restricted Cone >> NAT in the old terminology) as the default behavior for all NATs. > > Oh, wow, seriously? I completely agree with Bryan on this one. > Endpoint-independent is the only sensible solution, unless BEHAVE is > actively seeking to make the internet inhospitable to self- > organizing P2P > clouds (like Skype or P2P-SIP). > > Can anyone summarize for me (off list) why we made this disastrous > decision? > Alternatively, can anyone offer any pointers back into the list > archive as > to when this decision was made so I can catch up on the reasoning? > The best > I can find is this, from 2005: > > http://list.sipfoundry.org/archive/ietf-behave/msg00696.html That was indeed part of this very long discussion thread - it might be a bit difficult to trace, because the discussion of this topic was mixed with discussion of several other issues that I and others brought up in response to the (first) "last call" for the BEHAVE UDP draft. The message you point to is actually pretty late in the discussion, after I had already given up hope that the working group would agree to a direct recommendation that NATs "SHOULD implement endpoint-independent filtering behavior" and fell back on fighting for a recommendation that NATs at least "SHOULD _allow the user_ to configure them to enable endpoint-independent filtering behavior". But others in the group objected strongly even to that, and it finally came down to the August 2005 IETF meeting in Paris, whose minutes you can find here: http://www3.ietf.org/proceedings/05aug/index.html Basically, I ended up being the only one in the whole (pretty fully) room advocating even that relatively weak language, recommending that users even be allowed to configure their NATs for endpoint- independent filtering behavior. So I gave up and let the group do what they wanted to. In retrospect, I should have asked for a show of hands indicating who in the room represented (a) a NAT/firewall vendor, (b) a vendor of centralized VoIP infrastructure, and (c) a developer of self- organizing P2P applications or protocols. I suspect practically everyone there was in either category (a) or (b). Or if anyone else there was representing category (c), they didn't understand the practical implications of the decision being made. I agree, I still think the decision was disastrous, but what could I do? Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 21:05:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdycD-0003LO-2z; Tue, 17 Apr 2007 21:05:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdycB-0003Iz-7l for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 21:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdycA-0003Ir-UO for behave@ietf.org; Tue, 17 Apr 2007 21:05:42 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdyc9-0001tM-Li for behave@ietf.org; Tue, 17 Apr 2007 21:05:42 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 17 Apr 2007 18:05:40 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Tue, 17 Apr 2007 18:05:40 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Apr 2007 18:05:39 -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 Date: Tue, 17 Apr 2007 18:04:58 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D06404478FFD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Endpoint-independent filtering is the way to go. Thread-Index: AceBVAczNF5xj+XUTYmhnvMzsOsr2gAAXZVg References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> From: Christian Huitema To: Bryan Ford , David Barrett X-OriginalArrivalTime: 18 Apr 2007 01:05:39.0761 (UTC) FILETIME=[AE2B1210:01C78155] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF BEHAVE WG Subject: [BEHAVE] RE: Endpoint-independent filtering is the way to go. 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 agree, I still think the decision was disastrous, but what could I do? Design your applications for the network you have, not the network you wish you have. -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 21:08:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdyf7-0005N8-52; Tue, 17 Apr 2007 21:08:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hdyf6-0005N3-KA for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 21:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdyf6-0005Ms-AZ for behave@ietf.org; Tue, 17 Apr 2007 21:08:44 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdyf6-0004Ib-31 for behave@ietf.org; Tue, 17 Apr 2007 21:08:44 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3I18fei018310; Tue, 17 Apr 2007 21:08:42 -0400 (EDT) Received: from [192.168.1.106] (pool-151-199-61-176.bos.east.verizon.net [151.199.61.176]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3I18e8g013450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 21:08:41 -0400 (EDT) In-Reply-To: <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D6481C8-64BC-4F13-8158-F2DD2147ED42@mit.edu> From: Bryan Ford Subject: Re: [BEHAVE] Endpoint-independent filtering is the way to go. Date: Tue, 17 Apr 2007 21:08:35 -0400 To: james woodyatt X-Mailer: Apple Mail (2.752.3) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF 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 Apr 17, 2007, at 7:44 PM, james woodyatt wrote: > On Apr 17, 2007, at 16:33, David Barrett wrote: >> >> Oh, wow, seriously? I completely agree with Bryan on this one. >> Endpoint-independent is the only sensible solution, unless BEHAVE is >> actively seeking to make the internet inhospitable to self- >> organizing P2P >> clouds (like Skype or P2P-SIP). [...] > > Apple's AirPort base station products have always done endpoint- > independent mapping since their first generation was introduced > over five years ago. This was quite deliberate, and I doubt Apple > will reverse that decision unless it receives pressure from the > community of Internet security experts. Bravo. I have yet to see one anyone come up with single shred of concrete evidence that endpoint-dependent filtering actually increases security in any practical way. For example, if someone in the security community could point out ONE SINGLE real security vulnerability that EVER existed in ANY application/OS combination at ANY time in the past, which WAS remotely exploitable if the host was behind a firewall with endpoint-independent filtering, but WAS NOT exploitable if the firewall had implemented endpoint-dependent filtering, then I might be tempted to rethink my position. Given the number of Windows exploits in the history of the world, one would imagine an example could be found if there was one. But as far as I have been able to tell the case for endpoint-dependent filtering is nothing but FUD. And so instead of trying to fulfill its charter and do something to defend the basic principles the Internet was built on, the BEHAVE group just rolled over and played dead. Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 21:15: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 1HdylY-0007ao-95; Tue, 17 Apr 2007 21:15:24 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdylX-0007ah-FJ for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 21:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdylX-0007aZ-5p for behave@ietf.org; Tue, 17 Apr 2007 21:15:23 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdylV-0006cB-V9 for behave@ietf.org; Tue, 17 Apr 2007 21:15:23 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3I1FKXv022262; Tue, 17 Apr 2007 21:15:21 -0400 (EDT) Received: from [192.168.1.106] (pool-151-199-61-176.bos.east.verizon.net [151.199.61.176]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3I1FJYK015080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 21:15:20 -0400 (EDT) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06404478FFD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D06404478FFD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51B04916-8659-4469-AE3F-0AFD64D84EB0@MIT.EDU> From: Bryan Ford Date: Tue, 17 Apr 2007 21:15:17 -0400 To: Christian Huitema X-Mailer: Apple Mail (2.752.3) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF BEHAVE WG Subject: [BEHAVE] Re: Endpoint-independent filtering is the way to go. 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 Apr 17, 2007, at 9:04 PM, Christian Huitema wrote: >> I agree, I still think the decision was disastrous, but what could I > do? > > Design your applications for the network you have, not the network you > wish you have. That's what I do, and what any intelligent P2P application/protocol designer does. The problem is that the BEHAVE group's decision, if followed by the industry, makes that task ever more difficult over time, asymptotically approaching impossible (as we run out of first- class nodes able to accept incoming connections). The right decision, in contrast, would have made the task easier over time, asymptotically approaching trivial. Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 21:32: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 1Hdz28-0005RR-2f; Tue, 17 Apr 2007 21:32:32 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hdz27-0005RM-6J for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 21:32:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdz26-0005RE-T3 for behave@ietf.org; Tue, 17 Apr 2007 21:32:30 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdz25-00049O-Iz for behave@ietf.org; Tue, 17 Apr 2007 21:32:30 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3I1WQh5001598 for ; Tue, 17 Apr 2007 18:32:26 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id C270C30003 for ; Tue, 17 Apr 2007 18:32:26 -0700 (PDT) X-AuditID: 11807125-a1322bb0000007e5-6a-4625752aa94b Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay7.apple.com (Apple SCV relay) with ESMTP id AF54E3005D for ; Tue, 17 Apr 2007 18:32:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06404478FFD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D06404478FFD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <044DE227-842A-4693-B35C-62B503C1D093@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Tue, 17 Apr 2007 18:32:22 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Apr 17, 2007, at 18:04, Christian Huitema wrote: > > Design your applications for the network you have, not the network > you wish you have. I wish IETF could keep from designing new and interesting ways for the Internet to break the applications we have, not to mention the applications we wish we could have. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 21:56: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 1HdzP9-0004pC-09; Tue, 17 Apr 2007 21:56:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdzP8-0004p7-2S for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 21:56:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdzP7-0004oz-PJ for behave@ietf.org; Tue, 17 Apr 2007 21:56:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzOD-0004RK-GT for behave@ietf.org; Tue, 17 Apr 2007 21:55:21 -0400 Received: from smtp3.akamai.com ([63.116.109.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdzOC-0002N7-7l for behave@ietf.org; Tue, 17 Apr 2007 21:55:21 -0400 Received: from smtp3.akamai.com (vwall1.sanmateo.corp.akamai.com [172.23.1.71]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3I1tT0O028127 for ; Tue, 17 Apr 2007 18:55:29 -0700 (PDT) Received: from USCA1EX-GATE1.sanmateo.corp.akamai.com (usca1ex-gate1.sanmateo.corp.akamai.com [172.23.1.110]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3I1tT4T028124 for ; Tue, 17 Apr 2007 18:55:29 -0700 (PDT) Received: from CAVS1.sanmateo.corp.akamai.com ([172.23.1.125]) by USCA1EX-GATE1.sanmateo.corp.akamai.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 18:59:12 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 17 Apr 2007 18:55:18 -0700 Message-ID: <38464B16719C77439C06051F392AB9E6062EB2EB@CAVS1.sanmateo.corp.akamai.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Endpoint-independent filtering is the way to go. Thread-Index: AceBXJ2jVab3CxUASoip+lrYJgBNeg== From: "Barrett, David" To: X-OriginalArrivalTime: 18 Apr 2007 01:59:12.0890 (UTC) FILETIME=[2957A5A0:01C7815D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-TMDA-Confirmed: Tue, 17 Apr 2007 21:56:17 -0400 Subject: [BEHAVE] RE: Endpoint-independent filtering is the way to go. 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: Bryan Ford [mailto:baford@MIT.EDU] >=20 > Basically, I ended up being the only one in the whole (pretty fully) > room advocating even that relatively weak language, recommending that > users even be allowed to configure their NATs for endpoint- > independent filtering behavior. So I gave up and let the group do > what they wanted to. Cullen -- Is it safe to say that the consensus of the BEHAVE group is = the benefit offered by decentralized overlay networks (eg, DHTs) are = outweighed by the security risks of endpoint-independent mapping? Given that the IETF-chartered P2P-SIP folks are actively building a DHT = that requires a high fraction of endpoint-independent filtered nodes, = shouldn't we inform them that we're on a collision course and they need = to redesign as a result? -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 17 22:09: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 1HdzcG-0004pk-Tm; Tue, 17 Apr 2007 22:09:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HdzcE-0004mu-RB for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 22:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzcE-0004mk-GK for behave@ietf.org; Tue, 17 Apr 2007 22:09:50 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdzbv-00088l-Oz for behave@ietf.org; Tue, 17 Apr 2007 22:09:33 -0400 Received: by py-out-1112.google.com with SMTP id f31so4554pyh for ; Tue, 17 Apr 2007 19:09:31 -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=a0fH65kbuhHY1YlsS3XVtVNwtgh7NyluvuoKc33081QUjxydjNUyKyiwxu/2xYHFfAcH3r2ygICpeFL6bBU2ZcAPHdbyPoQWHuaoX5kK+jGAPOvdJph2KmQbMjvTHOO9xMUNut+l0WxQGT29BaMRWwlxAAD2Egtay2ywpNliq74= 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=CcUPQH0AqU9EQrg7GBPZr0EU3t7xOqepP13TtQw6kOdWiQXBzDSn+6IrgBGR6op3jxqlfIW6+GOVKzMCpJQncm52ySPMBAV50qzGviGPbwpPE18OVmprcFQ1gC1JeqHDqug58ErRzOn4eOjQKI926+6RaTQiLIxDcgk8HEmP2rw= Received: by 10.35.66.1 with SMTP id t1mr22699pyk.1176862171355; Tue, 17 Apr 2007 19:09:31 -0700 (PDT) Received: by 10.35.107.17 with HTTP; Tue, 17 Apr 2007 19:09:31 -0700 (PDT) Message-ID: <20d2bdfb0704171909j2f8e56f6q9bf335dddc3bc154@mail.gmail.com> Date: Tue, 17 Apr 2007 22:09:31 -0400 From: "Bruce Lowekamp" To: "Barrett, David" Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. In-Reply-To: <38464B16719C77439C06051F392AB9E6062EB2EB@CAVS1.sanmateo.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <38464B16719C77439C06051F392AB9E6062EB2EB@CAVS1.sanmateo.corp.akamai.com> X-Google-Sender-Auth: bef766c34498e2f6 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 I just posted a similar reply to the same topic on the p2psip list, but since it's in two places, here is the actual text from 4787: REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. For one proposed solution for p2psip (or similar) applications, see draft-matthews-p2psip-dsip-nat-traversal (I personally prefer endpoint independent filtering, but there are lots of ways for protocols to work with dependent filtering.) Bruce On 4/17/07, Barrett, David wrote: > > -----Original Message----- > > From: Bryan Ford [mailto:baford@MIT.EDU] > > > > Basically, I ended up being the only one in the whole (pretty fully) > > room advocating even that relatively weak language, recommending that > > users even be allowed to configure their NATs for endpoint- > > independent filtering behavior. So I gave up and let the group do > > what they wanted to. > > Cullen -- Is it safe to say that the consensus of the BEHAVE group is the benefit offered by decentralized overlay networks (eg, DHTs) are outweighed by the security risks of endpoint-independent mapping? > > Given that the IETF-chartered P2P-SIP folks are actively building a DHT that requires a high fraction of endpoint-independent filtered nodes, shouldn't we inform them that we're on a collision course and they need to redesign as a result? > > -david > > > > _______________________________________________ > 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 Tue Apr 17 22:32: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 1Hdzxg-0007OQ-No; Tue, 17 Apr 2007 22:32:00 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hdzxf-0007OL-Lx for behave-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 22:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdzxf-0007OD-CW for behave@ietf.org; Tue, 17 Apr 2007 22:31:59 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdzxd-0004EP-T5 for behave@ietf.org; Tue, 17 Apr 2007 22:31:59 -0400 Received: from Quinthar ([68.26.248.105]) by quinthar.com for ; Tue, 17 Apr 2007 19:31:55 -0700 From: "David Barrett" To: "'Bryan Ford'" Date: Tue, 17 Apr 2007 19:31:46 -0700 Message-ID: <02bd01c78161$b83c0320$6f02a8c0@Quinthar> 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: AceBVAHAGvtx3MEOSyKjrzXJhkOKzgADXGkQ In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'IETF BEHAVE WG' Subject: [BEHAVE] RE: Endpoint-independent filtering is the way to go. 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, now that I read the RFC as suggested by Bruce, REQ 8 doesn't appear to recommend endpoint-dependent filtering by default. Bryan -- Am I misreading this? Why are you saying that it's recommending endpoint-dependent filtering by default? -david > -----Original Message----- > From: Bryan Ford [mailto:baford@MIT.EDU] > Sent: Tuesday, April 17, 2007 5:53 PM > To: David Barrett > Cc: 'Christian Huitema'; 'IETF BEHAVE WG' > Subject: Re: Endpoint-independent filtering is the way to go. > > On Apr 17, 2007, at 7:33 PM, David Barrett wrote: > > >> -----Original Message----- > >> From: Bryan Ford [mailto:baford@MIT.EDU] > >> > >> ... because of the BEHAVE group's decision a while ago > >> to recommend endpoint-dependent filtering behavior (Restricted Cone > >> NAT in the old terminology) as the default behavior for all NATs. > > > > Oh, wow, seriously? I completely agree with Bryan on this one. > > Endpoint-independent is the only sensible solution, unless BEHAVE is > > actively seeking to make the internet inhospitable to self- > > organizing P2P > > clouds (like Skype or P2P-SIP). > > > > Can anyone summarize for me (off list) why we made this disastrous > > decision? > > Alternatively, can anyone offer any pointers back into the list > > archive as > > to when this decision was made so I can catch up on the reasoning? > > The best > > I can find is this, from 2005: > > > > http://list.sipfoundry.org/archive/ietf-behave/msg00696.html > > That was indeed part of this very long discussion thread - it might > be a bit difficult to trace, because the discussion of this topic was > mixed with discussion of several other issues that I and others > brought up in response to the (first) "last call" for the BEHAVE UDP > draft. The message you point to is actually pretty late in the > discussion, after I had already given up hope that the working group > would agree to a direct recommendation that NATs "SHOULD implement > endpoint-independent filtering behavior" and fell back on fighting > for a recommendation that NATs at least "SHOULD _allow the user_ to > configure them to enable endpoint-independent filtering behavior". > But others in the group objected strongly even to that, and it > finally came down to the August 2005 IETF meeting in Paris, whose > minutes you can find here: > > http://www3.ietf.org/proceedings/05aug/index.html > > Basically, I ended up being the only one in the whole (pretty fully) > room advocating even that relatively weak language, recommending that > users even be allowed to configure their NATs for endpoint- > independent filtering behavior. So I gave up and let the group do > what they wanted to. > > In retrospect, I should have asked for a show of hands indicating who > in the room represented (a) a NAT/firewall vendor, (b) a vendor of > centralized VoIP infrastructure, and (c) a developer of self- > organizing P2P applications or protocols. I suspect practically > everyone there was in either category (a) or (b). Or if anyone else > there was representing category (c), they didn't understand the > practical implications of the decision being made. > > I agree, I still think the decision was disastrous, but what could I do? > > Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 00:09:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He1TX-0008DZ-I5; Wed, 18 Apr 2007 00:08:59 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He1TW-0008DU-JC for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 00:08:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He1TW-0008DM-9P for behave@ietf.org; Wed, 18 Apr 2007 00:08:58 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He1TU-0002mB-R3 for behave@ietf.org; Wed, 18 Apr 2007 00:08:58 -0400 Received: by wx-out-0506.google.com with SMTP id h31so31804wxd for ; Tue, 17 Apr 2007 21:08:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=lnUxJ8eERHKWBBOaXhs2Ul5oX6rP6FqCy9IZdTkynNAohgsBG1/5wqoKfTCBp61WYNVJgbzX7Tb/y+WAvLFeryeBCOLaCfCaK/SqlsgcNb0wSLFMTBaUzrP0I5N1qdLD1QSavstwkwIClw4CY8MtaXyJUYJ9n04C27nLZsJb62o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=ULbZ8Pjb8XK5wOIIPniFodzNEh0K47uryj5SRpzEt33x6JI3pXbZ0ZyHQqydkDAPHdFY8jhoxfy1fpN5hExBCzF4u5TIBPe+dRoqXea4tQPdHzrUCLH+dXaBG2qcBrZgBRueZzUxBHwm/rq9Z6SLkEo75kkkOsVdzxlMvMl+Pvc= Received: by 10.67.36.6 with SMTP id o6mr949443ugj.1176869335859; Tue, 17 Apr 2007 21:08:55 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTP id y6sm559860mug.2007.04.17.21.08.53; Tue, 17 Apr 2007 21:08:55 -0700 (PDT) Message-ID: <462599F1.2050102@gmail.com> Date: Wed, 18 Apr 2007 14:09:21 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [BEHAVE] TCP framing in TURN 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 draft-ietf-behave-turn-03.txt, para 5: "The first octet of this framing is 0x02 to indicate STUN messages or 0x03 to indicate end-to-end data to or from the active destination. Note that the first octet is always distinguishable from an unframed STUN request or response (which is always 0x00 or 0x01)." Could you explain me why do you need to additionaly frame STUN messages since all STUN messages have always 0x00 or 0x01 in their first octet and we can simply distinguish them from the end-to-end data frame? Am I misreading something? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 02:42: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 1He3rv-0004eU-Rq; Wed, 18 Apr 2007 02:42:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He3ru-0004X5-Jc for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 02:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He3ru-0004Up-5x for behave@ietf.org; Wed, 18 Apr 2007 02:42:18 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He3rs-0007vb-SM for behave@ietf.org; Wed, 18 Apr 2007 02:42:18 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 17 Apr 2007 23:42:16 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Tue, 17 Apr 2007 23:42:15 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Apr 2007 23:42:15 -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: Endpoint-independent filtering is the way to go. Date: Tue, 17 Apr 2007 23:41:22 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <044DE227-842A-4693-B35C-62B503C1D093@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Thread-Index: AceBWXWzxeRN8txhRR6Gb8tBQF2QugAKgAkw References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar><70C6EFCDFC8AAD418EF7063CD132D06404478FFD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <044DE227-842A-4693-B35C-62B503C1D093@apple.com> From: Christian Huitema To: "james woodyatt" , "IETF BEHAVE WG" X-OriginalArrivalTime: 18 Apr 2007 06:42:15.0616 (UTC) FILETIME=[B3D5FC00:01C78184] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 > > Design your applications for the network you have, not the network > > you wish you have. >=20 > I wish IETF could keep from designing new and interesting ways for > the Internet to break the applications we have, not to mention the > applications we wish we could have. Yep. The problem, however, is not so much the IETF as the lack of industry agreed rules on what constitutes a "good" router. We (Microsoft) are trying to address that. The test program available at http://www.microsoft.com/windows/using/tools/igd/default.mspx checks for common bugs in home routers (aka Internet Gateway Devices, IGD). Endpoint independent mapping would be considered one such bug. Routers are supposed to pass these tests if they want to show the "designed for Vista" logo. A router that exhibits endpoint independent mapping or "symmetric NAT" behavior would not get this logo. -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 02:55: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 1He44o-0000lv-0b; Wed, 18 Apr 2007 02:55:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He44m-0000kv-1q for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 02:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He44i-0000jR-Uz for behave@ietf.org; Wed, 18 Apr 2007 02:55:32 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He44h-0005wm-Gc for behave@ietf.org; Wed, 18 Apr 2007 02:55:32 -0400 Received: from Quinthar ([67.169.180.240]) by quinthar.com for ; Tue, 17 Apr 2007 23:55:22 -0700 From: "David Barrett" To: "'Christian Huitema'" , "'james woodyatt'" , "'IETF BEHAVE WG'" Subject: RE: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Tue, 17 Apr 2007 23:55:15 -0700 Message-ID: <008201c78186$85487eb0$75240046@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceBWXWzxeRN8txhRR6Gb8tBQF2QugAKgAkwAACmRlA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Just curious, what sort of requirements does your tool make for filtering? Does it allow for both endpoint-dependent and -independent filtering? -david > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, April 17, 2007 11:41 PM > To: james woodyatt; IETF BEHAVE WG > Subject: RE: [BEHAVE] RE: Endpoint-independent filtering is the way to go. > > > > Design your applications for the network you have, not the network > > > you wish you have. > > > > I wish IETF could keep from designing new and interesting ways for > > the Internet to break the applications we have, not to mention the > > applications we wish we could have. > > Yep. The problem, however, is not so much the IETF as the lack of > industry agreed rules on what constitutes a "good" router. We > (Microsoft) are trying to address that. The test program available at > http://www.microsoft.com/windows/using/tools/igd/default.mspx checks for > common bugs in home routers (aka Internet Gateway Devices, IGD). > Endpoint independent mapping would be considered one such bug. Routers > are supposed to pass these tests if they want to show the "designed for > Vista" logo. A router that exhibits endpoint independent mapping or > "symmetric NAT" behavior would not get this logo. > > -- Christian Huitema > > > > > _______________________________________________ > 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 Apr 18 03:01: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 1He4Ap-0001Nx-Qb; Wed, 18 Apr 2007 03:01:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He4Ao-0001Ns-FP for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 03:01:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4Ao-0001Ng-4h for behave@ietf.org; Wed, 18 Apr 2007 03:01:50 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He4Am-0000QT-Si for behave@ietf.org; Wed, 18 Apr 2007 03:01:50 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 18 Apr 2007 00:01:48 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Wed, 18 Apr 2007 00:01:47 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Apr 2007 00:01:47 -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: Endpoint-independent filtering is the way to go. Date: Wed, 18 Apr 2007 00:01:41 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <008201c78186$85487eb0$75240046@Quinthar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Thread-Index: AceBWXWzxeRN8txhRR6Gb8tBQF2QugAKgAkwAACmRlAAAD82gA== References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <008201c78186$85487eb0$75240046@Quinthar> From: Christian Huitema To: "David Barrett" , "james woodyatt" , "IETF BEHAVE WG" X-OriginalArrivalTime: 18 Apr 2007 07:01:47.0918 (UTC) FILETIME=[6E9512E0:01C78187] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 > Just curious, what sort of requirements does your tool make for > filtering? > Does it allow for both endpoint-dependent and -independent filtering? We allow for both. Our P2P apps work through endpoint-dependent filtering routers. Some use ICE like mechanisms, other use IPv6 over Teredo. -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 03:37:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4iy-00054c-IK; Wed, 18 Apr 2007 03:37:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He4iw-00052U-P6 for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 03:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4iv-00051C-5d for behave@ietf.org; Wed, 18 Apr 2007 03:37:05 -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 1He4it-0004tN-Ld for behave@ietf.org; Wed, 18 Apr 2007 03:37:05 -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 l3I7aAtU028967; Wed, 18 Apr 2007 10:36:46 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:36:30 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:36:30 +0300 Received: from esdhcp04141.research.nokia.com (esdhcp04141.research.nokia.com [172.21.41.41]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3I7aMdH009125; Wed, 18 Apr 2007 10:36:24 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Wed, 18 Apr 2007 10:36:21 +0300 User-Agent: KMail/1.9.6 References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <008201c78186$85487eb0$75240046@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704181036.22016.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 18 Apr 2007 07:36:30.0486 (UTC) FILETIME=[47E3BB60:01C7818C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Wednesday 18 April 2007 10:01:41 ext Christian Huitema wrote: > > Just curious, what sort of requirements does your tool make for > > filtering? > > Does it allow for both endpoint-dependent and -independent filtering? > > We allow for both. Our P2P apps work through endpoint-dependent > filtering routers. Some use ICE like mechanisms, other use IPv6 over > Teredo. But then there is always the need for some rendez-vous point that is not=20 firewalled (SIP registrar, Teredo server...). Not that I consider this a=20 problem myself, but I cannot see this working in a DHT typeof network, if a= ll=20 nodes are behind stateful firewalls. Also for non-UDP transports, I am slightly suspicious... For TCP simultaneo= us=20 open to work, there is the requirements that the firewall does not send ICM= P=20 errors (c.f. BEHAVE-TCP)... and that's not specified in IPv6 case, as far a= s=20 I know. That being said, I can only agree with the notion that apps should=20 use "side-effect" of firewalling rather than depend on a signaling protocol= =20 that is likely not implemented by the gateway. But I do not see these as=20 contradictory either; signaling has some advantages such as support for=20 detecting firewall reboots or requesting real pinholing that hole punching= =20 will never support. Another good thing with signaling is the ability to negociate the refresh=20 timer, which is known to matter for mobile devices, as sending refresh=20 packets every so often drains the battery. =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 Apr 18 05:18: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 1He6JD-0007Sg-0Y; Wed, 18 Apr 2007 05:18:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He6JA-0007SV-9k for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 05:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6J9-0007SK-Ty for behave@ietf.org; Wed, 18 Apr 2007 05:18:35 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He6J8-0007rC-LC for behave@ietf.org; Wed, 18 Apr 2007 05:18:35 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 05:18:29 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 05:18:24 -0400 Subject: Re: [BEHAVE] Endpoint-independent filtering is the way to go. From: Saikat Guha To: Bryan Ford In-Reply-To: <7D6481C8-64BC-4F13-8158-F2DD2147ED42@mit.edu> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> <7D6481C8-64BC-4F13-8158-F2DD2147ED42@mit.edu> Date: Wed, 18 Apr 2007 05:18:24 -0400 Message-Id: <1176887904.6657.26.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 18 Apr 2007 09:18:24.0641 (UTC) FILETIME=[8435BF10:01C7819A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IETF 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: , Content-Type: multipart/mixed; boundary="===============1074674613==" Errors-To: behave-bounces@ietf.org --===============1074674613== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PMcGUSYk3NxouJ0bjIuE" --=-PMcGUSYk3NxouJ0bjIuE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-17 at 21:08 -0400, Bryan Ford wrote: > On Apr 17, 2007, at 7:44 PM, james woodyatt wrote: > > Apple's AirPort base station products have always done endpoint-=20 > > independent mapping=20 ^^^^^^^^^^^^^^^^^^^ > Bravo. I have yet to see one anyone come up with single shred of =20 > concrete evidence that endpoint-dependent filtering=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ endpoint independent mapping is not the same as endpoint dependent filtering. Infact, there is nothing called "endpoint-dependent filtering". There is "address dependent filtering" and and "address-and-port dependent filtering". Conflating the two glosses over some important subtleties. Finally, behave MANDATES *endpoint independent mapping* (that which james is referring to I believe). Second, behave RECOMMENDs endpoint independent filtering for NATs that wish to be P2P friendly (that which brian is refering to I believe). Lastly, it RECOMMENDs "address dependent filtering" but NOT address and port dependent filtering for security conscious NATs.=20 If you think the security concern is not justified, refer to a comment made by a Junier engineer in the Paris meeting (check the audio transcript). To paraphrase the comment, anything where talking to ONE internet host leaves the NATed host vulnerable to ANYONE and EVERYONE on the Internet is unacceptable. --=20 Saikat --=-PMcGUSYk3NxouJ0bjIuE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGJeJgnFltqi691/oRAhWpAJ0ZSVIBvFviKlzj0EDBVgpZui2oPgCfW2UQ EYqHge9Us/jyR4ARTMGt9Vg= =zUYm -----END PGP SIGNATURE----- --=-PMcGUSYk3NxouJ0bjIuE-- --===============1074674613== 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 --===============1074674613==-- From behave-bounces@ietf.org Wed Apr 18 05:32: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 1He6Wu-0007eb-VZ; Wed, 18 Apr 2007 05:32:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He6Wj-0007In-Hq for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 05:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6W6-0006Tg-4X for behave@ietf.org; Wed, 18 Apr 2007 05:31:58 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He6Ur-0002UM-Ue for behave@ietf.org; Wed, 18 Apr 2007 05:30:43 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 05:30:36 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 05:30:32 -0400 Subject: Re: [BEHAVE] Re: Endpoint-independent filtering is the way to go. From: Saikat Guha To: Bryan Ford In-Reply-To: <51B04916-8659-4469-AE3F-0AFD64D84EB0@MIT.EDU> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D06404478FFD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <51B04916-8659-4469-AE3F-0AFD64D84EB0@MIT.EDU> Date: Wed, 18 Apr 2007 05:30:31 -0400 Message-Id: <1176888631.6657.35.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 18 Apr 2007 09:30:32.0005 (UTC) FILETIME=[35C0AF50:01C7819C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IETF 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: , Content-Type: multipart/mixed; boundary="===============1241894376==" Errors-To: behave-bounces@ietf.org --===============1241894376== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CjneoyzATUjvBdOv+Pc4" --=-CjneoyzATUjvBdOv+Pc4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-17 at 21:15 -0400, Bryan Ford wrote: > The problem is that the BEHAVE group's decision, if =20 > followed by the industry, makes that task ever more difficult over =20 > time, asymptotically approaching impossible (as we run out of first-=20 > class nodes able to accept incoming connections). This is analogous to saying if everyone uses DNS names all the time then, over time, it'll be impossible to reach any host on the Internet because we'll all just have DNS names. But that is not true now is it? In addition to DNS names, we have the IP addresses of root servers. Those root IPs *cannot* change.=20 Asymptotically, I for one expect to see rendezvous providers just like the DNS root. Rendezvous providers will be required to be non-NAT'ed just like DNS roots are required to operate at a fixed IP. If you are behind a "address dependent filtering" NAT but "endpoint independent mapping" NAT (the most secure config recommended by behave), you must first rendezvous with your peer at the rendezvous service, exchange ICE messages, and then establish the connection. As for the scalability of such a rendezvous service, that would be the topic of discussion for a SIP mailing list. --=20 Saikat --=-CjneoyzATUjvBdOv+Pc4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGJeU3nFltqi691/oRArk8AJ4lpR9qFT/mDkllXk4ZT7sE4xhGGACfePAg YolYBf/11LXaE0z2mi73YlY= =M4ZY -----END PGP SIGNATURE----- --=-CjneoyzATUjvBdOv+Pc4-- --===============1241894376== 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 --===============1241894376==-- From behave-bounces@ietf.org Wed Apr 18 05:40: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 1He6eS-0004LU-QS; Wed, 18 Apr 2007 05:40:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He6eR-0004LM-Ml for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 05:40:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6eR-0004LE-0a for behave@ietf.org; Wed, 18 Apr 2007 05:40:35 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He6eP-0004YV-PG for behave@ietf.org; Wed, 18 Apr 2007 05:40:34 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 05:40:28 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 05:40:23 -0400 Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. From: Saikat Guha To: "Barrett, David" In-Reply-To: <38464B16719C77439C06051F392AB9E6062EB2EB@CAVS1.sanmateo.corp.akamai.com> References: <38464B16719C77439C06051F392AB9E6062EB2EB@CAVS1.sanmateo.corp.akamai.com> Date: Wed, 18 Apr 2007 05:40:23 -0400 Message-Id: <1176889223.6657.44.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 18 Apr 2007 09:40:23.0806 (UTC) FILETIME=[967E59E0:01C7819D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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="===============0312485106==" Errors-To: behave-bounces@ietf.org --===============0312485106== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-k7Gue/oqMY6nnagd4E+0" --=-k7Gue/oqMY6nnagd4E+0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-17 at 18:55 -0700, Barrett, David wrote: > Is it safe to say that the consensus of the BEHAVE group is the > benefit offered by decentralized overlay networks (eg, DHTs) are > outweighed by the security risks of endpoint-independent mapping? No. You are presupposing the solution -- that in the future no global rendezvous service exists. I would say, there exists at least one way where developers can achieve *BOTH* decentralized networks *AND* secure connections. Global rendezvous service (e.g. a SIP infrastructure much like the DNS infrastructure today) is one such way, there may be others. However, requiring endpoint independent filtering would be to admit defeat / condemn the network by saying that security simply cannot be achieved if decentralized networks is a goal. Obviously, that is wrong. --=20 Saikat --=-k7Gue/oqMY6nnagd4E+0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGJeeHnFltqi691/oRAlrjAJ9v/LTWjT+rMSjTUanWOE+Ro5Lf5ACfVfYA 6uopBCEn8fpGmJF/w5gYBzg= =nlmU -----END PGP SIGNATURE----- --=-k7Gue/oqMY6nnagd4E+0-- --===============0312485106== 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 --===============0312485106==-- From behave-bounces@ietf.org Wed Apr 18 09:00: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 1He9lr-0000WN-Fa; Wed, 18 Apr 2007 09:00:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He9lq-0000WC-3r for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 09:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9lp-0000W0-Q8 for behave@ietf.org; Wed, 18 Apr 2007 09:00:25 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9lo-0003Q7-He for behave@ietf.org; Wed, 18 Apr 2007 09:00:25 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3ID0IVv023097; Wed, 18 Apr 2007 09:00:18 -0400 (EDT) Received: from [192.168.1.105] (pool-151-199-61-176.bos.east.verizon.net [151.199.61.176]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3ID0HQj008169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Apr 2007 09:00:18 -0400 (EDT) Subject: Re: [BEHAVE] Endpoint-independent filtering is the way to go. From: Bryan Ford To: Saikat Guha In-Reply-To: <1176887904.6657.26.camel@sioux.systems.cs.cornell.edu> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> <7D6481C8-64BC-4F13-8158-F2DD2147ED42@mit.edu> <1176887904.6657.26.camel@sioux.systems.cs.cornell.edu> Content-Type: text/plain Organization: Massachusetts Institute of Technology Date: Wed, 18 Apr 2007 09:00:30 -0400 Message-Id: <1176901230.4818.6.camel@slack> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF 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 Wed, 2007-04-18 at 05:18 -0400, Saikat Guha wrote: > On Tue, 2007-04-17 at 21:08 -0400, Bryan Ford wrote: > > On Apr 17, 2007, at 7:44 PM, james woodyatt wrote: > > > Apple's AirPort base station products have always done endpoint- > > > independent mapping > ^^^^^^^^^^^^^^^^^^^ > > Bravo. I have yet to see one anyone come up with single shred of > > concrete evidence that endpoint-dependent filtering > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > endpoint independent mapping is not the same as endpoint dependent > filtering. Oops, sorry, just a typo - I meant "filtering" in both places, not "mapping". > If you think the security concern is not justified, refer to a comment > made by a Junier engineer in the Paris meeting (check the audio > transcript). To paraphrase the comment, anything where talking to ONE > internet host leaves the NATed host vulnerable to ANYONE and EVERYONE on > the Internet is unacceptable. But it doesn't leave the NATted host vulnerable to ANYONE and EVERYONE - at most it is vulnerable to an external host that has the resources to scan systematically for the public port - which is typically in the large upper range well clear of standard port assignments. As I said, show me just ONE actual, documented, working historical exploit and I might reconsider. But you might have a tough time - as has been pointed out already, practically all attacks have already migrated up the protocol stack to higher layers that aren't protected by any basic firewall with either filtering behavior. Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 09:11: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 1He9wt-0008DQ-Tv; Wed, 18 Apr 2007 09:11:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1He9ws-0008Ce-6Z for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 09:11:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9wr-0008CU-Sd for behave@ietf.org; Wed, 18 Apr 2007 09:11:49 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9wq-00072f-Lc for behave@ietf.org; Wed, 18 Apr 2007 09:11:49 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3IDBl4h000581; Wed, 18 Apr 2007 09:11:47 -0400 (EDT) Received: from [192.168.1.105] (pool-151-199-61-176.bos.east.verizon.net [151.199.61.176]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3IDBkne011933 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Apr 2007 09:11:47 -0400 (EDT) From: Bryan Ford To: David Barrett In-Reply-To: <02bd01c78161$b83c0320$6f02a8c0@Quinthar> References: <02bd01c78161$b83c0320$6f02a8c0@Quinthar> Content-Type: text/plain Organization: Massachusetts Institute of Technology Date: Wed, 18 Apr 2007 09:11:59 -0400 Message-Id: <1176901919.4818.19.camel@slack> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'IETF BEHAVE WG' Subject: [BEHAVE] RE: Endpoint-independent filtering is the way to go. 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, 2007-04-17 at 19:31 -0700, David Barrett wrote: > Actually, now that I read the RFC as suggested by Bruce, REQ 8 doesn't > appear to recommend endpoint-dependent filtering by default. > > Bryan -- Am I misreading this? Why are you saying that it's recommending > endpoint-dependent filtering by default? Oops, you're right - sorry, I forgot that the final language actually did end up more or less permitting either option. So it's not quite as bad as I remembered. But it still disturbs me greatly that the BEHAVE group ended up officially "blessing" the anti-connectivity endpoint-depending filtering behavior based on absolutely no evidence of added security other than FUD. Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 09:28: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 1HeACV-0000yC-Db; Wed, 18 Apr 2007 09:27:59 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeACU-0000y7-UF for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 09:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeACU-0000xz-Kl for behave@ietf.org; Wed, 18 Apr 2007 09:27:58 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeACU-0003ek-D2 for behave@ietf.org; Wed, 18 Apr 2007 09:27:58 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3IDRvkX012195; Wed, 18 Apr 2007 09:27:57 -0400 (EDT) Received: from [192.168.1.105] (pool-151-199-61-176.bos.east.verizon.net [151.199.61.176]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3IDRtGU018941 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Apr 2007 09:27:56 -0400 (EDT) Subject: Re: [BEHAVE] Re: Endpoint-independent filtering is the way to go. From: Bryan Ford To: Saikat Guha In-Reply-To: <1176888631.6657.35.camel@sioux.systems.cs.cornell.edu> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D06404478FFD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <51B04916-8659-4469-AE3F-0AFD64D84EB0@MIT.EDU> <1176888631.6657.35.camel@sioux.systems.cs.cornell.edu> Content-Type: text/plain Organization: Massachusetts Institute of Technology Date: Wed, 18 Apr 2007 09:28:09 -0400 Message-Id: <1176902889.4818.34.camel@slack> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF 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 Wed, 2007-04-18 at 05:30 -0400, Saikat Guha wrote: > On Tue, 2007-04-17 at 21:15 -0400, Bryan Ford wrote: > > The problem is that the BEHAVE group's decision, if > > followed by the industry, makes that task ever more difficult over > > time, asymptotically approaching impossible (as we run out of first- > > class nodes able to accept incoming connections). > > This is analogous to saying if everyone uses DNS names all the time > then, over time, it'll be impossible to reach any host on the Internet > because we'll all just have DNS names. > > But that is not true now is it? In addition to DNS names, we have the IP > addresses of root servers. Those root IPs *cannot* change. > > Asymptotically, I for one expect to see rendezvous providers just like > the DNS root. Rendezvous providers will be required to be non-NAT'ed > just like DNS roots are required to operate at a fixed IP. But Internet standards REQUIRE that every ISP provide DNS service to their clients, and in particular to run _enough_ DNS servers to handle the the everyday load their clients produce without hammering the upstream or root DNS servers. If the IETF were similarly to REQUIRE that every ISP provide working STUN servers to their clients, which those clients can easily locate through fully automatic mechanisms (e.g., DHCP), and which can handle all the rendezvous load that the clients may generate even when they are running connection-intensive protocols like DHTs, then I would be happy with that strategy. Until then, though, you're using the existence of something that doesn't exist - either "de facto" or "de jure" - as an excuse for not defending the Internet's original connectivity paradigm. Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 09:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAFB-0001r6-10; Wed, 18 Apr 2007 09:30:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeAF8-0001pi-Vl for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 09:30:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAF8-0001pa-MH for behave@ietf.org; Wed, 18 Apr 2007 09:30:42 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAF7-0004Cl-Eb for behave@ietf.org; Wed, 18 Apr 2007 09:30:42 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3IDUcqc013897; Wed, 18 Apr 2007 09:30:38 -0400 (EDT) Received: from [192.168.1.105] (pool-151-199-61-176.bos.east.verizon.net [151.199.61.176]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3IDUaeT019946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Apr 2007 09:30:37 -0400 (EDT) Subject: Re: [BEHAVE] Endpoint-independent filtering is the way to go. From: Bryan Ford To: Saikat Guha In-Reply-To: <1176901230.4818.6.camel@slack> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> <7D6481C8-64BC-4F13-8158-F2DD2147ED42@mit.edu> <1176887904.6657.26.camel@sioux.systems.cs.cornell.edu> <1176901230.4818.6.camel@slack> Content-Type: text/plain Organization: Massachusetts Institute of Technology Date: Wed, 18 Apr 2007 09:30:50 -0400 Message-Id: <1176903050.4818.37.camel@slack> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF 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 Wed, 2007-04-18 at 09:00 -0400, Bryan Ford wrote: > On Wed, 2007-04-18 at 05:18 -0400, Saikat Guha wrote: > > On Tue, 2007-04-17 at 21:08 -0400, Bryan Ford wrote: > > > On Apr 17, 2007, at 7:44 PM, james woodyatt wrote: > > > > Apple's AirPort base station products have always done endpoint- > > > > independent mapping > > ^^^^^^^^^^^^^^^^^^^ > > > Bravo. I have yet to see one anyone come up with single shred of > > > concrete evidence that endpoint-dependent filtering > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > endpoint independent mapping is not the same as endpoint dependent > > filtering. > > Oops, sorry, just a typo - I meant "filtering" in both places, not > "mapping". Re-oops - I thought the first instance was my writing, but it was James's, which I had misread. But the rest of the statement stands. Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 09:52:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAab-0006x2-Oo; Wed, 18 Apr 2007 09:52:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeAaY-0006wf-9P for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 09:52:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAaX-0006wS-W3 for behave@ietf.org; Wed, 18 Apr 2007 09:52:49 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAaT-0001TU-Lx for behave@ietf.org; Wed, 18 Apr 2007 09:52:49 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3968233C1A; Wed, 18 Apr 2007 06:53:09 -0700 (PDT) Date: Wed, 18 Apr 2007 06:53:09 -0700 From: Eric Rescorla To: Bryan Ford Subject: Re: [BEHAVE] Endpoint-independent filtering is the way to go. In-Reply-To: <1176901230.4818.6.camel@slack> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> <7D6481C8-64BC-4F13-8158-F2DD2147ED42@mit.edu> <1176887904.6657.26.camel@sioux.systems.cs.cornell.edu> <1176901230.4818.6.camel@slack> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070418135309.3968233C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF 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 At Wed, 18 Apr 2007 09:00:30 -0400, Bryan Ford wrote: > > On Wed, 2007-04-18 at 05:18 -0400, Saikat Guha wrote: > > On Tue, 2007-04-17 at 21:08 -0400, Bryan Ford wrote: > > > On Apr 17, 2007, at 7:44 PM, james woodyatt wrote: > > > > Apple's AirPort base station products have always done endpoint- > > > > independent mapping > > ^^^^^^^^^^^^^^^^^^^ > > > Bravo. I have yet to see one anyone come up with single shred of > > > concrete evidence that endpoint-dependent filtering > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > endpoint independent mapping is not the same as endpoint dependent > > filtering. > > Oops, sorry, just a typo - I meant "filtering" in both places, not > "mapping". > > > If you think the security concern is not justified, refer to a comment > > made by a Junier engineer in the Paris meeting (check the audio > > transcript). To paraphrase the comment, anything where talking to ONE > > internet host leaves the NATed host vulnerable to ANYONE and EVERYONE on > > the Internet is unacceptable. > > But it doesn't leave the NATted host vulnerable to ANYONE and EVERYONE - > at most it is vulnerable to an external host that has the resources to > scan systematically for the public port - which is typically in the > large upper range well clear of standard port assignments. http://insecure.org/nmap/ > As I said, show me just ONE actual, documented, working historical > exploit and I might reconsider. But you might have a tough time - as > has been pointed out already, practically all attacks have already > migrated up the protocol stack to higher layers that aren't protected by > any basic firewall with either filtering behavior. And yet packet filters are incredibly common. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 09: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 1HeAad-0006xs-Ov; Wed, 18 Apr 2007 09:52:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeAac-0006xd-49 for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 09:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAab-0006ww-LH for behave@ietf.org; Wed, 18 Apr 2007 09:52:53 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAaa-0001cv-B3 for behave@ietf.org; Wed, 18 Apr 2007 09:52:53 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E99EB33C37; Wed, 18 Apr 2007 06:53:15 -0700 (PDT) Date: Wed, 18 Apr 2007 06:53:15 -0700 From: Eric Rescorla To: Bryan Ford Subject: Re: [BEHAVE] Endpoint-independent filtering is the way to go. In-Reply-To: <1176901230.4818.6.camel@slack> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> <7D6481C8-64BC-4F13-8158-F2DD2147ED42@mit.edu> <1176887904.6657.26.camel@sioux.systems.cs.cornell.edu> <1176901230.4818.6.camel@slack> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070418135315.E99EB33C37@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF 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 At Wed, 18 Apr 2007 09:00:30 -0400, Bryan Ford wrote: > > On Wed, 2007-04-18 at 05:18 -0400, Saikat Guha wrote: > > On Tue, 2007-04-17 at 21:08 -0400, Bryan Ford wrote: > > > On Apr 17, 2007, at 7:44 PM, james woodyatt wrote: > > > > Apple's AirPort base station products have always done endpoint- > > > > independent mapping > > ^^^^^^^^^^^^^^^^^^^ > > > Bravo. I have yet to see one anyone come up with single shred of > > > concrete evidence that endpoint-dependent filtering > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > endpoint independent mapping is not the same as endpoint dependent > > filtering. > > Oops, sorry, just a typo - I meant "filtering" in both places, not > "mapping". > > > If you think the security concern is not justified, refer to a comment > > made by a Junier engineer in the Paris meeting (check the audio > > transcript). To paraphrase the comment, anything where talking to ONE > > internet host leaves the NATed host vulnerable to ANYONE and EVERYONE on > > the Internet is unacceptable. > > But it doesn't leave the NATted host vulnerable to ANYONE and EVERYONE - > at most it is vulnerable to an external host that has the resources to > scan systematically for the public port - which is typically in the > large upper range well clear of standard port assignments. http://insecure.org/nmap/ > As I said, show me just ONE actual, documented, working historical > exploit and I might reconsider. But you might have a tough time - as > has been pointed out already, practically all attacks have already > migrated up the protocol stack to higher layers that aren't protected by > any basic firewall with either filtering behavior. And yet packet filters are incredibly common. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 10:42: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 1HeBMO-0007zp-FM; Wed, 18 Apr 2007 10:42:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeBMN-0007zU-Dx for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 10:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBMN-0007zM-4Q for behave@ietf.org; Wed, 18 Apr 2007 10:42:15 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBMJ-0000eJ-Sr for behave@ietf.org; Wed, 18 Apr 2007 10:42:15 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:42:11 -0400 Received: from [172.23.16.30] ([172.23.16.30]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:42:10 -0400 Subject: Re: [BEHAVE] Endpoint-independent filtering is the way to go. From: Saikat Guha To: Bryan Ford In-Reply-To: <1176901230.4818.6.camel@slack> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> <7D6481C8-64BC-4F13-8158-F2DD2147ED42@mit.edu> <1176887904.6657.26.camel@sioux.systems.cs.cornell.edu> <1176901230.4818.6.camel@slack> Organization: Cornell University Date: Wed, 18 Apr 2007 10:42:09 -0400 Message-Id: <1176907329.5131.60.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 18 Apr 2007 14:42:10.0828 (UTC) FILETIME=[BF1EA4C0:01C781C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF 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: , Content-Type: multipart/mixed; boundary="===============0775891523==" Errors-To: behave-bounces@ietf.org --===============0775891523== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zWiLg9k9mQVs7I4zbh2H" --=-zWiLg9k9mQVs7I4zbh2H Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-04-18 at 09:00 -0400, Bryan Ford wrote: > But it doesn't leave the NATted host vulnerable to ANYONE and EVERYONE > at most it is vulnerable to an external host that has the resources to > scan systematically for the public port - which is typically in the ^^^^ Most NATs are port-number preserving. If an application uses local port x, translated packets will appear to come from the same port x on the external side. So no port-scan is necessary. Combine this with MS SQL Slammer worm, and the following scenario emerges. Normal operation: SQL1 ---- NAT1 ---- Internet ----- Firewall --- SQL2 SQL1 is configured to send daily log backups to an offsite SQL2. MS SQL server uses the UDP port on SQL1 to contact the UDP port on SQL2. Slammer day operation: SQL1 ----- NAT1 --------- Slammer1 Slammer1 can now send a single packet to SQL1 through the SQL1-SQL2 hole that was left open on the NAT. Game over. --=20 Saikat --=-zWiLg9k9mQVs7I4zbh2H Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGJi5BnFltqi691/oRAtdEAJ9s65IetgF2urWg52hgxELM1CIV6QCfYQn8 U9tt86I/7gGA7dgjiK5f3EY= =sfzV -----END PGP SIGNATURE----- --=-zWiLg9k9mQVs7I4zbh2H-- --===============0775891523== 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 --===============0775891523==-- From behave-bounces@ietf.org Wed Apr 18 10:52: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 1HeBW7-0006nk-Kn; Wed, 18 Apr 2007 10:52:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeBW6-0006nQ-3d for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 10:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBW5-0006nI-QS for behave@ietf.org; Wed, 18 Apr 2007 10:52:17 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBW4-0004CW-EV for behave@ietf.org; Wed, 18 Apr 2007 10:52:17 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:52:15 -0400 Received: from [172.23.16.30] ([172.23.16.30]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:52:15 -0400 Subject: Re: [BEHAVE] Re: Endpoint-independent filtering is the way to go. From: Saikat Guha To: Bryan Ford In-Reply-To: <1176902889.4818.34.camel@slack> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D06404478FFD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <51B04916-8659-4469-AE3F-0AFD64D84EB0@MIT.EDU> <1176888631.6657.35.camel@sioux.systems.cs.cornell.edu> <1176902889.4818.34.camel@slack> Organization: Cornell University Date: Wed, 18 Apr 2007 10:52:14 -0400 Message-Id: <1176907934.5131.71.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 18 Apr 2007 14:52:15.0426 (UTC) FILETIME=[277CFA20:01C781C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF 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: , Content-Type: multipart/mixed; boundary="===============0781604545==" Errors-To: behave-bounces@ietf.org --===============0781604545== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SXByT6IIu6EKF24snili" --=-SXByT6IIu6EKF24snili Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-04-18 at 09:28 -0400, Bryan Ford wrote: > But Internet standards REQUIRE that every ISP provide DNS service to > their clients Can you point me to such an ISP requirements document?=20 AFAIK, ISPs are not *required* to provide a recursive resolver. Any third-party service (at a well-known IP) can provide a recursive resolver the entire world can use. > If the IETF were similarly to REQUIRE that every ISP provide working > STUN servers to their clients No need to "REQUIRE that every ISP" provide a STUN server; just that _some_ STUN servers exist, perhaps third-party.=20 > which those clients can easily locate through fully automatic mechanisms=20 > (e.g., DHCP) Now you are talking about (non-insurmountable) configuration hurdles. Completely tangential to NAT filtering. > , and which can handle > all the rendezvous load=20 ... and performance. More engineering. > then I would be happy > with that strategy. =20 I, for one, wouldn't be happy if asked to surrender a secure network for one that requires a touch more configuration and engineering. --=20 Saikat --=-SXByT6IIu6EKF24snili Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGJjCenFltqi691/oRAutMAJ4mnMOac5SjcuBilKTSTBq+TJMCOwCfTMzY AcmZ+Wqjea9IQF7N46WXwus= =+GOu -----END PGP SIGNATURE----- --=-SXByT6IIu6EKF24snili-- --===============0781604545== 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 --===============0781604545==-- From behave-bounces@ietf.org Wed Apr 18 14:20: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 1HeElN-0007nb-Cu; Wed, 18 Apr 2007 14:20:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeElL-0007nR-Tc for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 14:20:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeElL-0007nJ-K9 for behave@ietf.org; Wed, 18 Apr 2007 14:20:15 -0400 Received: from smtp3.akamai.com ([63.116.109.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeElK-0005Sr-5y for behave@ietf.org; Wed, 18 Apr 2007 14:20:15 -0400 Received: from smtp3.akamai.com (vwall2.sanmateo.corp.akamai.com [172.23.1.72]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3IIKNsX019044 for ; Wed, 18 Apr 2007 11:20:23 -0700 (PDT) Received: from USCA1EX-GATE1.sanmateo.corp.akamai.com (usca1ex-gate1.sanmateo.corp.akamai.com [172.23.1.110]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3IIKM95019039; Wed, 18 Apr 2007 11:20:22 -0700 (PDT) Received: from CAVS1.sanmateo.corp.akamai.com ([172.23.1.125]) by USCA1EX-GATE1.sanmateo.corp.akamai.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 11:24:07 -0700 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: Endpoint-independent filtering is the way to go. X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Apr 2007 11:20:11 -0700 Message-ID: <38464B16719C77439C06051F392AB9E6062EB2F1@CAVS1.sanmateo.corp.akamai.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Thread-Index: AceBuyUkEnBdhu6/Skuw0aZjDb7F3AAINSO7 References: <02bd01c78161$b83c0320$6f02a8c0@Quinthar> <1176901919.4818.19.camel@slack> From: "Barrett, David" To: "Bryan Ford" , "David Barrett" X-OriginalArrivalTime: 18 Apr 2007 18:24:07.0656 (UTC) FILETIME=[C0915680:01C781E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF 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 Thanks for the clarification. So in effect, BEHAVE makes no = recommendation regarding restricted/full-cone (ie, recommends both = equally), but instead just outlaws all forms of symmetric NATs. That's = a step in the right direction, though I agree, not as far as I'd like. -david -----Original Message----- From: Bryan Ford [mailto:baford@MIT.EDU] Sent: Wed 4/18/2007 6:11 AM To: David Barrett Cc: 'IETF BEHAVE WG' Subject: [BEHAVE] RE: Endpoint-independent filtering is the way to go. =20 On Tue, 2007-04-17 at 19:31 -0700, David Barrett wrote: > Actually, now that I read the RFC as suggested by Bruce, REQ 8 doesn't > appear to recommend endpoint-dependent filtering by default. >=20 > Bryan -- Am I misreading this? Why are you saying that it's = recommending > endpoint-dependent filtering by default? Oops, you're right - sorry, I forgot that the final language actually did end up more or less permitting either option. So it's not quite as bad as I remembered. But it still disturbs me greatly that the BEHAVE group ended up officially "blessing" the anti-connectivity endpoint-depending filtering behavior based on absolutely no evidence of added security other than FUD. Bryan _______________________________________________ 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 Apr 18 14:33: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 1HeEyc-0004UL-KZ; Wed, 18 Apr 2007 14:33:58 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeEyb-0004UG-8Q for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 14:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEya-0004U8-VH for behave@ietf.org; Wed, 18 Apr 2007 14:33:56 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEya-0008IQ-IZ for behave@ietf.org; Wed, 18 Apr 2007 14:33:56 -0400 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3IIXuY0025247 for ; Wed, 18 Apr 2007 11:33:56 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 12B6F40477 for ; Wed, 18 Apr 2007 11:33:56 -0700 (PDT) X-AuditID: 11807126-9dd4bbb0000007ff-19-46266494cd63 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay8.apple.com (Apple SCV relay) with ESMTP id 0BE9A4007B for ; Wed, 18 Apr 2007 11:33:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <008201c78186$85487eb0$75240046@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Wed, 18 Apr 2007 11:33:50 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Apr 18, 2007, at 00:01, Christian Huitema wrote: > > We allow for both. Our P2P apps work through endpoint-dependent > filtering routers. Some use ICE like mechanisms, other use IPv6 > over Teredo. Does the tool check that Teredo is properly blocked when the router is advertising a global scope IPv6 prefix? -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 16:31:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeGoK-000294-Di; Wed, 18 Apr 2007 16:31:28 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeGoI-00027S-W7 for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 16:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeGoI-000274-M3 for behave@ietf.org; Wed, 18 Apr 2007 16:31:26 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeGoG-0007X4-Bn for behave@ietf.org; Wed, 18 Apr 2007 16:31:26 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 18 Apr 2007 13:31:23 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Wed, 18 Apr 2007 13:31:23 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Apr 2007 13:31:23 -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: Endpoint-independent filtering is the way to go. Date: Wed, 18 Apr 2007 13:31:03 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064044793D5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Thread-Index: AceB6DFjbsCg8orKTLSW17evL2c2nQAD+ZJQ References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com><008201c78186$85487eb0$75240046@Quinthar><70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Christian Huitema To: james woodyatt , IETF BEHAVE WG X-OriginalArrivalTime: 18 Apr 2007 20:31:23.0144 (UTC) FILETIME=[87AC5880:01C781F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Apr 18, 2007, at 00:01, Christian Huitema wrote: >> >> We allow for both. Our P2P apps work through endpoint-dependent =20 >> filtering routers. Some use ICE like mechanisms, other use IPv6 =20 >> over Teredo. > > Does the tool check that Teredo is properly blocked when the router =20 > is advertising a global scope IPv6 prefix? No. In fact, we expect routers to not block Teredo, regardless of their IPv6 configuration. For example, even if a host does have native IPv6 connectivity, it might want to run a "host based" Teredo relay in order to communicate with other Teredo hosts.=20 -- Christian Huitema =20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 18 16:54: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 1HeHAZ-0007Sm-9z; Wed, 18 Apr 2007 16:54:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeHAY-0007RY-4w for behave-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 16:54:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHAX-0007Qt-Rc for behave@ietf.org; Wed, 18 Apr 2007 16:54:25 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHAV-000660-G2 for behave@ietf.org; Wed, 18 Apr 2007 16:54:25 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3IKsMth020109 for ; Wed, 18 Apr 2007 13:54:22 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id DD17B100FA for ; Wed, 18 Apr 2007 13:54:22 -0700 (PDT) X-AuditID: 11807124-a057cbb0000007e5-92-4626857ef292 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay6.apple.com (Apple SCV relay) with ESMTP id C721F1006E for ; Wed, 18 Apr 2007 13:54:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064044793D5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <008201c78186$85487eb0$75240046@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <70C6EFCDFC8AAD418EF7063CD132D064044793D5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Wed, 18 Apr 2007 13:54:17 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Apr 18, 2007, at 13:31, Christian Huitema wrote: > [I wrote:] >> >> Does the tool check that Teredo is properly blocked when the router >> is advertising a global scope IPv6 prefix? > > No. In fact, we expect routers to not block Teredo, regardless of > their IPv6 configuration. [...] For the "Designed for Windows Vista" certification, do you require Teredo *not* to be blocked by IPv6 routers offering prefixes derived from, for example, 6to4 tunnels? Apple communications engineering is in the middle of discussions about how to secure the local network against unsolicited traffic embedded in Teredo tunnels. I'm currently advocating blocking all Teredo if an native IPv6 prefix is advertised on the local network. It's easier than trying to apply the stateful packet filter to the traffic embedded in the UDP flows. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 19 01: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 1HePby-0007ga-Id; Thu, 19 Apr 2007 01:55:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HePbx-0007fo-9f for behave-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 01:55:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HePbt-0007el-Ug for behave@ietf.org; Thu, 19 Apr 2007 01:55:13 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HePbs-0001aE-KP for behave@ietf.org; Thu, 19 Apr 2007 01:55:13 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 18 Apr 2007 22:55:12 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Wed, 18 Apr 2007 22:55:11 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Apr 2007 22:55:11 -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: Endpoint-independent filtering is the way to go. Date: Wed, 18 Apr 2007 22:54:54 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D06404479714@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Thread-Index: AceB+864z/VB2STjSyuEZjFsS5IngAASwejw References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com><008201c78186$85487eb0$75240046@Quinthar><70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com><70C6EFCDFC8AAD418EF7063CD132D064044793D5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Christian Huitema To: james woodyatt , IETF BEHAVE WG X-OriginalArrivalTime: 19 Apr 2007 05:55:11.0526 (UTC) FILETIME=[4AF5CC60:01C78247] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 > >> Does the tool check that Teredo is properly blocked when the router > >> is advertising a global scope IPv6 prefix? > > > > No. In fact, we expect routers to not block Teredo, regardless of > > their IPv6 configuration. [...] >=20 > For the "Designed for Windows Vista" certification, do you require > Teredo *not* to be blocked by IPv6 routers offering prefixes derived > from, for example, 6to4 tunnels? =20 That is correct, we require Teredo to not be blocked, even if the IGD offers 6to4 or other IPv6 services. > Apple communications engineering is > in the middle of discussions about how to secure the local network > against unsolicited traffic embedded in Teredo tunnels. We expect that protection to be performed in the host. Teredo is only enabled on Windows if there is an active host firewall, that explicitly controls IPv6 traffic. -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 19 02:56:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeQYi-0000oA-4B; Thu, 19 Apr 2007 02:56:00 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HeQYh-0000o1-0w for behave-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 02:55:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeQYg-0000nt-Ef for behave@ietf.org; Thu, 19 Apr 2007 02:55:58 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeQYf-0006HZ-0a for behave@ietf.org; Thu, 19 Apr 2007 02:55:58 -0400 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3J6tu2N006930 for ; Wed, 18 Apr 2007 23:55:56 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 914A740556 for ; Wed, 18 Apr 2007 23:55:56 -0700 (PDT) X-AuditID: 11807126-9e54cbb0000007ff-19-4627127c7b23 Received: from [17.219.210.210] (unknown [17.219.210.210]) by relay8.apple.com (Apple SCV relay) with ESMTP id 6A724404EE for ; Wed, 18 Apr 2007 23:55:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06404479714@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <008201c78186$85487eb0$75240046@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <70C6EFCDFC8AAD418EF7063CD132D064044793D5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <70C6EFCDFC8AAD418EF7063CD132D06404479714@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <273B520E-4E48-417A-AAE9-81AE9A7AF824@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Wed, 18 Apr 2007 23:55:50 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Apr 18, 2007, at 22:54, Christian Huitema wrote: > [I wrote:] >> >> For the "Designed for Windows Vista" certification, do you require >> Teredo *not* to be blocked by IPv6 routers offering prefixes >> derived from, for example, 6to4 tunnels? > > That is correct, we require Teredo to not be blocked, even if the > IGD offers 6to4 or other IPv6 services. Interesting. That seems like a curious design choice. >> Apple communications engineering is in the middle of discussions >> about how to secure the local network against unsolicited traffic >> embedded in Teredo tunnels. > > We expect that protection to be performed in the host. Teredo is > only enabled on Windows if there is an active host firewall, that > explicitly controls IPv6 traffic. That expectation may be unrealistic. Teredo is an IPv6 transition mechanism, not a virtual private networking application. It cannot be allowed to be a method for circumventing the stateful packet firewall in residential IPv6 gateways for the establishment of communications counter to policies defined by network administrators. As such, I'm pretty confident that the Teredo requirement will go on Apple's list of reasons not to seek the "Designed for Windows Vista" certification. I also think the BEHAVE working group should explicitly recommend blocking Teredo in dual-IPv6/IPv4-NAT gateways. Such gateways should implement their own Teredo relays for forwarding to and from the 2001::/32 prefix subject to the filtering policy configured at the gateway. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 20 05:50: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 1Hepkx-0007aT-Du; Fri, 20 Apr 2007 05:50:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hepkw-0007aF-2F for behave-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 05:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hepkv-0007a6-OG for behave@ietf.org; Fri, 20 Apr 2007 05:50:17 -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 1Hepku-0001KB-9p for behave@ietf.org; Fri, 20 Apr 2007 05:50:17 -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 l3K9o4uW030987; Fri, 20 Apr 2007 12:50:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:49:51 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:49:51 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:49:50 +0300 Received: from esdhcp04068.research.nokia.com (esdhcp04068.research.nokia.com [172.21.40.68]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3K9nnVj016958; Fri, 20 Apr 2007 12:49:49 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TCP framing in TURN Date: Fri, 20 Apr 2007 12:49:50 +0300 User-Agent: KMail/1.9.6 References: <462599F1.2050102@gmail.com> In-Reply-To: <462599F1.2050102@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704201249.50462.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 Apr 2007 09:49:50.0829 (UTC) FILETIME=[3D4AB1D0:01C78331] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070420125013-77B66BB0-66D79CBC/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Wednesday 18 April 2007 07:09:21 ext Evgeniy Khramtsov wrote: > From draft-ietf-behave-turn-03.txt, para 5: > > "The first octet of this framing is 0x02 to indicate STUN messages or > 0x03 to indicate end-to-end data to or from the active destination. > Note that the first octet is always distinguishable from an unframed > STUN request or response (which is always 0x00 or 0x01)." > Could you explain me why do you need to additionaly frame STUN messages > since all STUN messages have always 0x00 or 0x01 in their first octet > and we can simply distinguish them from the end-to-end data frame? Am I > misreading something? Sure, we could avoid framing STUN messages (I vaguely remember this being=20 already pointed out at the last meeting). However, the end-to-end data framing will probably need to be changed to=20 something that sets either or both of the higher-order two bits of the=20 framing (since STUN always sets the first two bits to zero). Could be=20 something like 0x4001PQRT then two bytes length, and then 0xPQRT bytes of T= CP=20 data. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 22 03:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfWaN-0006IK-Iz; Sun, 22 Apr 2007 03:34:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfWaL-0006ID-Qw for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 03:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfWaL-0006I4-Dy for behave@ietf.org; Sun, 22 Apr 2007 03:34:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfWaJ-0004kB-RG for behave@ietf.org; Sun, 22 Apr 2007 03:34:13 -0400 Received: by ug-out-1314.google.com with SMTP id 72so991881ugd for ; Sun, 22 Apr 2007 00:34:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=QCHxP/AHT2sT/L7Ks7K2gZ3QAQ46gundI0fYTwLTmwh1osCv+gg0t/cm+7EeUhYewOPpvIjcM33lZFz08owhJY/FpWDel1D+yOTIydRcAytascm8sr9IXwR02ggeAQN5fyxjMfjF/KtOxosdIlG3RrQMdYzdIzpkkl4NC0fvtpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=nXe/ddmqplxUgvHQt4259Z5mZ4taQXzi+XN0SJaR8ftzvK6uEuxVSfIOx4RwgUjl1XgWy4pDJ5fyrUrcZKzSrYjekqlMZMLrwj7Dyo7t8pndG0XvtBydcVq2SS/os5J/VifcYMQOCfWRLgk5v3W3EonLWpJ35Af17u3u5KRpyHM= Received: by 10.66.244.11 with SMTP id r11mr4209234ugh.1177227250925; Sun, 22 Apr 2007 00:34:10 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTP id c25sm5613083ika.2007.04.22.00.34.08; Sun, 22 Apr 2007 00:34:09 -0700 (PDT) Message-ID: <462B0FEE.7030701@gmail.com> Date: Sun, 22 Apr 2007 17:34:06 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [BEHAVE] Successful Responses in TURN 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 Looks like some TURN responses are not documented in the I-D, or, perhaps, I'm misreading something :) However, I have 3 questions: 1. What should the server reply to the successful Set Active Destination request? 2. What should the server reply to the successful Allocate request with the LIFETIME attribute set to 0 (aka 'destroying an allocation' request)? 3. What should the server reply to the successful Connect request? Formally, if the response is not documented in the spec, the server should not generate the response. Is it really true? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 22 10:00: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 1Hfcbp-0007lJ-Bl; Sun, 22 Apr 2007 10:00:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hfcbo-0007l8-EQ for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 10:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfcbo-0007kv-4d for behave@ietf.org; Sun, 22 Apr 2007 10:00:08 -0400 Received: from web33309.mail.mud.yahoo.com ([68.142.206.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfcbk-0006Wl-Kl for behave@ietf.org; Sun, 22 Apr 2007 10:00:08 -0400 Received: (qmail 75952 invoked by uid 60001); 22 Apr 2007 14:00:03 -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=40aI+jNESEOlmGUW7EH2XwoUPpSqSxoBl1G1+C09x1S/MC4ixytRjY9D4uutYCrNdmafVMrFCq6Hlqe+zR71XLeBw5wAOWScKY9Snkp7X8Rm9fd1IN/vXOHK6FKWgA0z4yVt7zd842W6lq99f9sWfsYCFnrcBl08YlUsTrBhkl0=; X-YMail-OSG: 586Q18EVM1kFeRYXb1EzZoNEEjKeXDSEmp4u7UJK9zhXHCHVqo0XmEwUFav0DvF25eyogGCJE.k2yLl1MPNUzfflOgBrLjygV1GJIOPw.rRIHlM- Received: from [69.236.67.182] by web33309.mail.mud.yahoo.com via HTTP; Sun, 22 Apr 2007 07:00:03 PDT Date: Sun, 22 Apr 2007 07:00:03 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] RE: [tcpm] icmp type 3, code 13 To: "Faisal Siyavudeen \(fsiyavud\)" , Joe Touch In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <668657.73320.qm@web33309.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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 Faisal, Sorry for the delay in responding. You are absolutely right. ICMP type 3, code 13 was selected for exactly the reasons you cite below. Thanks. regards, suresh --- "Faisal Siyavudeen (fsiyavud)" wrote: > > | > it could be code 10 or code 13 depending on the type of filtering. > | > | I don't see that difference; code 10 just says > | administratively prohibited, and code 13 says > | administratively prohibited because of filtering. In either > | case, other ports could be reachable. > | > > I agree. > > I am sorry I was not clear - my point was that 10 cannot be used where > other ports on the hosts are still accessible, while 13 can be used in > any of these cases. BTW, the following note in RFC 1812 makes me wonder > if NAT devices can send code 10 at all as they are more like routers: > > > Codes 9 and 10 were intended for use by end-to-end encryption devices > used by U.S military agencies. Routers SHOULD use the newly defined Code > 13 (Communication Administratively Prohibited) if they administratively > filter packets. > > > rgds > Faisal > > | -----Original Message----- > | From: Joe Touch [mailto:touch@ISI.EDU] > | Sent: Tuesday, April 10, 2007 10:04 PM > | To: Faisal Siyavudeen (fsiyavud) > | Cc: Pekka Savola; Dan Wing (dwing); tcpm@ietf.org; > | behave@ietf.org; Mahesh Govind (mgovind) > | Subject: Re: [tcpm] icmp type 3, code 13 > | > | > | > | Faisal Siyavudeen (fsiyavud) wrote: > | > | '10' seems to (at least more strongly) imply that all > | communication > | > | with the destination address is administratively prohibited. > | > > | > Does NAT administrative filtering referred to by > | > draft-ietf-behave-nat-icmp-03 cover filtering of > | application traffic > | > based on destination port? If yes, what error would be > | generated by a > | > NAT filtering out a certain type of application traffic to > | a certain > | > set of hosts? In that case, code 10 would not be the right > | one, as the > | > host might still be reachable on a different port. I feel that the > | > actual choice of error code would vary - it could be code > | 10 or code > | > 13 depending on the type of filtering. > | > | I don't see that difference; code 10 just says > | administratively prohibited, and code 13 says > | administratively prohibited because of filtering. In either > | case, other ports could be reachable. > | > | Joe > | > | > > _______________________________________________ > 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 Sun Apr 22 10:06: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 1Hfchs-0004mr-F8; Sun, 22 Apr 2007 10:06:24 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hfchq-0004lH-GA for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 10:06:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfchq-0004l9-6e for behave@ietf.org; Sun, 22 Apr 2007 10:06:22 -0400 Received: from web33308.mail.mud.yahoo.com ([68.142.206.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfcho-0000JE-Tm for behave@ietf.org; Sun, 22 Apr 2007 10:06:22 -0400 Received: (qmail 51487 invoked by uid 60001); 22 Apr 2007 14:06:20 -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=S5SvR8rkUuIQk2T9+k3Osy2KsxpKHeUhaby1GXZsRvymIjs0I9p3bajRZJxrzNDCh9hAKdL0lhsAFNb0IY+vkq9KjmkAjN7HrKEDtT0+7x+q/giK/tlhAy0M9cJn4ekbewcL/0CccPFfnvCGBL/5d4mNMI5y4hF82HCvku7O8ZY=; X-YMail-OSG: Gpk97Z0VM1loOlhZdTkhLTbudnO9CxnBTsuASVPTSJCqt_aN6lPcWupPckhN8dBhpcVJfw-- Received: from [69.236.67.182] by web33308.mail.mud.yahoo.com via HTTP; Sun, 22 Apr 2007 07:06:20 PDT Date: Sun, 22 Apr 2007 07:06:20 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 To: Joe Touch , "Faisal Siyavudeen \(fsiyavud\)" In-Reply-To: <461BCA0B.3010706@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <355540.51243.qm@web33308.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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 --- Joe Touch wrote: > > > Faisal Siyavudeen (fsiyavud) wrote: > > | > it could be code 10 or code 13 depending on the type of filtering. > > | > > | I don't see that difference; code 10 just says > > | administratively prohibited, and code 13 says > > | administratively prohibited because of filtering. In either > > | case, other ports could be reachable. > > | > > > > I agree. > > > > I am sorry I was not clear - my point was that 10 cannot be used where > > other ports on the hosts are still accessible, while 13 can be used in > > any of these cases. BTW, the following note in RFC 1812 makes me wonder > > if NAT devices can send code 10 at all as they are more like routers: > > Uh, routers decrement the TTL. NATs do not. I don't think NATs behave > like routers per se. > > > > > Codes 9 and 10 were intended for use by end-to-end encryption devices > > used by U.S military agencies. Routers SHOULD use the newly defined Code > > 13 (Communication Administratively Prohibited) if they administratively > > filter packets. > > > > That argues that NATs should generate their own codes. This is NOT > router administrative filtering either. [suresh] NAT forwards packets between nodes in private domain and public domain. If NAT cannot forward a packet due to resource constrains or administrative restrictions, NAT needs to specify a reason to the sender. ICMP code 13 closely matches the description of the cause. What is your argument against using code 13? regards, suresh > > Joe _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 22 10:28: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 1Hfd3N-00087W-ON; Sun, 22 Apr 2007 10:28:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hfd3M-00087R-Nr for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 10:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfd3M-00087J-EJ for behave@ietf.org; Sun, 22 Apr 2007 10:28:36 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfd3F-0006rE-Qv for behave@ietf.org; Sun, 22 Apr 2007 10:28:34 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 10:28:24 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 10:28:19 -0400 From: Saikat Guha To: behave In-Reply-To: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> References: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> Date: Sun, 22 Apr 2007 10:28:19 -0400 Message-Id: <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 22 Apr 2007 14:28:19.0784 (UTC) FILETIME=[796E6480:01C784EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Sam Hartman Subject: [BEHAVE] RE: DISCUSS and COMMENT: draft-ietf-behave-tcp 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="===============1072785133==" Errors-To: behave-bounces@ietf.org --===============1072785133== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-d4d2Kxl/nXrdpFNN06x5" --=-d4d2Kxl/nXrdpFNN06x5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable During the IESG last call of draft-ietf-behave-tcp, a couple of concerns were raised some of which were discussed on list. One recent concern adds a new requirement (REQ-9), which the authors wanted to bring to the list (Change #1 below). A new version of the draft is now available (to be posted shortly): I-D: http://saikat.guha.cc/pub/draft-ietf-behave-tcp-07.txt Diff: http://saikat.guha.cc/pub/draft-ietf-behave-tcp-07-from-06.diff.html Key changes: 1. PMTU support requirement: The new version now explicitly recommends PMTU support using RFC 2119 terminology. Previous version was silent on this issue and implicitly depended on the corresponding UDP recommendation. REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination Unreachable "Fragmentation Needed and Don't Fragment was Set" (Type 3, Code 4) messages. This text is consistent with both the UDP doc and recent WG discussion on the list. Additional text surrounding this requirement discourages filtering any destination unreachables for efficiency purposes. =20 2. Scope clarification: Clarify connections to the NAT itself (e.g. an=20 HTTP-management interface) are out-of-scope of this document. How to deal with such connections (be they TCP or UDP) is complex, which an=20 implementation-guideline document could address. 3. SACK support: Callout to implementers that packets with SACK notifications should be properly handled. cheers, --=20 Saikat --=-d4d2Kxl/nXrdpFNN06x5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGK3EDnFltqi691/oRAhnKAJ9jhmguL8Q1yES4E2uHOvY1+cn7PwCeM6HI dgXxRdzdkLkOrrMFdefMgt8= =fWvu -----END PGP SIGNATURE----- --=-d4d2Kxl/nXrdpFNN06x5-- --===============1072785133== 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 --===============1072785133==-- From behave-bounces@ietf.org Sun Apr 22 10:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfdHy-000776-UW; Sun, 22 Apr 2007 10:43:42 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfdHx-00076s-Ru for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 10:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfdHx-00076k-IE for behave@ietf.org; Sun, 22 Apr 2007 10:43:41 -0400 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfdHw-00036i-4j for behave@ietf.org; Sun, 22 Apr 2007 10:43:41 -0400 Received: (qmail 92709 invoked by uid 60001); 22 Apr 2007 14:43:39 -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=hR/rQ3QTEyVDBLpiERV9uKc8r+DVnhgqP6TMns7IQ/R4TS3SB6xn8Hl1Z/Qx4zmGUJh/m/IsQc0SdZE6WzVEcNcs+mgdRlFTdOEnGe0xjQOhwUzBK0bTkAdkoFvn2IN0NjAijKWiP1N99HOjvXLakDMD05j4Nl5cMoDvqb1TBmQ=; X-YMail-OSG: uqcz44MVM1kY_3eNK7DMaPDEaLuKFzSmq7fvGNk55quTDxX4xX3tjRFYkrSrT.eQ5r5vVcdmuU7zb9SdnIbu.wneBLNja3p6_qUXGEqj9iHh2rY- Received: from [69.236.67.182] by web33306.mail.mud.yahoo.com via HTTP; Sun, 22 Apr 2007 07:43:39 PDT Date: Sun, 22 Apr 2007 07:43:39 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 To: Joe Touch , Pekka Savola In-Reply-To: <461BDE8E.9000307@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <570982.92506.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tcpm@ietf.org, behave@ietf.org, "Faisal Siyavudeen \(fsiyavud\)" , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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 --- Joe Touch wrote: > > > Pekka Savola wrote: > ... > >> Uh, routers decrement the TTL. NATs do not. I don't think NATs behave > >> like routers per se. > > > > YMMV but all NATs I have seen and used do decrement TTL. (I've heard > > reports about ones that don't, but never seen one myself.) > > One of the nasty things about NATs (or the people who design them) is > that anything that makes them visible is likely to be disabled by some > subset, in the hopes of making it 'transparent'. > > Although many NATs do decrement the TTL, there is no such requirement. > RFC3022 (traditional NATs, informational) doesn't even mention it, and [suresh] You are right, there is no mention of TTL in RFC 3022. And, we donot have a BEHAVE recommendation on NATs at IP level to suggest a BCP. That said, it does not take away the fact that NAT is fundamentally a router. As Pekka said, most NAT devices do decrement TTL in the IP heder, > RFC2766 (NAT proposed standard) talks about setting TTL to 0 for DNS, > but says specifically that TTLs are not decremented for statically > mapped addresses (and has nothing to say about dynamic ones). [suresh] Joe - the TTL above refers to the time-to-Live of the DNS RR, not the TTL of the IP header. > Other docs > (MIDCOM, arch implications of NATs) don't require TTL decrement either. > > > I'd be interested in knowing in which conditions access to a network, > > host, or a subset of a host should be considered "administratively > > prohibited", but that administrative prohibition is not due to filtering > > (be it a firewall rule, access list, configuration toggle, or whatever). > > source address/reverse path validation comes to mind. > [suresh] You are saying that a router can send ICMP code 13 if source address of a packet it receives is invalid. This is some sort of an administrative configuration/restriction. It seems reasonable for NAT to use the same error code 13 when it runs out of resources or has another type of administrative restriction. > Yes, it might be set with a toggle, but it's not what most people > consider when then talk about packet filtering (at least IMO). [suresh] I do not understand your above comment. What might be set with a toggle? > > IMO, because a NAT behaves like an endpoint (to the Internet side), it > should send ICMPs like one, and issue ICMP host/port unreachables, not > administrative filtering that routers would send. That would also 'do > the right thing' by making the ICMPs result in hard errors. > [suresh] Joe - NAT is not an endpoint device. NAT does not run applications on itself. If it does, that is not within the scope of BEHAVE. You may be stuck on some semantics. But, most people would agree NAT is a routing device. NAT forwards packets between private and public nodes. When NAT doesnt allow a flow to go through it, it must do what is right for an intermediate device and send the appropriate ICMP error code to the sender - be it a public node or a private node. I dont know of any other error code that is more appropriate than ICMP code 13 to do this. regards, suresh > Joe > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > > _______________________________________________ > 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 Sun Apr 22 13:46:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfg8w-0001FL-UZ; Sun, 22 Apr 2007 13:46:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hfg8v-0001D6-1c for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 13:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfg8u-0001Cy-O8; Sun, 22 Apr 2007 13:46:32 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfg8t-0005V7-Bg; Sun, 22 Apr 2007 13:46:32 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3MHkD4g005128; Sun, 22 Apr 2007 10:46:14 -0700 (PDT) Message-ID: <462B9F55.1090008@isi.edu> Date: Sun, 22 Apr 2007 10:45:57 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <355540.51243.qm@web33308.mail.mud.yahoo.com> In-Reply-To: <355540.51243.qm@web33308.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============1087287570==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1087287570== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD77DCF3A4101327F6AE2C17B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD77DCF3A4101327F6AE2C17B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable NATs are not routers. Using a code defined in RFC1812 for this purpose is to inappropriately imply that a router is generating the code. Joe Pyda Srisuresh wrote: > --- Joe Touch wrote: >=20 >> >> Faisal Siyavudeen (fsiyavud) wrote: >>> | > it could be code 10 or code 13 depending on the type of filtering= =2E >>> |=20 >>> | I don't see that difference; code 10 just says=20 >>> | administratively prohibited, and code 13 says=20 >>> | administratively prohibited because of filtering. In either=20 >>> | case, other ports could be reachable. >>> |=20 >>> >>> I agree. >>> >>> I am sorry I was not clear - my point was that 10 cannot be used wher= e >>> other ports on the hosts are still accessible, while 13 can be used i= n >>> any of these cases. BTW, the following note in RFC 1812 makes me wond= er >>> if NAT devices can send code 10 at all as they are more like routers:= >> Uh, routers decrement the TTL. NATs do not. I don't think NATs behave >> like routers per se. >> >>> >>> Codes 9 and 10 were intended for use by end-to-end encryption devices= >>> used by U.S military agencies. Routers SHOULD use the newly defined C= ode >>> 13 (Communication Administratively Prohibited) if they administrative= ly >>> filter packets. >>> >> That argues that NATs should generate their own codes. This is NOT >> router administrative filtering either. >=20 > [suresh] NAT forwards packets between nodes in private domain and publi= c > domain. If NAT cannot forward a packet due to resource constrains or > administrative restrictions, NAT needs to specify a reason to the sende= r.=20 > ICMP code 13 closely matches the description of the cause. What is your= > argument against using code 13? =20 >=20 > regards, > suresh=20 >=20 >> Joe >=20 >=20 --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigD77DCF3A4101327F6AE2C17B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGK59VE5f5cImnZrsRAlFiAJ91+N8fWbpcWsg11mh07vkG88alqwCfSZrW wRQn08nOIAWBJiH3Vrsk1ek= =BI5y -----END PGP SIGNATURE----- --------------enigD77DCF3A4101327F6AE2C17B-- --===============1087287570== 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 --===============1087287570==-- From behave-bounces@ietf.org Sun Apr 22 13:50: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 1HfgCs-0003SI-BW; Sun, 22 Apr 2007 13:50:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfgCr-0003Rz-4q for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 13:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfgCq-0003Rr-RW; Sun, 22 Apr 2007 13:50:36 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfgCq-0006OJ-F5; Sun, 22 Apr 2007 13:50:36 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3MHoKCc005932; Sun, 22 Apr 2007 10:50:21 -0700 (PDT) Message-ID: <462BA04C.6090208@isi.edu> Date: Sun, 22 Apr 2007 10:50:04 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <570982.92506.qm@web33306.mail.mud.yahoo.com> In-Reply-To: <570982.92506.qm@web33306.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============1422250932==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1422250932== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCC6E867A554DBE9500992F7E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC6E867A554DBE9500992F7E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pyda Srisuresh wrote: > --- Joe Touch wrote: =2E.. >> Although many NATs do decrement the TTL, there is no such requirement.= >> RFC3022 (traditional NATs, informational) doesn't even mention it, and= >=20 > [suresh] You are right, there is no mention of TTL in RFC 3022. And, we= donot > have a BEHAVE recommendation on NATs at IP level to suggest a BCP. That= said, > it does not take away the fact that NAT is fundamentally a router. No, it is not. It would need to follow the entirety of RFC1812 to be a router; since decrementing the TTL is not required, it is *clearly* not a router. > As Pekka > said, most NAT devices do decrement TTL in the IP heder,=20 >=20 >> RFC2766 (NAT proposed standard) talks about setting TTL to 0 for DNS, >> but says specifically that TTLs are not decremented for statically >> mapped addresses (and has nothing to say about dynamic ones).=20 >=20 > [suresh] Joe - the TTL above refers to the time-to-Live of the DNS RR, = not the > TTL of the IP header.=20 Thanks for the detail; that is further evidence that NATs have nothing to do with routers, and are not routers. =2E.. >> IMO, because a NAT behaves like an endpoint (to the Internet side), it= >> should send ICMPs like one, and issue ICMP host/port unreachables, not= >> administrative filtering that routers would send. That would also 'do >> the right thing' by making the ICMPs result in hard errors. >> > [suresh] Joe - NAT is not an endpoint device. NAT does not run applicat= ions on > itself. If it does, that is not within the scope of BEHAVE.=20 A NAT sources packets with its own IP address; to the rest of the Internet, it behaves like an IP address source, and so IMO it is required to obey RFC1122 in all respects. > You may be stuck on some semantics. But, most people would agree NAT is= a > routing device. NAT forwards packets between private and public nodes. = When NAT > doesnt allow a flow to go through it, it must do what is right for an > intermediate device and send the appropriate ICMP error code to the sen= der - be > it a public node or a private node. I dont know of any other error code= that is > more appropriate than ICMP code 13 to do this. To the rest of the Internet (the public side), a NAT is clearly an IP source, and so must obey 1122. *IF* we want, we can require that NATs also obey 1812 on the private side - if we believe that the private device thinks the NAT is a router. I think that part isn't as clearly required. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigCC6E867A554DBE9500992F7E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGK6BNE5f5cImnZrsRAivGAJ4rYsoMR66pRCnFZA8FdebhPIuNBwCeMcal 349A0X7US1oUZp0HVhLkdmQ= =IuoR -----END PGP SIGNATURE----- --------------enigCC6E867A554DBE9500992F7E-- --===============1422250932== 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 --===============1422250932==-- From behave-bounces@ietf.org Sun Apr 22 17:04: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 1HfjED-0000wi-3n; Sun, 22 Apr 2007 17:04:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfjEB-0000wY-Sr for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 17:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfjEB-0000wL-JC for behave@ietf.org; Sun, 22 Apr 2007 17:04:11 -0400 Received: from web33308.mail.mud.yahoo.com ([68.142.206.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfjEB-0000l9-5s for behave@ietf.org; Sun, 22 Apr 2007 17:04:11 -0400 Received: (qmail 79917 invoked by uid 60001); 22 Apr 2007 21:04:10 -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=qQF8vK00SpSbXFeApy/YA5oYG7Qu9kOQHfoayTOxB4TYBfGsHLXABs3jgnuvn2IXCiAWCMwlvqqtx3bWp0BBJ3AIV4GDFs684T8CdZKitxzi3UndfYlrvAPWdjm8Eqnc6pjHRzEh/DVxbaR5MoqA0kZy+Bshz7A+xbx59BI3d8c=; X-YMail-OSG: TdMK0_kVM1k0fPYIbG7aK95tME_5SkCUh2BAdTJSes9ww2QjWep77j8A8DhrJoFiMCkYMw-- Received: from [69.236.67.182] by web33308.mail.mud.yahoo.com via HTTP; Sun, 22 Apr 2007 14:04:10 PDT Date: Sun, 22 Apr 2007 14:04:10 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 To: Joe Touch In-Reply-To: <462B9F55.1090008@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <623076.79726.qm@web33308.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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 Below is what RFC 1812 has to say about what constitutes a router. This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. The Internet community usually refers to such devices as IP routers or simply routers. NATs forward IP packets from one network to another. That makes NAT a router. And, it is appropriate for NAT to use the error codes a router device would use. If you insist NAT is not a router, I am not going to argue or get into a debate with you on this. I will simply disagree. So do the vast majority of people taht use NATs to connect to public networks. regards, suresh --- Joe Touch wrote: > NATs are not routers. Using a code defined in RFC1812 for this purpose > is to inappropriately imply that a router is generating the code. > > Joe > > Pyda Srisuresh wrote: > > --- Joe Touch wrote: > > > >> > >> Faisal Siyavudeen (fsiyavud) wrote: > >>> | > it could be code 10 or code 13 depending on the type of filtering. > >>> | > >>> | I don't see that difference; code 10 just says > >>> | administratively prohibited, and code 13 says > >>> | administratively prohibited because of filtering. In either > >>> | case, other ports could be reachable. > >>> | > >>> > >>> I agree. > >>> > >>> I am sorry I was not clear - my point was that 10 cannot be used where > >>> other ports on the hosts are still accessible, while 13 can be used in > >>> any of these cases. BTW, the following note in RFC 1812 makes me wonder > >>> if NAT devices can send code 10 at all as they are more like routers: > >> Uh, routers decrement the TTL. NATs do not. I don't think NATs behave > >> like routers per se. > >> > >>> > >>> Codes 9 and 10 were intended for use by end-to-end encryption devices > >>> used by U.S military agencies. Routers SHOULD use the newly defined Code > >>> 13 (Communication Administratively Prohibited) if they administratively > >>> filter packets. > >>> > >> That argues that NATs should generate their own codes. This is NOT > >> router administrative filtering either. > > > > [suresh] NAT forwards packets between nodes in private domain and public > > domain. If NAT cannot forward a packet due to resource constrains or > > administrative restrictions, NAT needs to specify a reason to the sender. > > ICMP code 13 closely matches the description of the cause. What is your > > argument against using code 13? > > > > regards, > > suresh > > > >> Joe > > > > > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 22 17:12: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 1HfjM3-0005sJ-GA; Sun, 22 Apr 2007 17:12:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfjM1-0005sB-SI for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 17:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfjM1-0005s3-Ir; Sun, 22 Apr 2007 17:12:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfjM0-0001zw-6i; Sun, 22 Apr 2007 17:12:17 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3MLBmoF012871; Sun, 22 Apr 2007 14:11:49 -0700 (PDT) Message-ID: <462BCF84.6040706@isi.edu> Date: Sun, 22 Apr 2007 14:11:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <623076.79726.qm@web33308.mail.mud.yahoo.com> In-Reply-To: <623076.79726.qm@web33308.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============1751875894==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1751875894== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C81E59175C4D6D4A9686202" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C81E59175C4D6D4A9686202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pyda Srisuresh wrote: > Below is what RFC 1812 has to say about what constitutes a router. >=20 > This memo defines and discusses requirements for devices that perform= > the network layer forwarding function of the Internet protocol suite.= > The Internet community usually refers to such devices as IP routers o= r > simply routers. The rest of that document is what defines what is an Internet router. Being a device that does network layer forwarding and violates any of the rest of that doc means that device is not an Internet router. > NATs forward IP packets from one network to another. That makes NAT a r= outer. NATs don't follow the requirement of: - decrement the TTL - do not modify the source or destination IP address (except as per source-routing options) =2E.. > If you insist NAT is not a router, I am not going to argue or get into = a debate > with you on this. I will simply disagree. So do the vast majority of pe= ople > taht use NATs to connect to public networks. They can and have disagreed before, but this isn't up for a popular vote. It's utterly useless to talk about using any sort of IETF standard - including ICMP type 3 code 13 - and expect the rest of the Internet to follow that standard when NATs violate the standard of what it means to be a router. Joe --------------enig7C81E59175C4D6D4A9686202 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGK8+FE5f5cImnZrsRAsPSAKD0SmYQL75i5R+Vda+3cb03u33wagCbBgQp efScZuhYs5nCKTXiS1lLZ1Y= =g48G -----END PGP SIGNATURE----- --------------enig7C81E59175C4D6D4A9686202-- --===============1751875894== 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 --===============1751875894==-- From behave-bounces@ietf.org Sun Apr 22 20:36:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmXB-0001pJ-MW; Sun, 22 Apr 2007 20:36:01 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfmX9-0001oT-PL for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 20:35:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmX9-0001oL-Fq; Sun, 22 Apr 2007 20:35:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfmX8-0003Hz-7g; Sun, 22 Apr 2007 20:35:59 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2007 17:35:57 -0700 X-IronPort-AV: i="4.14,439,1170662400"; d="scan'208"; a="414380539:sNHT45889216" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3N0ZvMf002358; Sun, 22 Apr 2007 17:35:57 -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 l3N0ZsA9027444; Mon, 23 Apr 2007 00:35:54 GMT In-Reply-To: <462B9F55.1090008@isi.edu> References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> 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] Re: [tcpm] icmp type 3, code 13 Date: Sun, 22 Apr 2007 17:35:22 -0700 To: Joe Touch X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=292; t=1177288557; x=1178152557; c=relaxed/simple; s=sjdkim7002; 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=20[tcpm]=20icmp=20type=203, =20code=2 013 |Sender:=20; bh=iE5hZQibrpc9DNA4PcShm0qWXLuDa/36w36a1tovytk=; b=N881WKdBGhL+j5RkEKAJa65UJO/JRt3K8xYckB+rgIb190/OjCYmdslq7YSjiZ4NqWqirpIT D3LXRTAjzztWcKChLN/RWrZYFQrze9kMe6GT7ADDDsm5iJwvq6ptenxw; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: tcpm@ietf.org, behave@ietf.org, Pekka Savola , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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 Apr 22, 2007, at 10:45 AM, Joe Touch wrote: > NATs are not routers. Using a code defined in RFC1812 for this purpose > is to inappropriately imply that a router is generating the code. agree - and point out this has been said many times by several different people in Behave. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 22 20:44:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmfC-0005o2-Pr; Sun, 22 Apr 2007 20:44:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfmfB-0005nw-H7 for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 20:44:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmfB-0005no-7Y for behave@ietf.org; Sun, 22 Apr 2007 20:44:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfmf9-0005EB-Vp for behave@ietf.org; Sun, 22 Apr 2007 20:44:17 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 22 Apr 2007 17:44:15 -0700 X-IronPort-AV: i="4.14,439,1170662400"; d="scan'208"; a="55423577:sNHT90188577" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3N0iF4q031862; Sun, 22 Apr 2007 17:44:15 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l3N0iDwo025161; Mon, 23 Apr 2007 00:44:14 GMT In-Reply-To: <1176901230.4818.6.camel@slack> References: <025e01c78148$d48f54a0$6f02a8c0@Quinthar> <6F406657-8604-4F21-A950-BD6C70DBFB96@apple.com> <7D6481C8-64BC-4F13-8158-F2DD2147ED42@mit.edu> <1176887904.6657.26.camel@sioux.systems.cs.cornell.edu> <1176901230.4818.6.camel@slack> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1815F147-2E0B-4F40-A197-1D37BD8A75E0@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] Endpoint-independent filtering is the way to go. Date: Sun, 22 Apr 2007 17:43:41 -0700 To: Bryan Ford X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=485; t=1177289055; x=1178153055; c=relaxed/simple; s=sjdkim8002; 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]=20Endpoint-independent=20filtering=20is=20th e=20way=20to=20go. |Sender:=20; bh=NmtrhnY/vtl/R+3Z/6E5UFNiSXprZ/gZ+mIbP0A+7GQ=; b=O7grQclbYjSMyNNxB+M67QmBeMiWmwlVXrvJAEv5udAbCDdwhyisnJ4ftdSC6q0sKvd96OjE cy5YIZ6C3qt0anBOfjclH94lbbcPMLBBlhiaxneOt5whtvcpZoxtQZQu; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF 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 Apr 18, 2007, at 6:00 AM, Bryan Ford wrote: > But it doesn't leave the NATted host vulnerable to ANYONE and > EVERYONE - > at most it is vulnerable to an external host that has the resources to > scan systematically for the public port - which is typically in the > large upper range well clear of standard port assignments. > I think if you go an look at serious botnet code you will find that lots of it does exactly that Cullen < with my individual hat on> _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 22 21:03: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 1HfmxK-0006Ja-U7; Sun, 22 Apr 2007 21:03:02 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfmxJ-0006JU-KJ for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 21:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmxJ-0006JM-9v for behave@ietf.org; Sun, 22 Apr 2007 21:03:01 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfmxI-0004FE-W0 for behave@ietf.org; Sun, 22 Apr 2007 21:03:01 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 22 Apr 2007 18:03:00 -0700 X-IronPort-AV: i="4.14,439,1170662400"; d="scan'208"; a="55430744:sNHT181380753" 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 l3N130tr013100; Sun, 22 Apr 2007 18:03:00 -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 l3N12wZU028979; Mon, 23 Apr 2007 01:02:58 GMT In-Reply-To: <200704181036.22016.remi.denis-courmont@nokia.com> References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <008201c78186$85487eb0$75240046@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <200704181036.22016.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: Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Sun, 22 Apr 2007 18:02:26 -0700 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2454; t=1177290180; x=1178154180; 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]=20RE=3A=20Endpoint-independent=20filtering=2 0=20is=20the=20way=20to=20go. |Sender:=20; bh=i6cRZafObSpA2hPDbrkO2YeDdLaf9fy3ZeZI42RVtnY=; b=JEqMaWcKrtTgOtfWacbjQyq5LHUZpEH1NekH5Z5vLsuYTAkgJFlAWZs2aPO4LRDSh0ElD8ja bfElvurQyqEI9JX82+u4xDQ/iLQ02CCBkKKVrgjc+9xH18NxR6LBvgli; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 I'm curios about what you are suggesting here - let's say two nodes =20 both behind different NAT want to communicate and there is no =20 rendezvous server. I'll assume the NATs have Endpoint-independent =20 filtering. How does this work without a rendezvous server? What =20 address do they use. If the plan is to manually configure port forwarding in one of the =20 NATs then use something like dyndns to find the port then I don't =20 think you should be worried. Every NAT i have seen that supports =20 static port forwarding has done independent filtering on that NAT =20 (though the NAT may be doing address dependent filtering on all the =20 dynamically allocated ports). Doing anything else would be sort of =20 crazy and require entry of the specific address from which to accept =20 packets in the static port forward rule. I'll also note this is using =20= dyndns as a rendezvous server. Cullen On Apr 18, 2007, at 12:36 AM, R=E9mi Denis-Courmont wrote: > > > But then there is always the need for some rendez-vous point that =20 > is not > firewalled (SIP registrar, Teredo server...). Not that I consider =20 > this a > problem myself, but I cannot see this working in a DHT typeof =20 > network, if all > nodes are behind stateful firewalls. > > Also for non-UDP transports, I am slightly suspicious... For TCP =20 > simultaneous > open to work, there is the requirements that the firewall does not =20 > send ICMP > errors (c.f. BEHAVE-TCP)... and that's not specified in IPv6 case, =20 > as far as > I know. > > That being said, I can only agree with the notion that apps should > use "side-effect" of firewalling rather than depend on a signaling =20 > protocol > that is likely not implemented by the gateway. But I do not see =20 > these as > contradictory either; signaling has some advantages such as support =20= > for > detecting firewall reboots or requesting real pinholing that hole =20 > punching > will never support. > > Another good thing with signaling is the ability to negociate the =20 > refresh > timer, which is known to matter for mobile devices, as sending refresh > packets every so often drains the battery. > > --=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 Sun Apr 22 22:58: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 1HfolT-0006n6-Dn; Sun, 22 Apr 2007 22:58:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfolS-0006jB-DP for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 22:58:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfolS-0006ir-1J for behave@ietf.org; Sun, 22 Apr 2007 22:58:54 -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 1HfolQ-00012D-OW for behave@ietf.org; Sun, 22 Apr 2007 22:58:54 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2007 19:58:53 -0700 X-IronPort-AV: i="4.14,439,1170662400"; d="scan'208"; a="480537599:sNHT54925956" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3N2wpow015174; Sun, 22 Apr 2007 19:58:51 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l3N2wpwo007522; Mon, 23 Apr 2007 02:58:51 GMT In-Reply-To: <38464B16719C77439C06051F392AB9E6062EB2EB@CAVS1.sanmateo.corp.akamai.com> References: <38464B16719C77439C06051F392AB9E6062EB2EB@CAVS1.sanmateo.corp.akamai.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] RE: Endpoint-independent filtering is the way to go. Date: Sun, 22 Apr 2007 19:58:18 -0700 To: "Barrett, David" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4459; t=1177297132; x=1178161132; c=relaxed/simple; s=sjdkim5002; 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=20Endpoint-independent=20filtering=2 0=20is=20the=20way=20to=20go. |Sender:=20; bh=cgpqNCOcsvgpamG7xEO3nCBjVfhux5DhwWVDYlWq7Vo=; b=NafOcg+eITKb0LZS8MHqiVVzJOlp3yCCz44++bZ2TnRt9Qasc8iWMw9UiDXFjKchazDxPKvk sR3+Pgk+vZPaKoSTZ9EOy0a+PiRKGQF2KEDrY034OopYBcJCuPQEYXuL; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 Apr 17, 2007, at 6:55 PM, Barrett, David wrote: >> -----Original Message----- >> From: Bryan Ford [mailto:baford@MIT.EDU] >> >> Basically, I ended up being the only one in the whole (pretty fully) >> room advocating even that relatively weak language, recommending that >> users even be allowed to configure their NATs for endpoint- >> independent filtering behavior. So I gave up and let the group do >> what they wanted to. I am pretty sure that the room had people from at least three different companies that were doing P2P work and wanted NATs to work - but to agreeing with Bryan's point, they were probably not a large part of the people in the room. My view would be that most of the people in the room thought that 1) P2P stuff will work better than Bryan thinks it will work with endpoint dependent filtering (but they understand we have to have endpoint independent mapping) 2) the security provided by endpoint dependent filtering in firewalls is more important to them than it is to Bryan. > > Cullen -- Is it safe to say that the consensus of the BEHAVE group > is the benefit offered by decentralized overlay networks (e.g., > DHTs) are outweighed by the security risks of endpoint-independent > mapping? No - I don't think that was exactly what was happening. I think the group believed that the security was achievable at the same time as DHTs. We have lots of examples of P2P applications, some of them DHT based, that work fine with endpoint-dependent mappings. Christian posted about Microsoft work earlier on this thread, Skype would be another well known example, the dsip protocol draft in P2PSIP WG. It's hard to go back in time and guess what people were thinking but I know what several people argued and what I suspect most people were thinking was that they could build P2P application without endpoint- independent mapping. I suspect that many of them were also thinking that for anywhere where a firewall functionality was required, endpoint-independent mapping would be the death nail of behave being implemented. The bulk of residential NATs todays include "SPI" which usually means endpoint dependent filtering. I will note that apple is an exception to this - but I don't envy the role of the apple engineering folks that have to explain to the marketing folks that CNET and other reviews are wrong and it is good that the Airports don't have SPI. And I hope Apple can turn this into enough of a feature for the environments it is suitable for - the Behave UDP specs are written such that something that works like the Apple could be behave complaint and so could something that include SPI. I think firewalls are one of the defensive in depths techniques that help security - particularly given what seem to be the general state of end host security today where every major OS includes a stream of security patches. Certainly some people at IETF will argue SPI firewalls are useless - however, even theses people will agree that an pragmatic view of the future is that a large percentage of endpoints are going to be behind them. Even if the world moves to IPv6, and all NATs go away, the v6ops people are still assuming firewalls will be in use that do SPI. All of this is why Behave does not specify firewall behavior but tries to make sure that it is possible to be a behave complaint NAT and still do the things a minimal firewall often does. Greg Lebovitz explained this very clearly in the BOF before Behave was chartered and had strong consensus behind this - I think he has explained it again in many of the Behave meetings including the last one in Prague. > > Given that the IETF-chartered P2P-SIP folks are actively building a > DHT that requires a high fraction of endpoint-independent filtered > nodes, shouldn't we inform them that we're on a collision course > and they need to redesign as a result? No - I don't think there is a collision course here - the people doing NAT work in the P2PSIP group are very aware of what Behave is recommending and are designing applications that work in that environment. > > -david > > Cullen < with my individual hat on> > > _______________________________________________ > 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 Mon Apr 23 00:45: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 1HfqQj-0005YT-NV; Mon, 23 Apr 2007 00:45:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfqQh-0005YF-VU for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 00:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfqQg-0005Xi-RK for behave@ietf.org; Mon, 23 Apr 2007 00:45:34 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfqQe-00068h-Ao for behave@ietf.org; Mon, 23 Apr 2007 00:45:34 -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 l3N4jA2P032534; Mon, 23 Apr 2007 07:45:29 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 07:45:27 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 07:45:26 +0300 Received: from esdhcp041138.research.nokia.com (esdhcp041138.research.nokia.com [172.21.41.138]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3N4jP3t024097; Mon, 23 Apr 2007 07:45:25 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Successful Responses in TURN Date: Mon, 23 Apr 2007 07:45:29 +0300 User-Agent: KMail/1.9.6 References: <462B0FEE.7030701@gmail.com> In-Reply-To: <462B0FEE.7030701@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704230745.29312.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 23 Apr 2007 04:45:26.0783 (UTC) FILETIME=[364FB0F0:01C78562] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Sunday 22 April 2007 10:34:06 ext Evgeniy Khramtsov wrote: > Looks like some TURN responses are not documented in the I-D, or, > perhaps, I'm misreading something :) > However, I have 3 questions: > > 1. What should the server reply to the successful Set Active Destination > request? > 2. What should the server reply to the successful Allocate request with > the LIFETIME attribute set to 0 (aka 'destroying an allocation' request)? Since this is not explicitly specified, my understanding is that it sends a= =20 normal successful Allocate response with 0 as lifetime. > 3. What should the server reply to the successful Connect request? > Formally, if the response is not documented in the spec, the server > should not generate the response. Is it really true? No. Considering the "base" STUN specification, a Request always gets either= a=20 Response or an Error Response as an answer. Also note that it is now offici= al=20 that OR'ing with 0x100 resp. 0x110 makes a Response resp. Error Response co= de=20 out of a Request code. =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 Apr 23 00:58: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 1Hfqcp-0006y6-4X; Mon, 23 Apr 2007 00:58:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hfqcn-0006tt-QQ for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 00:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfqcn-0006tl-Gw for behave@ietf.org; Mon, 23 Apr 2007 00:58:05 -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 1Hfqcl-0002Fb-T1 for behave@ietf.org; Mon, 23 Apr 2007 00:58:05 -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 l3N4vwmB015368; Mon, 23 Apr 2007 07:58:00 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 07:57:59 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 07:57:59 +0300 Received: from esdhcp041138.research.nokia.com (esdhcp041138.research.nokia.com [172.21.41.138]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3N4vvsP007151; Mon, 23 Apr 2007 07:57:57 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Cullen Jennings" Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Mon, 23 Apr 2007 07:58:01 +0300 User-Agent: KMail/1.9.6 References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <200704181036.22016.remi.denis-courmont@nokia.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: <200704230758.01590.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 23 Apr 2007 04:57:59.0278 (UTC) FILETIME=[F6D550E0:01C78563] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 23 April 2007 04:02:26 ext Cullen Jennings wrote: > I'm curios about what you are suggesting here - let's say two nodes > both behind different NAT want to communicate and there is no > rendezvous server. I'll assume the NATs have Endpoint-independent > filtering. How does this work without a rendezvous server? I would assume that DHTs would be significantly harder to deploy if only a= =20 limited subsets of the nodes have endpoint-independant filtering if at all.= =20 However, not being involved in that kind of stuff, I am in no position to=20 propose anything in that regard. As far as I am concerned (i.e. being=20 selfish), Rendez-vous servers are fine. =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 Apr 23 08:41: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 1Hfxr5-0003I3-8Z; Mon, 23 Apr 2007 08:41:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hfxr4-0003EK-7C for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 08:41:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfxr3-0003EC-Sb for behave@ietf.org; Mon, 23 Apr 2007 08:41:17 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hfxr2-0001Gu-Fc for behave@ietf.org; Mon, 23 Apr 2007 08:41:17 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3NCfDeJ001646; Mon, 23 Apr 2007 08:41:13 -0400 (EDT) Received: from [192.168.1.105] (pool-68-160-6-231.bos.east.verizon.net [68.160.6.231]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3NCfApC006488 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Apr 2007 08:41:10 -0400 (EDT) Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. From: Bryan Ford To: Cullen Jennings In-Reply-To: References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <008201c78186$85487eb0$75240046@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <200704181036.22016.remi.denis-courmont@nokia.com> Content-Type: text/plain Organization: Massachusetts Institute of Technology Date: Mon, 23 Apr 2007 08:41:09 -0400 Message-Id: <1177332069.5638.36.camel@slack> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Sun, 2007-04-22 at 18:02 -0700, Cullen Jennings wrote: > I'm curios about what you are suggesting here - let's say two nodes > both behind different NAT want to communicate and there is no > rendezvous server. I'll assume the NATs have Endpoint-independent > filtering. How does this work without a rendezvous server? What > address do they use. Let's be more specific: say they're two nodes participating in a DHT. They can learn each others' address/port from any third node already participating in the DHT (which may also be behind a NAT). Any node already in the DHT with endpoint-independent filtering will do, and if the DHT is big and endpoint-independent filtering is widespread, there should be many such nodes - even if practically all of the nodes in the DHT are behind NATs. The same applies if a node is already in the DHT but it is just searching through the DHT for a particular key - it typically has to contact log(N) nodes to find the key it wants, and if these nodes have endpoint-independent filtering, it just finds the next target node's address/port from the previous one. This all falls out naturally from any DHT's join/maintenance protocol. But if nodes with endpoint-independent filtering are rare, then the DHT algorithm breaks down because all the NATted DHT node have to hammer on one or a very few "true" public rendezvous servers whenever they need to talk to ANYONE new. That's O(log(N)) separate runs of STUN or something similar through the central STUN server whenever ANY node wants to join or lookup ANYTHING - i.e., O(N log(N)) overall load. DHT nodes with endpoint-dependent filtering can't help out other nodes - they're truly "second-class citizens". You know, 3/5ths of a person and all that. And if DHT nodes can't help each other out, there's probably no benefit of having a DHT at all anymore. Since you have a server big enough to handle the demands of all the clients at once anyway just to handle the hole punching load, you might as well just run a centralized hash table on that big server in the first place. > If the plan is to manually configure port forwarding in one of the > NATs then use something like dyndns to find the port then I don't > think you should be worried. The plan is very much NOT to have to manually configure port forwarding - most users don't have the foggiest clue what a port is and definitely don't want to have to learn. That's why self-organizing distributed apps really need either endpoint-independent filtering by default, or SOME way to punch endpoint-independent filtering holes explicitly (assuming local security policy permits) with no manual configuration, via something like UPnP or NAT-PMP. Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 10:14: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 1HfzJQ-0002v0-SO; Mon, 23 Apr 2007 10:14:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HfzJP-0002ub-8y for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 10:14:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzJO-0002uT-Vc; Mon, 23 Apr 2007 10:14:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfzJM-0002Bx-29; Mon, 23 Apr 2007 10:14:38 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NEEJu4028700; Mon, 23 Apr 2007 07:14:20 -0700 (PDT) Message-ID: <462CBF2B.2040100@isi.edu> Date: Mon, 23 Apr 2007 07:14:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <0C53DCFB700D144284A584F54711EC58033AD7BD@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58033AD7BD@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0507186536==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0507186536== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig673476E372F3D43386EE838B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig673476E372F3D43386EE838B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > Firstly, why is this being disussed in tcpm? This doesn't apply to TCP > directly. [ even in-directly it might apply to all other transport > protocols who can/may want to act on these errors] Maybe tsvwg is more > appropriate?=20 That's possible; someone in Behave might start by posting a summary of the question there as well. > As far as the current discussion goes, there is a thin line of > distinction between hosts and routers, today. There may be many devices that do both functions, but to the extent they do they must then obey both the host and router requirements. > Today's routers do all > sort of things which were only done by end-hosts at one point of time. Such as? Other than acting like end hosts for connections that terminate at routers, which they have always done, and always required RFC1122-level support... > So any discussion which is based on the semantics of a > router/switch/host is IMO, useless, since things have evolved. Until the requirements in the IETF are updated to reflect this opinion, it is irrelevant. > Also, actually, when you say "NAT's are not routers", there is a lot of= > ambiguity there : >=20 > Typical case where NAT is configured in a router, which means that this= > device, applies NAT rule and route's the packets.=20 Then the part that routes must obey RFC1812 rules. If the part that routes can respond in lieu of the part that NATs, then that's fine. But when the part that NATs acts, it can't act like the router. > So are you saying :- =2E.. > - generate a ICMP error code if the error is a result of a "routing > operation" and NOT as a result of "NAT operation"?=20 Yes. > I really don't see a > value in seperating these and it boils down to pure semantic argument, > IMO, without considering the characteristics of the deployed Internet > today.=20 First, there are plenty of devices that do not combine both functions, and that's where we're talking about. However, in the case of the combined device, it still makes sense to determine WHY an error code is being generated. If because of a routing issue, then RFC1812 works; if because of a NAT issue, then RFC1812 is NOT the guiding document. Joe >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU]=20 >> Sent: Sunday, April 22, 2007 2:12 PM >> To: Pyda Srisuresh >> Cc: tcpm@ietf.org; behave@ietf.org; Mahesh Govind (mgovind);=20 >> Dan Wing (dwing); Faisal Siyavudeen (fsiyavud) >> Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 >> >> >> >> Pyda Srisuresh wrote: >>> Below is what RFC 1812 has to say about what constitutes a router. >>> >>> This memo defines and discusses requirements for devices=20 >> that perform >>> the network layer forwarding function of the Internet=20 >> protocol suite. >>> The Internet community usually refers to such devices as=20 >> IP routers or >>> simply routers. >> The rest of that document is what defines what is an Internet router. >> Being a device that does network layer forwarding and=20 >> violates any of the rest of that doc means that device is not=20 >> an Internet router. >> >>> NATs forward IP packets from one network to another. That=20 >> makes NAT a router. >> >> NATs don't follow the requirement of: >> - decrement the TTL >> - do not modify the source or destination IP address >> (except as per source-routing options) >> >> ... >>> If you insist NAT is not a router, I am not going to argue=20 >> or get into=20 >>> a debate with you on this. I will simply disagree. So do the vast=20 >>> majority of people taht use NATs to connect to public networks. >> They can and have disagreed before, but this isn't up for a=20 >> popular vote. It's utterly useless to talk about using any=20 >> sort of IETF standard >> - including ICMP type 3 code 13 - and expect the rest of the=20 >> Internet to follow that standard when NATs violate the=20 >> standard of what it means to be a router. >> >> Joe >> >> >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig673476E372F3D43386EE838B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLL8rE5f5cImnZrsRAkaYAKCxHpQK6ru7L9JJ6eA2rbljJnNUewCgmRX8 htxwE5SggzIVlM9/mRAPMuQ= =+D/E -----END PGP SIGNATURE----- --------------enig673476E372F3D43386EE838B-- --===============0507186536== 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 --===============0507186536==-- From behave-bounces@ietf.org Mon Apr 23 12:01: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 1Hg0yQ-0003dy-MX; Mon, 23 Apr 2007 12:01:06 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg0yP-0003dV-6F for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0yO-0003bj-SK for behave@ietf.org; Mon, 23 Apr 2007 12:01:04 -0400 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0yN-0005qp-IK for behave@ietf.org; Mon, 23 Apr 2007 12:01:04 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l3NG0vBn015130; Mon, 23 Apr 2007 12:00:57 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l3NG0ube005603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 12:00:57 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 23 Apr 2007 12:00:53 -0400 To: Cullen Jennings , Joe Touch X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Behave WG Subject: [BEHAVE] Are NATs routers? 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 [Starting a new thread and trimming the CC list] On 22-Apr-07, at 20:35 , Cullen Jennings wrote: > > On Apr 22, 2007, at 10:45 AM, Joe Touch wrote: > >> NATs are not routers. Using a code defined in RFC1812 for this >> purpose >> is to inappropriately imply that a router is generating the code. > > agree - and point out this has been said many times by several > different people in Behave. I am guessing that this came up before I started attending BEHAVE meetings, but I would be interesting in hearing more about why NATs are not routers, or at least router-like. As I see it, most NAT boxes have different subnets on their public and private sides, so they look rather similar to a router to me. Regarding the TTL, perhaps I am missing something, but wouldn't we want a NAT to decrement the TTL field as the packet passes through? Perhaps this is a new requirement? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 12:08: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 1Hg15t-0008W0-Lm; Mon, 23 Apr 2007 12:08:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg15r-0008Vl-RV for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:08:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg15r-0008VN-7t for behave@ietf.org; Mon, 23 Apr 2007 12:08:47 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg15q-0000Ly-4a for behave@ietf.org; Mon, 23 Apr 2007 12:08:47 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 23 Apr 2007 09:08:45 -0700 X-IronPort-AV: i="4.14,443,1170662400"; d="scan'208"; a="55564351:sNHT53912304" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3NG8jFu000776; Mon, 23 Apr 2007 09:08:45 -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 l3NG8iA9011828; Mon, 23 Apr 2007 16:08:45 GMT In-Reply-To: <1177332069.5638.36.camel@slack> References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <008201c78186$85487eb0$75240046@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <200704181036.22016.remi.denis-courmont@nokia.com> <1177332069.5638.36.camel@slack> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B6CE47D-12F1-4CD5-A58C-BEB72C0DBBE3@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Mon, 23 Apr 2007 09:08:14 -0700 To: Bryan Ford X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3469; t=1177344525; x=1178208525; c=relaxed/simple; s=sjdkim5002; 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=20Endpoint-independent=20filtering=2 0=20is=20the=20way=20to=20go. |Sender:=20; bh=4dsWvYFd/4kONk2+EaN/52GCxssKD/5VBVZ+znF3qtk=; b=JfrHmhmxJnkf51Uk33ylh3mI0WRVGHhIWIBPU3xIOX0hFuqygyd+yuV3Ruxd3GOTP+rUtQ6Y dr9B6TPjiZSHN9hpY6bLUEmFsuDc0usCs5BkyCmbYIpe3Fbns49aTFQc; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Apr 23, 2007, at 5:41 AM, Bryan Ford wrote: > On Sun, 2007-04-22 at 18:02 -0700, Cullen Jennings wrote: >> I'm curios about what you are suggesting here - let's say two nodes >> both behind different NAT want to communicate and there is no >> rendezvous server. I'll assume the NATs have Endpoint-independent >> filtering. How does this work without a rendezvous server? What >> address do they use. > > Let's be more specific: say they're two nodes participating in a DHT. > They can learn each others' address/port from any third node already > participating in the DHT (which may also be behind a NAT). Any node > already in the DHT with endpoint-independent filtering will do, and if > the DHT is big and endpoint-independent filtering is widespread, there > should be many such nodes - even if practically all of the nodes in > the > DHT are behind NATs. The same applies if a node is already in the DHT > but it is just searching through the DHT for a particular key - it > typically has to contact log(N) nodes to find the key it wants, and if > these nodes have endpoint-independent filtering, it just finds the > next > target node's address/port from the previous one. This all falls out > naturally from any DHT's join/maintenance protocol. > > But if nodes with endpoint-independent filtering are rare, then the > DHT > algorithm breaks down because all the NATted DHT node have to > hammer on > one or a very few "true" public rendezvous servers whenever they > need to > talk to ANYONE new. That's O(log(N)) separate runs of STUN or > something > similar through the central STUN server whenever ANY node wants to > join > or lookup ANYTHING - i.e., O(N log(N)) overall load. DHT nodes with > endpoint-dependent filtering can't help out other nodes - they're > truly > "second-class citizens". You know, 3/5ths of a person and all that. > > And if DHT nodes can't help each other out, there's probably no > benefit > of having a DHT at all anymore. Since you have a server big enough to > handle the demands of all the clients at once anyway just to handle > the > hole punching load, you might as well just run a centralized hash > table > on that big server in the first place. Ok - I get where the disconnect is now ... Let's as-sum *every* node in the DHT is behind an address dependent filtering NAT except the boot strap nodes - clearly we don't want all the traffic in the DHT flowing thought the bootstrap nodes - that would not scale as you point out. I think you and I have the same requirements here and I think that they can be meant in this case - I will explain how below. Say B is bootstrap node, A is some node in the DHT, and C wants to join and C's finger table causes it to want to have a connection to A. C contacts B to join the ring and uses it to route messages while it builds it's finger table. When it wants to build a connection to A, the A and C nodes do the normal NAT whole punching thing (either with UDP or TCP) to form a direction connection - while they are doing this the roue messages via the DHT (which is the rendezvous service) to bring up the connection. But once they have done this, they can send messages directly to each other. So in the case above, the first few nodes would route messages via the bootstrap node until their finger tables are up but after that they don't. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 12: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 1Hg1DH-0007Fe-8g; Mon, 23 Apr 2007 12:16:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg1DG-0007FB-Sb for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1DF-0007Eu-7S for behave@ietf.org; Mon, 23 Apr 2007 12:16:26 -0400 Received: from mx2-7.spamtrap.magma.ca ([209.217.78.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1DE-0002mO-TZ for behave@ietf.org; Mon, 23 Apr 2007 12:16:25 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx2-7.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3NGGNcq004441; Mon, 23 Apr 2007 12:16:23 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l3NGGM2f026825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 12:16:23 -0400 In-Reply-To: <1177332069.5638.36.camel@slack> References: <70C6EFCDFC8AAD418EF7063CD132D064044790B1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <008201c78186$85487eb0$75240046@Quinthar> <70C6EFCDFC8AAD418EF7063CD132D064044790B4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <200704181036.22016.remi.denis-courmont@nokia.com> <1177332069.5638.36.camel@slack> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51E603CA-ECF8-4127-8CD4-80B4FC51DB0C@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Mon, 23 Apr 2007 12:16:19 -0400 To: Bryan Ford X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 23-Apr-07, at 08:41 , Bryan Ford wrote: > On Sun, 2007-04-22 at 18:02 -0700, Cullen Jennings wrote: >> I'm curios about what you are suggesting here - let's say two nodes >> both behind different NAT want to communicate and there is no >> rendezvous server. I'll assume the NATs have Endpoint-independent >> filtering. How does this work without a rendezvous server? What >> address do they use. > > Let's be more specific: say they're two nodes participating in a DHT. > They can learn each others' address/port from any third node already > participating in the DHT (which may also be behind a NAT). Any node > already in the DHT with endpoint-independent filtering will do, and if > the DHT is big and endpoint-independent filtering is widespread, there > should be many such nodes - even if practically all of the nodes in > the > DHT are behind NATs. The same applies if a node is already in the DHT > but it is just searching through the DHT for a particular key - it > typically has to contact log(N) nodes to find the key it wants, and if > these nodes have endpoint-independent filtering, it just finds the > next > target node's address/port from the previous one. This all falls out > naturally from any DHT's join/maintenance protocol. > > But if nodes with endpoint-independent filtering are rare, then the > DHT > algorithm breaks down because all the NATted DHT node have to > hammer on > one or a very few "true" public rendezvous servers whenever they > need to > talk to ANYONE new. That's O(log(N)) separate runs of STUN or > something > similar through the central STUN server whenever ANY node wants to > join > or lookup ANYTHING - i.e., O(N log(N)) overall load. DHT nodes with > endpoint-dependent filtering can't help out other nodes - they're > truly > "second-class citizens". You know, 3/5ths of a person and all that. > > And if DHT nodes can't help each other out, there's probably no > benefit > of having a DHT at all anymore. Since you have a server big enough to > handle the demands of all the clients at once anyway just to handle > the > hole punching load, you might as well just run a centralized hash > table > on that big server in the first place. Let me repost here an e-mail that I posted to the P2PSIP mailing list a week ago. In a nutshell, I believe that DHTs _CAN_ be made to work when all peers are behind address-dependent filtering NATs, and the documents below describe how to do this in the specific case of Chord. ---- Message sent to P2PSIP on April 18th ---- I just want to second what Enrico and Bruce are saying: I believe we can live with NATs and Firewalls that have endpoint-dependent filtering. The basics of the idea for how to deal with these are described in three drafts draft-matthews-p2psip-bootstrap-mechanisms, and draft-matthews-p2psip-dsip-nat-traversal (which Bruce already mentioned) draft-matthews-p2psip-nats-and-overlays The first draft describes how a node that wishes to join a peer-to- peer overlay can establish a connection to ONE peer in the overlay. The second draft describes how the node can then leverage this connection to establish a partial mesh of connections to other peers, and then use this partial mesh to route messages through the overlay. The third draft attempts to explain this idea and compare it with other approaches to NAT Traversal for peer-to-peer networks. There is still more work to do flesh out all the details, but I believe the drafts adequately describe the core of the idea. There was a hot debate in the BEHAVE group on the filtering issue. However, the key fact is that there are many, many NATs today that already implement endpoint-dependent filtering for "security" reasons, and it was felt that many manufacturers would just ignore the recommendation if the document said "NATs MUST have endpoint-independent filtering". --- End of message --- I believe that most people active in P2PSIP today believe that we can live with address-dependent filtering on NATs. It is not ideal, but it is not the end of the world either. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 12:26:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1N1-00076R-S5; Mon, 23 Apr 2007 12:26:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg1N1-00074q-15 for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1N0-00073t-Mi for behave@ietf.org; Mon, 23 Apr 2007 12:26:30 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1L0-0005DR-OI for behave@ietf.org; Mon, 23 Apr 2007 12:24:28 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NGOB5Y000358; Mon, 23 Apr 2007 09:24:13 -0700 (PDT) Message-ID: <462CDD8C.7060501@isi.edu> Date: Mon, 23 Apr 2007 09:23:40 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Philip Matthews References: In-Reply-To: X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Behave WG Subject: [BEHAVE] Re: Are NATs routers? 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="===============0131474969==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0131474969== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig06DDEFE99C0FC2742D061AF1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig06DDEFE99C0FC2742D061AF1 > [Starting a new thread and trimming the CC list] >=20 > On 22-Apr-07, at 20:35 , Cullen Jennings wrote: >> >> On Apr 22, 2007, at 10:45 AM, Joe Touch wrote: >> >>> NATs are not routers. Using a code defined in RFC1812 for this purpos= e >>> is to inappropriately imply that a router is generating the code. >> >> agree - and point out this has been said many times by several >> different people in Behave. >=20 > I am guessing that this came up before I started attending BEHAVE meeti= ngs, > but I would be interesting in hearing more about why NATs are not route= rs, > or at least router-like. >=20 > As I see it, most NAT boxes have different subnets on their public and > private sides, > so they look rather similar to a router to me. NATs translate IP headers; that's something routers never do. =46rom the public side, a NAT is (or should be) equivalent to a network endpoint; it sources and sinks packets with its public IP address. What it does with those packets on the back end is its own business, and if it is never visible to the public Internet it's irrelevant. =46rom the private side, NATs don't look like either a router or a host; they should look like an invisible wire to the net a NAT connects to - or at least that's the goal of many NATs (to be invisible). Although packets are forwarded, there is no "network level" forwarding going on; packet translation is NOT routing. > Regarding the TTL, perhaps I am missing something, but wouldn't we want= > a NAT > to decrement the TTL field as the packet passes through? Perhaps this > is a new > requirement? NATs often want to appear "invisible" - decrementing the TTL would make them very visible, and thus defeats that goal. Joe --------------enig06DDEFE99C0FC2742D061AF1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLN2aE5f5cImnZrsRAgPGAKCUN1EqJCv8cPlQ0EdNtJAUZQi0EgCfU/1i SSaVgwsKGHaGGu57j/TNdf8= =ftW4 -----END PGP SIGNATURE----- --------------enig06DDEFE99C0FC2742D061AF1-- --===============0131474969== 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 --===============0131474969==-- From behave-bounces@ietf.org Mon Apr 23 12:26: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 1Hg1NA-0007Tx-I0; Mon, 23 Apr 2007 12:26:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg1N7-0007IX-TN for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1N7-0007Gc-0r; Mon, 23 Apr 2007 12:26:37 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1N6-0005vS-BI; Mon, 23 Apr 2007 12:26:36 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NGQ7w2001045; Mon, 23 Apr 2007 09:26:10 -0700 (PDT) Message-ID: <462CDE0D.7070605@isi.edu> Date: Mon, 23 Apr 2007 09:25:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ted Faber Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> <20070423161021.GI66656@hut.isi.edu> In-Reply-To: <20070423161021.GI66656@hut.isi.edu> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0763294186==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0763294186== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB532D2998087F02859ABB77B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB532D2998087F02859ABB77B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Sun, Apr 22, 2007 at 10:45:57AM -0700, Joe Touch wrote: >> NATs are not routers. Using a code defined in RFC1812 for this purpose= >> is to inappropriately imply that a router is generating the code. >=20 > I agree that a NAT that doesn't follow 1812 is not a compliant router. > However if this is only a semantic issue there are plenty of words out > there that could get around the semantic issue, e.g. "... in this case > a NAT may send an ICMP type 3 code 13 packet as a proxy for the router > inside its name space in order to simplify the translation ...". There need not be a router on either side of a NAT; in that case, what router is the NAT being a proxy for? Besides, if I configure either such router to never send such messages, the NAT has no right to generate them for me. > Is there a deeper issue here? Will the ICMP being issued with the NAT'= s > address cause functional confusion or malfunction in a host receiving > it? Is this a distinction that matters, or are words sufficient? I think the issue is "eating cake and having it too". The fundamental goal of most NATs is invisibility; you can't be invisible and scream when something goes wrong. Joe --------------enigB532D2998087F02859ABB77B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLN4OE5f5cImnZrsRAk0JAKDrm3/GRHgd0VRzx1qhWemSIGWzpACg9YbG 31nNvV3bThCuFUBXkBo5+TI= =5LSI -----END PGP SIGNATURE----- --------------enigB532D2998087F02859ABB77B-- --===============0763294186== 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 --===============0763294186==-- From behave-bounces@ietf.org Mon Apr 23 12:41: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 1Hg1bB-00042j-Rm; Mon, 23 Apr 2007 12:41:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg1bA-00040W-LT for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1bA-00040O-Bv for behave@ietf.org; Mon, 23 Apr 2007 12:41:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1b9-0001gp-2a for behave@ietf.org; Mon, 23 Apr 2007 12:41:08 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 23 Apr 2007 09:41:07 -0700 X-IronPort-AV: i="4.14,443,1170662400"; d="scan'208"; a="414620845:sNHT54608226" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3NGf6Id003111; Mon, 23 Apr 2007 09:41:06 -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 l3NGf4A9026855; Mon, 23 Apr 2007 16:41:04 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <379D268B-5183-40E6-81EB-8C24CF32D2E4@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 23 Apr 2007 09:40:33 -0700 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1144; t=1177346466; x=1178210466; c=relaxed/simple; s=sjdkim6002; 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=20Are=20NATs=20routers? |Sender:=20; bh=bP8R7bR1bTfeZ11YY951fV7UfZYIabpUYd1iTCmAgZE=; b=SSu1HjWS1p9q5XVk7joWNnEDE43MZrJSzJc97Pf/g3AYh20w9G3GjxXmWmAcDO+92gVnnXH0 pPBXHzqLJD6F9cWgmRthOQ44S8DOw5huMmNVZwfZeUJ2e54WTE9dhMvm; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Behave WG , Joe Touch Subject: [BEHAVE] Re: Are NATs routers? 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 A more specific question might be why NATs don't meet the requirements of a devices that does RFC 1812. On Apr 23, 2007, at 9:00 AM, Philip Matthews wrote: > [Starting a new thread and trimming the CC list] > > On 22-Apr-07, at 20:35 , Cullen Jennings wrote: >> >> On Apr 22, 2007, at 10:45 AM, Joe Touch wrote: >> >>> NATs are not routers. Using a code defined in RFC1812 for this >>> purpose >>> is to inappropriately imply that a router is generating the code. >> >> agree - and point out this has been said many times by several >> different people in Behave. > > I am guessing that this came up before I started attending BEHAVE > meetings, > but I would be interesting in hearing more about why NATs are not > routers, > or at least router-like. > > As I see it, most NAT boxes have different subnets on their public > and private sides, > so they look rather similar to a router to me. > > Regarding the TTL, perhaps I am missing something, but wouldn't we > want a NAT > to decrement the TTL field as the packet passes through? Perhaps > this is a new > requirement? > > - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 12:46:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1g4-00089K-LH; Mon, 23 Apr 2007 12:46:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg1g3-00089F-LH for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1g3-000897-BZ for behave@ietf.org; Mon, 23 Apr 2007 12:46:11 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1g3-0003co-0O for behave@ietf.org; Mon, 23 Apr 2007 12:46:11 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1462162nzd for ; Mon, 23 Apr 2007 09:46:08 -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=onCCIErJIfK9veofnHYlON/O8hwrhXe/ftLQ5WDdFlhF2q/PK0sGu2ohibFL9A2jwm+fhWA+PpuE21VvNnUUALqbqhLZzx9fsqCwCKyxODKVffqDl3yzazdYc3jM1f/GuT4cT7cWPzGcjk+t1q5myndp6y1OLYvBoPrAMQj5t9I= 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=A39eXT/SlgJhq+o2fGvPshhl4ch9o475ICkAyuSi0i3ZbLE7Ik8Q3ezTaqiRTU/GrZ+bTXiLLDv3ktqNt9eAGHA3U1LtWnMJ2LR+GFXPgJzhLaF3z9bLJxsG+XL/JMm0bcLByLEYsj59i1ZjMg5wFL5/yu+M2qhCrtEwX1UnTgA= Received: by 10.115.77.1 with SMTP id e1mr1826611wal.1177346768380; Mon, 23 Apr 2007 09:46:08 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Mon, 23 Apr 2007 09:46:08 -0700 (PDT) Message-ID: <894e079b0704230946t5c4832ecpf67b62209d8fdccd@mail.gmail.com> Date: Mon, 23 Apr 2007 12:46:08 -0400 From: "Medhavi Bhatia" To: "Philip Matthews" Subject: Re: [BEHAVE] Are NATs routers? In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 9e7ef7e9637b1590 X-Spam-Score: 0.5 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Behave WG , Joe Touch 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="===============1937666958==" Errors-To: behave-bounces@ietf.org --===============1937666958== Content-Type: multipart/alternative; boundary="----=_Part_137977_1741.1177346768172" ------=_Part_137977_1741.1177346768172 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think if NATs were like routers, then everything which looks like a NAT would start looking like a router as well. These would be things like ALGs, SBCs (which may or may not decrement the SIP Max Fwd) etc. NATs deal with routing issues like all these entities do at layer 3 and above I am sure, but can you call all these things a router? On the other hand it would be good if NATs were to follow rules which are a superset of those of routers. On 4/23/07, Philip Matthews wrote: > > [Starting a new thread and trimming the CC list] > > On 22-Apr-07, at 20:35 , Cullen Jennings wrote: > > > > On Apr 22, 2007, at 10:45 AM, Joe Touch wrote: > > > >> NATs are not routers. Using a code defined in RFC1812 for this > >> purpose > >> is to inappropriately imply that a router is generating the code. > > > > agree - and point out this has been said many times by several > > different people in Behave. > > I am guessing that this came up before I started attending BEHAVE > meetings, > but I would be interesting in hearing more about why NATs are not > routers, > or at least router-like. > > As I see it, most NAT boxes have different subnets on their public > and private sides, > so they look rather similar to a router to me. > > Regarding the TTL, perhaps I am missing something, but wouldn't we > want a NAT > to decrement the TTL field as the packet passes through? Perhaps > this is a new > requirement? > > - Philip > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_137977_1741.1177346768172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think if NATs were like routers, then everything which looks like a NAT would start looking like a router as well. These would be things like ALGs, SBCs (which may or may not decrement the SIP Max Fwd) etc. NATs deal with routing issues like all these entities do at layer 3 and above I am sure, but can you call all these things a router?

On the other hand it would be good if NATs were to follow rules which are a superset of those of routers.

On 4/23/07, Philip Matthews < philip_matthews@magma.ca> wrote:
[Starting a new thread and trimming the CC list]

On 22-Apr-07, at 20:35 , Cullen Jennings wrote:
>
> On Apr 22, 2007, at 10:45 AM, Joe Touch wrote:
>
>> NATs are not routers. Using a code defined in RFC1812 for this
>> purpose
>> is to inappropriately imply that a router is generating the code.
>
> agree - and point out this has been said many times by several
> different people in Behave.

I am guessing that this came up before I started attending BEHAVE
meetings,
but I would be interesting in hearing more about why NATs are not
routers,
or at least router-like.

As I see it, most NAT boxes have different subnets on their public
and private sides,
so they look rather similar to a router to me.

Regarding the TTL, perhaps I am missing something, but wouldn't we
want a NAT
to decrement the TTL field as the packet passes through?  Perhaps
this is a new
requirement?

- Philip




_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave

------=_Part_137977_1741.1177346768172-- --===============1937666958== 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 --===============1937666958==-- From behave-bounces@ietf.org Mon Apr 23 12:47: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 1Hg1gq-00006x-Ok; Mon, 23 Apr 2007 12:47:00 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg1go-0008Up-QV for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1go-0008Ug-Gq for behave@ietf.org; Mon, 23 Apr 2007 12:46:58 -0400 Received: from ns2.dixons.org ([217.147.86.2] helo=post.planetlink.ltd.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1gn-0003y5-3V for behave@ietf.org; Mon, 23 Apr 2007 12:46:58 -0400 Received: from 82-32-46-174.cable.ubr06.azte.blueyonder.co.uk ([82.32.46.174] helo=westbury.dixons.org) by post.planetlink.ltd.uk with esmtp (Exim 4.50) id 1Hg1gk-0004CW-R6; Mon, 23 Apr 2007 17:46:54 +0100 Received: from jdd (helo=localhost) by westbury.dixons.org with local-esmtp (Exim 4.50) id 1Hg1gI-0000V9-2p; Mon, 23 Apr 2007 17:46:26 +0100 Date: Mon, 23 Apr 2007 17:46:26 +0100 (BST) From: Jim Dixon To: Joe Touch Subject: Re: [BEHAVE] Re: Are NATs routers? In-Reply-To: <462CDD8C.7060501@isi.edu> Message-ID: References: <462CDD8C.7060501@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Mon, 23 Apr 2007, Joe Touch wrote: > NATs translate IP headers; that's something routers never do. Have you told Cisco? I just googled on 'cisco nat' and got 1,630,000 hits. The first sets out the use of NAT in IOS. The second begins with 'network Address Translation allows a single device, such as a router, to act as an agent between the Internet (or "public network") and a local (or "private") network.' -- Jim Dixon jddixon@gmail.com cellphone 415 / 570 3608 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 12:47:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1hM-0000T3-9W; Mon, 23 Apr 2007 12:47:32 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg1hK-0000R7-QW for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1hK-0000Qx-Gz for behave@ietf.org; Mon, 23 Apr 2007 12:47:30 -0400 Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1hJ-0004cO-8N for behave@ietf.org; Mon, 23 Apr 2007 12:47:30 -0400 Received: from mail3.magma.ca (mail3.internal.magma.ca [10.0.10.13]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3NGlQK7009107; Mon, 23 Apr 2007 12:47:26 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail3.magma.ca (Magma's Mail Server) with ESMTP id l3NGlO9f030599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 12:47:26 -0400 In-Reply-To: <462CDD8C.7060501@isi.edu> References: <462CDD8C.7060501@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 23 Apr 2007 12:47:21 -0400 To: Joe Touch X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Behave WG Subject: [BEHAVE] Re: Are NATs routers? 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 23-Apr-07, at 12:23 , Joe Touch wrote: >> Regarding the TTL, perhaps I am missing something, >> but wouldn't we want a NAT >> to decrement the TTL field as the packet passes through? >> Perhaps this is a new requirement? > > NATs often want to appear "invisible" - decrementing the TTL would > make > them very visible, and thus defeats that goal. I don't think NATs are really invisible. There is a lot of work going on to make applications work through NATs, and a lot of work going on to discover NATs and their properties. So I think this goal is now obsolete. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 12:54: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 1Hg1oB-000742-4X; Mon, 23 Apr 2007 12:54:35 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg1oA-00071y-29 for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:54:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1o9-0006zo-K1 for behave@ietf.org; Mon, 23 Apr 2007 12:54:33 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1o7-0007My-58 for behave@ietf.org; Mon, 23 Apr 2007 12:54:33 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NGsJMK007989; Mon, 23 Apr 2007 09:54:20 -0700 (PDT) Message-ID: <462CE4AB.30205@isi.edu> Date: Mon, 23 Apr 2007 09:54:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jim Dixon Subject: Re: [BEHAVE] Re: Are NATs routers? References: <462CDD8C.7060501@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Content-Type: multipart/mixed; boundary="===============1684580534==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1684580534== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig255ED4FE0DAA2A93D118EF58" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig255ED4FE0DAA2A93D118EF58 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jim Dixon wrote: > On Mon, 23 Apr 2007, Joe Touch wrote: >=20 >> NATs translate IP headers; that's something routers never do. >=20 > Have you told Cisco? I just googled on 'cisco nat' and got 1,630,000 > hits. The first sets out the use of NAT in IOS.=20 We all know that there are boxes called routers that have - packaged inside - the functions of a NAT. These boxes also terminate connections, and to that end are hosts. Some sell such boxes that even connect to and network other technologies, like SNA. > The second begins > with 'network Address Translation allows a single device, such as a > router, to act as an agent between the Internet (or "public network") > and a local (or "private") network.' That's all focused on a single *physical* device. That's not relevant here. We're talking about the NAT functions, not the physical box. The router part of a box never translates headers; to do so is to violate RFC1812, and **by definition** renders whatever component does that "not a router". You can couple that box to an 1812-compliant router and sell it as a single box, but that is irrelevant. Joe --------------enig255ED4FE0DAA2A93D118EF58 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLOSrE5f5cImnZrsRAmT3AKCMfHcIm9DUFfOTPWovfeJu3RKOrACeKy7T XPtULZ7vRXuB69D8n41BdX4= =fm7T -----END PGP SIGNATURE----- --------------enig255ED4FE0DAA2A93D118EF58-- --===============1684580534== 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 --===============1684580534==-- From behave-bounces@ietf.org Mon Apr 23 12:56:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1pm-0008Fo-P2; Mon, 23 Apr 2007 12:56:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg1pb-0007nZ-Nl for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1pb-0007ms-4o for behave@ietf.org; Mon, 23 Apr 2007 12:56:03 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1pX-000856-9E for behave@ietf.org; Mon, 23 Apr 2007 12:56:03 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NGtX23008547; Mon, 23 Apr 2007 09:55:36 -0700 (PDT) Message-ID: <462CE4F6.6000405@isi.edu> Date: Mon, 23 Apr 2007 09:55:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Philip Matthews References: <462CDD8C.7060501@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Behave WG Subject: [BEHAVE] Re: Are NATs routers? 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="===============1366490233==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1366490233== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig33D5935A2DADF8A4267F8240" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig33D5935A2DADF8A4267F8240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Philip Matthews wrote: >=20 > On 23-Apr-07, at 12:23 , Joe Touch wrote: >>> Regarding the TTL, perhaps I am missing something, >>> but wouldn't we want a NAT >>> to decrement the TTL field as the packet passes through? >>> Perhaps this is a new requirement? >> >> NATs often want to appear "invisible" - decrementing the TTL would mak= e >> them very visible, and thus defeats that goal. >=20 > I don't think NATs are really invisible. > There is a lot of work going on to make applications work > through NATs, and a lot of work going on to discover > NATs and their properties. >=20 > So I think this goal is now obsolete. There is *some* work in trying to make the functions of these boxes visible and controllable, but that doesn't cover the entirety of what makes a NAT a NAT. In general, NATs do their best to be as invisible as possible, and visible only when that fails. Joe --------------enig33D5935A2DADF8A4267F8240 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLOT2E5f5cImnZrsRAjQzAJ9QIrz551AvXMUDy4e1YLEJ5mdAQACgq+aR qivkxPvMUej4yjDrZMFR8C4= =OcPK -----END PGP SIGNATURE----- --------------enig33D5935A2DADF8A4267F8240-- --===============1366490233== 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 --===============1366490233==-- From behave-bounces@ietf.org Mon Apr 23 13:01:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1uh-0005DJ-EI; Mon, 23 Apr 2007 13:01:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hfkot-0003td-2E for behave-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 18:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfkos-0003tN-OM; Sun, 22 Apr 2007 18:46:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfkos-0007M8-B4; Sun, 22 Apr 2007 18:46:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2007 15:46:09 -0700 X-IronPort-AV: i="4.14,439,1170662400"; d="scan'208"; a="414354533:sNHT50946788" 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 l3MMk9At004149; Sun, 22 Apr 2007 15:46:09 -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 l3MMk9ZT023985; Sun, 22 Apr 2007 22:46:09 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 15:46:09 -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: [tcpm] icmp type 3, code 13 Date: Sun, 22 Apr 2007 15:46:07 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58033AD7BD@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <462BCF84.6040706@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Thread-Index: AceFIwZrSlG9WE48Smed/fkcaYY6uQABRfhg From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" , "Pyda Srisuresh" X-OriginalArrivalTime: 22 Apr 2007 22:46:09.0214 (UTC) FILETIME=[04FFB5E0:01C78530] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2921; t=1177281969; x=1178145969; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20[tcpm]=20icmp=20type=203, =20code=2 013 |Sender:=20; bh=2innWXmD2IX7rlAUasc0ADjxuVRIvDthl40zwYlxrdw=; b=BKKRfsHuyO1cp2ZkW8z5bTEbLwCjMHHX6N9OYSsRNpdAwLDHXwkB/PHlcXuOG8s3Mc2a1Vtd yWWvkzW0mDX0MFHJGisa6KtxHGgnbkJhRt3WHL+3Z1VX2uGmsD97c40V; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Mon, 23 Apr 2007 13:01:18 -0400 Cc: tcpm@ietf.org, behave@ietf.org, "Faisal Siyavudeen \(fsiyavud\)" , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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 Firstly, why is this being disussed in tcpm? This doesn't apply to TCP directly. [ even in-directly it might apply to all other transport protocols who can/may want to act on these errors] Maybe tsvwg is more appropriate?=20 As far as the current discussion goes, there is a thin line of distinction between hosts and routers, today. Today's routers do all sort of things which were only done by end-hosts at one point of time. So any discussion which is based on the semantics of a router/switch/host is IMO, useless, since things have evolved.=20 Also, actually, when you say "NAT's are not routers", there is a lot of ambiguity there : Typical case where NAT is configured in a router, which means that this device, applies NAT rule and route's the packets. So are you saying :- - generate a ICMP error code if the error is a result of a "routing operation" and NOT as a result of "NAT operation"? I really don't see a value in seperating these and it boils down to pure semantic argument, IMO, without considering the characteristics of the deployed Internet today.=20 -Anantha=20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Sunday, April 22, 2007 2:12 PM > To: Pyda Srisuresh > Cc: tcpm@ietf.org; behave@ietf.org; Mahesh Govind (mgovind);=20 > Dan Wing (dwing); Faisal Siyavudeen (fsiyavud) > Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 >=20 >=20 >=20 > Pyda Srisuresh wrote: > > Below is what RFC 1812 has to say about what constitutes a router. > >=20 > > This memo defines and discusses requirements for devices=20 > that perform > > the network layer forwarding function of the Internet=20 > protocol suite. > > The Internet community usually refers to such devices as=20 > IP routers or > > simply routers. >=20 > The rest of that document is what defines what is an Internet router. > Being a device that does network layer forwarding and=20 > violates any of the rest of that doc means that device is not=20 > an Internet router. >=20 > > NATs forward IP packets from one network to another. That=20 > makes NAT a router. >=20 > NATs don't follow the requirement of: > - decrement the TTL > - do not modify the source or destination IP address > (except as per source-routing options) >=20 > ... > > If you insist NAT is not a router, I am not going to argue=20 > or get into=20 > > a debate with you on this. I will simply disagree. So do the vast=20 > > majority of people taht use NATs to connect to public networks. >=20 > They can and have disagreed before, but this isn't up for a=20 > popular vote. It's utterly useless to talk about using any=20 > sort of IETF standard > - including ICMP type 3 code 13 - and expect the rest of the=20 > Internet to follow that standard when NATs violate the=20 > standard of what it means to be a router. >=20 > Joe >=20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 13:01:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1ut-0005Kf-Hg; Mon, 23 Apr 2007 13:01:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg19R-0003xl-EA for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:12:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg19R-0003xW-4G; Mon, 23 Apr 2007 12:12:29 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg19P-0001bh-MX; Mon, 23 Apr 2007 12:12:29 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l3NGALeI010432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Apr 2007 09:10:21 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l3NGALqU093438; Mon, 23 Apr 2007 09:10:21 -0700 (PDT) (envelope-from faber) Date: Mon, 23 Apr 2007 09:10:21 -0700 From: Ted Faber To: Joe Touch Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Message-ID: <20070423161021.GI66656@hut.isi.edu> References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> Mime-Version: 1.0 In-Reply-To: <462B9F55.1090008@isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Mon, 23 Apr 2007 13:01:29 -0400 Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0298152896==" Errors-To: behave-bounces@ietf.org --===============0298152896== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lqaZmxkhekPBfBzr" Content-Disposition: inline --lqaZmxkhekPBfBzr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 22, 2007 at 10:45:57AM -0700, Joe Touch wrote: > NATs are not routers. Using a code defined in RFC1812 for this purpose > is to inappropriately imply that a router is generating the code. I agree that a NAT that doesn't follow 1812 is not a compliant router. However if this is only a semantic issue there are plenty of words out there that could get around the semantic issue, e.g. "... in this case a NAT may send an ICMP type 3 code 13 packet as a proxy for the router inside its name space in order to simplify the translation ...". Is there a deeper issue here? Will the ICMP being issued with the NAT's address cause functional confusion or malfunction in a host receiving it? Is this a distinction that matters, or are words sufficient? --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --lqaZmxkhekPBfBzr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLNptaUz3f+Zf+XsRAsZ+AJ4+MV4VhHt2xbZPZSipeb6lu1/0QACfR6LC aE5p0sQbRuEkXGINFrHh5Sc= =h7Pa -----END PGP SIGNATURE----- --lqaZmxkhekPBfBzr-- --===============0298152896== 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 --===============0298152896==-- From behave-bounces@ietf.org Mon Apr 23 13:13: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 1Hg26e-0000aX-SJ; Mon, 23 Apr 2007 13:13:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg26d-0000aF-Kx for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 13:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg26d-0000a6-BR for behave@ietf.org; Mon, 23 Apr 2007 13:13:39 -0400 Received: from ns2.dixons.org ([217.147.86.2] helo=post.planetlink.ltd.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg26c-0004xf-2X for behave@ietf.org; Mon, 23 Apr 2007 13:13:39 -0400 Received: from 82-32-46-174.cable.ubr06.azte.blueyonder.co.uk ([82.32.46.174] helo=westbury.dixons.org) by post.planetlink.ltd.uk with esmtp (Exim 4.50) id 1Hg26a-0004MM-52; Mon, 23 Apr 2007 18:13:36 +0100 Received: from jdd (helo=localhost) by westbury.dixons.org with local-esmtp (Exim 4.50) id 1Hg267-0000XC-Me; Mon, 23 Apr 2007 18:13:07 +0100 Date: Mon, 23 Apr 2007 18:13:07 +0100 (BST) From: Jim Dixon To: Joe Touch Subject: Re: [BEHAVE] Re: Are NATs routers? In-Reply-To: <462CE4AB.30205@isi.edu> Message-ID: References: <462CDD8C.7060501@isi.edu> <462CE4AB.30205@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Mon, 23 Apr 2007, Joe Touch wrote: > >> NATs translate IP headers; that's something routers never do. This is plain English: routers never translate IP headers. > > Have you told Cisco? I just googled on 'cisco nat' and got 1,630,000 > > hits. The first sets out the use of NAT in IOS. > > We all know that there are boxes called routers that have - packaged > inside - the functions of a NAT. These boxes also terminate connections, > and to that end are hosts. This is obfuscation. I do believe that every router that I have ever used has NAT functionality. That is, they are all capable of translating IP headers. And they are all routers. > The router part of a box never translates headers; to do so is to > violate RFC1812, and **by definition** renders whatever component does > that "not a router". You can couple that box to an 1812-compliant router > and sell it as a single box, but that is irrelevant. Sorry, you can't mistreat the English language in this way ;-) When I buy a router, I _expect_ it to have NAT functionality. I am not buying a 'box'. I am buying a router and in so doing I am buying its NAT capabilities. Lewis Carroll, 'Through the Looking Glass', Chapter VI, is relevant. -- Jim Dixon jddixon@gmail.com cellphone 415 / 570 3608 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 13:31: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 1Hg2Nj-0004Iy-GE; Mon, 23 Apr 2007 13:31:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg2Ni-0004Hg-Iw for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 13:31:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Ni-0004HK-8r for behave@ietf.org; Mon, 23 Apr 2007 13:31:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2Ng-00010B-Te for behave@ietf.org; Mon, 23 Apr 2007 13:31:18 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NHUuBJ017683; Mon, 23 Apr 2007 10:30:59 -0700 (PDT) Message-ID: <462CED41.8050700@isi.edu> Date: Mon, 23 Apr 2007 10:30:41 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jim Dixon Subject: Re: [BEHAVE] Re: Are NATs routers? References: <462CDD8C.7060501@isi.edu> <462CE4AB.30205@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , Content-Type: multipart/mixed; boundary="===============1798069950==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1798069950== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8A2B4005D57BFB1041D169B2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8A2B4005D57BFB1041D169B2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jim Dixon wrote: =2E.. > When I buy a router, I _expect_ it to have NAT functionality.=20 You do; others expect ATM interfaces, ethernet interfaces, etc. That's your issue, but doesn't define what a router is; RFC1812 does that. > I am > not buying a 'box'. I am buying a router and in so doing I am buying > its NAT capabilities. You also expect Ethernet functionality, but that has nothing to do with RFC1812 functions either. Joe --------------enig8A2B4005D57BFB1041D169B2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLO1BE5f5cImnZrsRAiLrAJ9oZDlWBoR1FRI2Aq3va9yYLj7eRwCfWuQx gG0U+OsKSdbWwhE5m7Lw4ck= =R/u9 -----END PGP SIGNATURE----- --------------enig8A2B4005D57BFB1041D169B2-- --===============1798069950== 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 --===============1798069950==-- From behave-bounces@ietf.org Mon Apr 23 13:56: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 1Hg2ls-0008Jw-R3; Mon, 23 Apr 2007 13:56:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg2ls-0008Jo-1Z for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 13:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2lr-0008Jg-OG for behave@ietf.org; Mon, 23 Apr 2007 13:56:15 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2lq-0006wx-B6 for behave@ietf.org; Mon, 23 Apr 2007 13:56:15 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NHtvHK023829; Mon, 23 Apr 2007 10:56:00 -0700 (PDT) Message-ID: <462CF31C.5040804@isi.edu> Date: Mon, 23 Apr 2007 10:55:40 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Dave Hudson Subject: Re: [BEHAVE] Re: Are NATs routers? References: In-Reply-To: X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Content-Type: multipart/mixed; boundary="===============1243307255==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1243307255== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB034B4FFE841AAFC92A1B0BD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB034B4FFE841AAFC92A1B0BD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dave Hudson wrote: > * -----Original Message----- > * From: Joe Touch [mailto:touch@ISI.EDU]=20 > * Sent: 23 April 2007 18:31 > * To: Jim Dixon > * Cc: Behave WG > * Subject: Re: [BEHAVE] Re: Are NATs routers? > *=20 > *=20 > *=20 > * Jim Dixon wrote: > * ... > * > When I buy a router, I _expect_ it to have NAT functionality.=20 > *=20 > * You do; others expect ATM interfaces, ethernet interfaces,=20 > * etc. That's your issue, but doesn't define what a router is;=20 > * RFC1812 does that. >=20 > As regards whether NATs are routers I suspect that whether anyone likes= > it or not most end users certainly believe that their home broadband > router is a router and no amount of trying to change that here will mak= e > much difference any more. All of these products are sold as "routers" > and are referred to as "routers" by every OEM (they're also certified a= s > routers for Windows Vista for example: > http://winqual.microsoft.com/HCL/ProductList.aspx?m=3Dv&g=3Dd&cid=3D712= &f=3D86b) That's fine, but here in the IETF we mean RFC1812 when we say routers, and marketing labels and public miseducation are not relevant. Can we move on? Joe --------------enigB034B4FFE841AAFC92A1B0BD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLPMdE5f5cImnZrsRAlLHAKCVrZRtr8scNBisT9mAmckFkJx7OQCglPB/ SO+YXFwxeUxpFq/Qr9s4dAc= =hSnl -----END PGP SIGNATURE----- --------------enigB034B4FFE841AAFC92A1B0BD-- --===============1243307255== 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 --===============1243307255==-- From behave-bounces@ietf.org Mon Apr 23 14:03:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2sy-0006eS-TV; Mon, 23 Apr 2007 14:03:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg2sy-0006eL-5i for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2sx-0006eD-SR for behave@ietf.org; Mon, 23 Apr 2007 14:03:35 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2sw-0008MJ-Gq for behave@ietf.org; Mon, 23 Apr 2007 14:03:35 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3NI3Y4B001886 for ; Mon, 23 Apr 2007 11:03:34 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id E9E7C10042 for ; Mon, 23 Apr 2007 11:03:33 -0700 (PDT) X-AuditID: 11807124-a157ebb0000007e5-b8-462cf4f522c5 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay6.apple.com (Apple SCV relay) with ESMTP id D483F1006B for ; Mon, 23 Apr 2007 11:03:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <38464B16719C77439C06051F392AB9E6062EB2EB@CAVS1.sanmateo.corp.akamai.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A0B2AB4-2C90-4B06-917B-94F04FA89B00@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Date: Mon, 23 Apr 2007 11:03:31 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Apr 22, 2007, at 19:58, Cullen Jennings wrote: > > [...] The bulk of residential NATs todays include "SPI" which > usually means endpoint dependent filtering. I will note that apple > is an exception to this - but I don't envy the role of the apple > engineering folks that have to explain to the marketing folks that > CNET and other reviews are wrong and it is good that the Airports > don't have SPI. AirPort base stations have always implemented SPI filtering. State created by outbound UDP flow initiations has always been subject to endpoint-independent filtering, and this has never been a source of customer dissatisfaction. Nobody from product marketing has ever brought up the subject with AirPort engineering. Future products may implement endpoint-dependent SPI filtering for outbound UDP flows. It wouldn't be difficult to do if market demand for BEHAVE-compliant NAT gateways emerges, but I can't say anything about what Apple plans to do. Note: UDP mappings created by NAT-PMP are always unfiltered-- and this is required by the NAT-PMP specification. The proposal I am currently drafting for extending the concept of PMP for use with IPv6 firewalls will certainly contain a similar requirement. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 14:10: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 1Hg2zl-0004al-Am; Mon, 23 Apr 2007 14:10:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg2zk-0004af-GM for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2zk-0004aX-6p for behave@ietf.org; Mon, 23 Apr 2007 14:10:36 -0400 Received: from ns2.dixons.org ([217.147.86.2] helo=post.planetlink.ltd.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2zi-0001I5-U1 for behave@ietf.org; Mon, 23 Apr 2007 14:10:36 -0400 Received: from 82-32-46-174.cable.ubr06.azte.blueyonder.co.uk ([82.32.46.174] helo=westbury.dixons.org) by post.planetlink.ltd.uk with esmtp (Exim 4.50) id 1Hg2zg-0004aP-Cx; Mon, 23 Apr 2007 19:10:32 +0100 Received: from jdd (helo=localhost) by westbury.dixons.org with local-esmtp (Exim 4.50) id 1Hg2zE-0000aK-HI; Mon, 23 Apr 2007 19:10:04 +0100 Date: Mon, 23 Apr 2007 19:10:04 +0100 (BST) From: Jim Dixon To: Joe Touch Subject: Re: [BEHAVE] Re: Are NATs routers? In-Reply-To: <462CED41.8050700@isi.edu> Message-ID: References: <462CDD8C.7060501@isi.edu> <462CE4AB.30205@isi.edu> <462CED41.8050700@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Mon, 23 Apr 2007, Joe Touch wrote: > Jim Dixon wrote: > ... > > When I buy a router, I _expect_ it to have NAT functionality. > > You do; others expect ATM interfaces, ethernet interfaces, etc. That's > your issue, but doesn't define what a router is; RFC1812 does that. Sorry, but this is absurd. Common use defines what any word means. We all know who the large router manufacturers are. Those manufacturers sell routers. Those routers have NAT functionality. > > I am > > not buying a 'box'. I am buying a router and in so doing I am buying > > its NAT capabilities. > > You also expect Ethernet functionality, but that has nothing to do with > RFC1812 functions either. I have actually bought routers without an Ethernet interface. But I don't recall ever buying one that wasn't capable of Network Address Translation. Your original assertion was straightforward: > NATs translate IP headers; that's something routers never do. This is simply wrong. It's not true. Routers route, and routers sometimes translate IP headers. They don't suddenly become "boxes" when they do so. -- Jim Dixon jddixon@gmail.com cellphone 415 / 570 3608 --------------------------------------------------------------------------- 'When I use a word,' Humpty Dumpty said, in a rather scornful tone, 'it means just what I choose it to mean -- neither more nor less.' Lewis Carroll, _Through the Looking Glass_ --------------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 14:17: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 1Hg36p-0000xT-B2; Mon, 23 Apr 2007 14:17:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg36n-0000xH-LL for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:17:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg36n-0000x2-8V for behave@ietf.org; Mon, 23 Apr 2007 14:17:53 -0400 Received: from web33309.mail.mud.yahoo.com ([68.142.206.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg36m-00034m-JV for behave@ietf.org; Mon, 23 Apr 2007 14:17:53 -0400 Received: (qmail 2722 invoked by uid 60001); 23 Apr 2007 18:17:51 -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=Xp9tPQqfd3W8Qptv010Z0hToJgig+bzMBbHe+1VsmXy1PA7Yg55p7LRDaCP+xA3NgdYhJAf6ORv+j66E23psf4zCQN/EfTOERXqTS+IeVRrUJzr/cNKy/Yt3nMk7qOS+AKLCGSOVKoRWxe6UJDzz98jzQQkNkGjJIQpXU3XaRos=; X-YMail-OSG: 4GBT_2MVM1mYUW4QFcr_r3itaQChpp2PKwe2YHRWeeSAFP15hFMV92bCvBGZitQ0UR7GhtC7h.K_Kcq9H7qK9wkiDuZPoPMu0mqJc4HbrSAt5UY- Received: from [209.172.74.45] by web33309.mail.mud.yahoo.com via HTTP; Mon, 23 Apr 2007 11:17:51 PDT Date: Mon, 23 Apr 2007 11:17:51 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 To: Joe Touch , "Anantha Ramaiah \(ananth\)" In-Reply-To: <462CBF2B.2040100@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <700710.98945.qm@web33309.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: behave@ietf.org, tsvwg@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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 --- Joe Touch wrote: > > > Anantha Ramaiah (ananth) wrote: > > Firstly, why is this being disussed in tcpm? This doesn't apply to TCP > > directly. [ even in-directly it might apply to all other transport > > protocols who can/may want to act on these errors] Maybe tsvwg is more > > appropriate? > > That's possible; someone in Behave might start by posting a summary of > the question there as well. > [suresh] Agree with Ananth's comment. This is likely more applicable to tsvwg than tcpm. I am replacing tcpm with tsvwg. > > As far as the current discussion goes, there is a thin line of > > distinction between hosts and routers, today. > > There may be many devices that do both functions, but to the extent they > do they must then obey both the host and router requirements. > > > Today's routers do all > > sort of things which were only done by end-hosts at one point of time. > > Such as? Other than acting like end hosts for connections that terminate > at routers, which they have always done, and always required > RFC1122-level support... > > > So any discussion which is based on the semantics of a > > router/switch/host is IMO, useless, since things have evolved. > > Until the requirements in the IETF are updated to reflect this opinion, > it is irrelevant. > [suresh] I agree with Ananth. Things have evolved considerably since the introduction of NATs, web and peer networking. Any discussion based on semantics and not on present day deployment is not going to be useful, IMHO. > > Also, actually, when you say "NAT's are not routers", there is a lot of > > ambiguity there : > > > > Typical case where NAT is configured in a router, which means that this > > device, applies NAT rule and route's the packets. > [suresh] Exactly. That is how NATs route. NATs translate IP addresses before forwarding. > Then the part that routes must obey RFC1812 rules. If the part that > routes can respond in lieu of the part that NATs, then that's fine. But > when the part that NATs acts, it can't act like the router. > [suresh] So, if the part that does "NAT function" tells the part that does "route fucntion" that the router cannot forward the packet (Cause: Resource constraint or admin restrictions), what error code shoud the part that does "route function" use when sending ICMP error message back to the sender? Are you saying this cannot be any of the error codes specified in RFC 1812? > > So are you saying :- > ... > > - generate a ICMP error code if the error is a result of a "routing > > operation" and NOT as a result of "NAT operation"? > > Yes. > > > I really don't see a > > value in seperating these and it boils down to pure semantic argument, > > IMO, without considering the characteristics of the deployed Internet > > today. > [suresh] Right. Full agree with Ananth. Coulndt have said it better. > First, there are plenty of devices that do not combine both functions, > and that's where we're talking about. > > However, in the case of the combined device, it still makes sense to > determine WHY an error code is being generated. If because of a routing > issue, then RFC1812 works; if because of a NAT issue, then RFC1812 is > NOT the guiding document. > [suresh] Joe - This is really a semantics argument. We have had discussions in the BEHAVE WG on which error code to use and settled on error code 13 as the most appropriate. This requirement has been in the draft for 6 months now. I will go with whatever the WG decides in the end. DO you think it is really necessary to invent a new ICMP error code for the error cause we are talking about? I think not. My 2c. regards, suresh > Joe > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@ISI.EDU] > >> Sent: Sunday, April 22, 2007 2:12 PM > >> To: Pyda Srisuresh > >> Cc: tcpm@ietf.org; behave@ietf.org; Mahesh Govind (mgovind); > >> Dan Wing (dwing); Faisal Siyavudeen (fsiyavud) > >> Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 > >> > >> > >> > >> Pyda Srisuresh wrote: > >>> Below is what RFC 1812 has to say about what constitutes a router. > >>> > >>> This memo defines and discusses requirements for devices > >> that perform > >>> the network layer forwarding function of the Internet > >> protocol suite. > >>> The Internet community usually refers to such devices as > >> IP routers or > >>> simply routers. > >> The rest of that document is what defines what is an Internet router. > >> Being a device that does network layer forwarding and > >> violates any of the rest of that doc means that device is not > >> an Internet router. > >> > >>> NATs forward IP packets from one network to another. That > >> makes NAT a router. > >> > >> NATs don't follow the requirement of: > >> - decrement the TTL > >> - do not modify the source or destination IP address > >> (except as per source-routing options) > >> > >> ... > >>> If you insist NAT is not a router, I am not going to argue > >> or get into > >>> a debate with you on this. I will simply disagree. So do the vast > >>> majority of people taht use NATs to connect to public networks. > >> They can and have disagreed before, but this isn't up for a > >> popular vote. It's utterly useless to talk about using any > >> sort of IETF standard > >> - including ICMP type 3 code 13 - and expect the rest of the > >> Internet to follow that standard when NATs violate the > >> standard of what it means to be a router. > >> > >> Joe > >> > >> > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 23 14:18: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 1Hg37l-0001SY-SV; Mon, 23 Apr 2007 14:18:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg37k-0001SQ-MB for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:18:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg37k-0001SI-Cj; Mon, 23 Apr 2007 14:18:52 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg37i-0003LJ-VS; Mon, 23 Apr 2007 14:18:52 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l3NIIMYL016150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Apr 2007 11:18:22 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l3NIIMNX016519; Mon, 23 Apr 2007 11:18:22 -0700 (PDT) (envelope-from faber) Date: Mon, 23 Apr 2007 11:18:22 -0700 From: Ted Faber To: Joe Touch Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Message-ID: <20070423181822.GB1301@hut.isi.edu> References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> <20070423161021.GI66656@hut.isi.edu> <462CDE0D.7070605@isi.edu> Mime-Version: 1.0 In-Reply-To: <462CDE0D.7070605@isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============1680790528==" Errors-To: behave-bounces@ietf.org --===============1680790528== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 23, 2007 at 09:25:49AM -0700, Joe Touch wrote: >=20 >=20 > Ted Faber wrote: > > On Sun, Apr 22, 2007 at 10:45:57AM -0700, Joe Touch wrote: > >> NATs are not routers. Using a code defined in RFC1812 for this purpose > >> is to inappropriately imply that a router is generating the code. > >=20 > > I agree that a NAT that doesn't follow 1812 is not a compliant router. > > However if this is only a semantic issue there are plenty of words out > > there that could get around the semantic issue, e.g. "... in this case > > a NAT may send an ICMP type 3 code 13 packet as a proxy for the router > > inside its name space in order to simplify the translation ...". >=20 > There need not be a router on either side of a NAT; in that case, what > router is the NAT being a proxy for? Oh I bet I can find a router on a non-trivial Internet path. :-) I don't want to spend too much time defending a hypothetical rewording. I'd rather talk about the issue that you get to below. > > Is there a deeper issue here? Will the ICMP being issued with the NAT's > > address cause functional confusion or malfunction in a host receiving > > it? Is this a distinction that matters, or are words sufficient? >=20 > I think the issue is "eating cake and having it too". >=20 > The fundamental goal of most NATs is invisibility; you can't be > invisible and scream when something goes wrong. This is a fair point. If a NAT is otherwise acting transparently, it is certainly alarming that it will occasionally pop up with an ICMP message. I can imagine the pain of trying to debug such an error message using standard tools like traceroute or even ping. ("I got an ICMP from something that doesn't respond to a ping!?") I think that the nail you're hitting is that partial visibility is clearly confusing to applications and administrators and needs to be avoided. I'd agree that a device that emits an ICMP but is otherwise invisible to endpoints is difficult enough to deal with in the real world that the behavior needs to be discouraged. If you agree with that, we agree. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLPhuaUz3f+Zf+XsRAkDOAJ9AQje5HOG6lomO7JPOwGKIc21JzQCfcgzD nPtSUH+ciHjoiweiIqQDDeU= =3+72 -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- --===============1680790528== 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 --===============1680790528==-- From behave-bounces@ietf.org Mon Apr 23 14:39: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 1Hg3RU-0001Bj-UB; Mon, 23 Apr 2007 14:39:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg3RT-0001BE-3a for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3RS-0001Av-GN; Mon, 23 Apr 2007 14:39:14 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3RS-0001Hv-1p; Mon, 23 Apr 2007 14:39:14 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NIcTIh004285; Mon, 23 Apr 2007 11:38:40 -0700 (PDT) Message-ID: <462CFD12.6030004@isi.edu> Date: Mon, 23 Apr 2007 11:38:10 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <700710.98945.qm@web33309.mail.mud.yahoo.com> In-Reply-To: <700710.98945.qm@web33309.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: behave@ietf.org, tsvwg@ietf.org, "Anantha Ramaiah \(ananth\)" , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0584020478==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0584020478== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2F5E4231C2623E63F6ABEEED" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F5E4231C2623E63F6ABEEED Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pyda Srisuresh wrote: > --- Joe Touch wrote: =2E.. >>> So any discussion which is based on the semantics of a >>> router/switch/host is IMO, useless, since things have evolved. >> Until the requirements in the IETF are updated to reflect this opinion= , >> it is irrelevant. >> > [suresh] I agree with Ananth. Things have evolved considerably since th= e > introduction of NATs, web and peer networking. Any discussion based on > semantics and not on present day deployment is not going to be useful, = IMHO. If you're proposing to redefine 1812 to include what a NAT does, go ahead, and good luck. Until then, IETF WGs need to stay within the scope of IETF standards. Public opinion doesn't update those standards until we do. >>> Also, actually, when you say "NAT's are not routers", there is a lot = of >>> ambiguity there : >>> >>> Typical case where NAT is configured in a router, which means that th= is >>> device, applies NAT rule and route's the packets.=20 > [suresh] Exactly. That is how NATs route. NATs translate IP addresses b= efore > forwarding. >=20 >> Then the part that routes must obey RFC1812 rules. If the part that >> routes can respond in lieu of the part that NATs, then that's fine. Bu= t >> when the part that NATs acts, it can't act like the router. >> > [suresh] So, if the part that does "NAT function" tells the part that d= oes > "route fucntion" that the router cannot forward the packet=20 That's nonsensical and 1812 does not apply. NAT functions are not required on routers, and routers do not expect such signals from NAT functions. > (Cause: Resource > constraint or admin restrictions), what error code shoud the part that = does > "route function" use when sending ICMP error message back to the sender= ? Are > you saying this cannot be any of the error codes specified in RFC 1812?= When caused by a NAT issue, yes, I'm saying it's inappropriate to co-opt router messages. =2E.. >> However, in the case of the combined device, it still makes sense to >> determine WHY an error code is being generated. If because of a routin= g >> issue, then RFC1812 works; if because of a NAT issue, then RFC1812 is >> NOT the guiding document. >> > [suresh] Joe - This is really a semantics argument. We have had discuss= ions in > the BEHAVE WG on which error code to use and settled on error code 13 a= s the > most appropriate. This requirement has been in the draft for 6 months n= ow.=20 And it's being reviewed by people outside the WG now, which is why it's being discussed now. > I will go with whatever the WG decides in the end. DO you think it is r= eally > necessary to invent a new ICMP error code for the error cause we are ta= lking > about? I think not. My 2c. Yes, I do. And I think this is necessary for exactly every reason anyone else does NOT want to generate a new error code. NATs are NOT routers. Joe --------------enig2F5E4231C2623E63F6ABEEED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLP0SE5f5cImnZrsRAlL0AJ0eVzaOns3BkXu05+wPQvf3H9KYXwCfQWVz rS0dzecDIyNFWHkasTRNPWk= =TsvC -----END PGP SIGNATURE----- --------------enig2F5E4231C2623E63F6ABEEED-- --===============0584020478== 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 --===============0584020478==-- From behave-bounces@ietf.org Mon Apr 23 14:40: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 1Hg3T9-0002tT-8c; Mon, 23 Apr 2007 14:40:59 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg3T7-0002rN-L0 for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3T7-0002rF-BV; Mon, 23 Apr 2007 14:40:57 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3T6-0001tP-Uq; Mon, 23 Apr 2007 14:40:57 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NIecJN004972; Mon, 23 Apr 2007 11:40:43 -0700 (PDT) Message-ID: <462CFD92.5080500@isi.edu> Date: Mon, 23 Apr 2007 11:40:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ted Faber Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> <20070423161021.GI66656@hut.isi.edu> <462CDE0D.7070605@isi.edu> <20070423181822.GB1301@hut.isi.edu> In-Reply-To: <20070423181822.GB1301@hut.isi.edu> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0873117886==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0873117886== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD1A1F59CF37DDDB09348BF86" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD1A1F59CF37DDDB09348BF86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Mon, Apr 23, 2007 at 09:25:49AM -0700, Joe Touch wrote: >> >> Ted Faber wrote: >>> On Sun, Apr 22, 2007 at 10:45:57AM -0700, Joe Touch wrote: >>>> NATs are not routers. Using a code defined in RFC1812 for this purpo= se >>>> is to inappropriately imply that a router is generating the code. >>> I agree that a NAT that doesn't follow 1812 is not a compliant router= =2E >>> However if this is only a semantic issue there are plenty of words ou= t >>> there that could get around the semantic issue, e.g. "... in this cas= e >>> a NAT may send an ICMP type 3 code 13 packet as a proxy for the route= r >>> inside its name space in order to simplify the translation ...". >> There need not be a router on either side of a NAT; in that case, what= >> router is the NAT being a proxy for? >=20 > Oh I bet I can find a router on a non-trivial Internet path. :-) Unless you can find one on EVERY such path, you can't assume you're generating the message as a proxy for that router. I.e., if a router isn't a required part of that path, then sending one as a proxy isn't an option. =2E.. >>> Is there a deeper issue here? Will the ICMP being issued with the NA= T's >>> address cause functional confusion or malfunction in a host receiving= >>> it? Is this a distinction that matters, or are words sufficient? >> I think the issue is "eating cake and having it too". >> >> The fundamental goal of most NATs is invisibility; you can't be >> invisible and scream when something goes wrong. >=20 > This is a fair point. If a NAT is otherwise acting transparently, it i= s > certainly alarming that it will occasionally pop up with an ICMP > message. I can imagine the pain of trying to debug such an error > message using standard tools like traceroute or even ping. ("I got an > ICMP from something that doesn't respond to a ping!?") >=20 > I think that the nail you're hitting is that partial visibility is > clearly confusing to applications and administrators and needs to be > avoided. I'd agree that a device that emits an ICMP but is otherwise > invisible to endpoints is difficult enough to deal with in the real > world that the behavior needs to be discouraged. If you agree with > that, we agree. Yes. The issue, IMO, is that generating a non-NAT ICMP is what's being requested exactly to hide the fact that there's a NAT here, and that's self-contradictory. Joe --------------enigD1A1F59CF37DDDB09348BF86 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLP2SE5f5cImnZrsRAp8YAKDypmW5DIZWzH4+u1RWvBgxZHfV/QCgjdMl sl1xi2c29OqwcjrnyGyKgK0= =Xa57 -----END PGP SIGNATURE----- --------------enigD1A1F59CF37DDDB09348BF86-- --===============0873117886== 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 --===============0873117886==-- From behave-bounces@ietf.org Mon Apr 23 14:50: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 1Hg3cQ-0003Cb-PN; Mon, 23 Apr 2007 14:50:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg3cP-0003CS-F0 for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3cP-0003B9-5E; Mon, 23 Apr 2007 14:50:33 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3cN-0004yB-Nw; Mon, 23 Apr 2007 14:50:33 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l3NIo8XX025301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Apr 2007 11:50:08 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l3NIo8Pc003613; Mon, 23 Apr 2007 11:50:08 -0700 (PDT) (envelope-from faber) Date: Mon, 23 Apr 2007 11:50:08 -0700 From: Ted Faber To: Joe Touch Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Message-ID: <20070423185008.GC1301@hut.isi.edu> References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> <20070423161021.GI66656@hut.isi.edu> <462CDE0D.7070605@isi.edu> <20070423181822.GB1301@hut.isi.edu> <462CFD92.5080500@isi.edu> Mime-Version: 1.0 In-Reply-To: <462CFD92.5080500@isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0864041834==" Errors-To: behave-bounces@ietf.org --===============0864041834== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 23, 2007 at 11:40:18AM -0700, Joe Touch wrote: > Unless you can find one on EVERY such path, you can't assume you're > generating the message as a proxy for that router. I.e., if a router > isn't a required part of that path, then sending one as a proxy isn't an > option. I am so not having that argument. >=20 > Yes. The issue, IMO, is that generating a non-NAT ICMP is what's being > requested exactly to hide the fact that there's a NAT here, and that's > self-contradictory. That seems a more compelling objection to me. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --Bu8it7iiRSEf40bY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLP/gaUz3f+Zf+XsRAjdEAJsHnoDUFiRJUDHYyfkg8PTYf9WCCgCeINl8 gdD5IGRgDoC08NuLFncqsfE= =aRzM -----END PGP SIGNATURE----- --Bu8it7iiRSEf40bY-- --===============0864041834== 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 --===============0864041834==-- From behave-bounces@ietf.org Mon Apr 23 14:58: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 1Hg3k9-0002Af-AK; Mon, 23 Apr 2007 14:58:33 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hg3k8-00029D-U2 for behave-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3k8-000294-KW for behave@ietf.org; Mon, 23 Apr 2007 14:58:32 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3k7-0006n1-9g for behave@ietf.org; Mon, 23 Apr 2007 14:58:32 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3NIwUf8010039 for ; Mon, 23 Apr 2007 11:58:30 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id A620529C002 for ; Mon, 23 Apr 2007 11:58:30 -0700 (PDT) X-AuditID: 11807123-9f3e8bb000000b42-06-462d01d653e3 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay5.apple.com (Apple SCV relay) with ESMTP id 92AE730400B for ; Mon, 23 Apr 2007 11:58:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070423181822.GB1301@hut.isi.edu> References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> <20070423161021.GI66656@hut.isi.edu> <462CDE0D.7070605@isi.edu> <20070423181822.GB1301@hut.isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01797A7E-4F54-4CCE-ABA1-A6F463145D4A@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Date: Mon, 23 Apr 2007 11:58:28 -0700 To: IETF BEHAVE WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Apr 23, 2007, at 11:18, Ted Faber wrote: > > I can imagine the pain of trying to debug such an error message > using standard tools like traceroute or even ping. ("I got an ICMP > from something that doesn't respond to a ping!?") I don't have to imagine this pain. Almost every NAT-gateway/firewall that supports some kind of "stealth" feature does this. Users keep insisting that this is feature, not a bug, and demanding that products do this in their factory default configurations. -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 24 02:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgECC-0006YJ-6C; Tue, 24 Apr 2007 02:08:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgECB-0006Y8-6g for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 02:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgECA-0006Y0-Oj for behave@ietf.org; Tue, 24 Apr 2007 02:08:10 -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 1HgEC9-0007Du-9i for behave@ietf.org; Tue, 24 Apr 2007 02:08:10 -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 l3O67rpW007520; Tue, 24 Apr 2007 09:08:07 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 09:08:03 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 09:08:02 +0300 Received: from esdhcp04070.research.nokia.com (esdhcp04070.research.nokia.com [172.21.40.70]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3O681ki000557; Tue, 24 Apr 2007 09:08:01 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Are NATs routers? Date: Tue, 24 Apr 2007 09:08:05 +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: <200704240908.05495.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 24 Apr 2007 06:08:02.0974 (UTC) FILETIME=[EAD82BE0:01C78636] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ext Philip Matthews 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 23 April 2007 19:00:53 ext Philip Matthews wrote: > I am guessing that this came up before I started attending BEHAVE > meetings, but I would be interesting in hearing more about why NATs > are not routers, or at least router-like. The NATting function is pretty much independant/orthogonal to the routing=20 function. Many NATs are *also* routers in terms of=20 implementations/architecture, though they do not obey the official IETF=20 requirements for a router. There are also NATs that are ARP proxies which=20 deviates a bit from a normal router. You can also put the NAT function within a bridge (in IEEE802.3 sense), tho= ugh=20 again, a bridge is not supposed to mangle the frames payload. And I have al= so=20 seen hybrid NATs that operated at a link-layer on the "internal" side, and = at=20 the socket-layer on the external side: such a NAT is Host in IETF sense on= =20 the external side. =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 Apr 24 08:12: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 1HgJsb-00072M-LA; Tue, 24 Apr 2007 08:12:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgJsa-00071U-7b for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 08:12:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJsZ-000718-Py for behave@ietf.org; Tue, 24 Apr 2007 08:12:19 -0400 Received: from web33307.mail.mud.yahoo.com ([68.142.206.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgJsX-0006aG-Cl for behave@ietf.org; Tue, 24 Apr 2007 08:12:19 -0400 Received: (qmail 44800 invoked by uid 60001); 24 Apr 2007 12:12:16 -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=nN4j4dkRNiiK2PyYTBo+rvAQvS/NugLa4x8Gyg24qY0BqeFerR8gui4kdwYM0EgjlY/fKi5DwxjtvFySloKICyv2yrz1qNpyeFBwOa9oswRgv5k4sr3Mi9PQMSmheNxgHJ2tX55v/Cfqcz98K4d6v8Y69y05FeYAEeFsOLh9+FM=; X-YMail-OSG: ngOB1jwVM1mTVp3evy1iVgRVcWgTMMp4J0OYlGc.AX9Xz7cnhETJmppTuAMzVhiUzOCOWi.bBsqPsf.j59WRARk4qZjwEeswgHsnM0d0TCK43eouMak- Received: from [69.236.67.182] by web33307.mail.mud.yahoo.com via HTTP; Tue, 24 Apr 2007 05:12:16 PDT Date: Tue, 24 Apr 2007 05:12:16 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Re: Are NATs routers? To: Joe Touch , Philip Matthews In-Reply-To: <462CE4F6.6000405@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <651322.42957.qm@web33307.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 --- Joe Touch wrote: > > > Philip Matthews wrote: > > > > On 23-Apr-07, at 12:23 , Joe Touch wrote: > >>> Regarding the TTL, perhaps I am missing something, > >>> but wouldn't we want a NAT > >>> to decrement the TTL field as the packet passes through? > >>> Perhaps this is a new requirement? > >> > >> NATs often want to appear "invisible" - decrementing the TTL would make > >> them very visible, and thus defeats that goal. > > > > I don't think NATs are really invisible. > > There is a lot of work going on to make applications work > > through NATs, and a lot of work going on to discover > > NATs and their properties. > > > > So I think this goal is now obsolete. > > There is *some* work in trying to make the functions of these boxes > visible and controllable, but that doesn't cover the entirety of what > makes a NAT a NAT. > > In general, NATs do their best to be as invisible as possible, and > visible only when that fails. [suresh] From a routing persepctive, NAT are are not invisble. A NAT is as visible as any router is in a network. What NATs do is to make the private networks invisble to the public side. I agree, The adddress/port assignment part in a NAT is often not visible to the outside. But, that does not effect the routing function. regards, suresh > > Joe > > > _______________________________________________ > 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 Tue Apr 24 09:07:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKjX-0006Nu-Sp; Tue, 24 Apr 2007 09:07:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgKjW-0006Nn-KD for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 09:07:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKjW-0006Nf-Ai for behave@ietf.org; Tue, 24 Apr 2007 09:07:02 -0400 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKjW-0001TY-1p for behave@ietf.org; Tue, 24 Apr 2007 09:07:02 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l3OD707T010471; Tue, 24 Apr 2007 09:07:01 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l3OD6xGK027499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Apr 2007 09:07:00 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80F3480A-35A2-44BA-9EF8-D4733AAE8858@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Tue, 24 Apr 2007 09:06:59 -0400 To: Behave WG X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Joe Touch Subject: [BEHAVE] Should NATs decrement the TTL field? 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 Rather than continuing the general discussion on whether a NAT is a router (see separate thread), I now think it is more productive to discuss specific behaviors. To this end, I will ask: Should a NAT decrement the TTL field in the IP header when forwarding a packet? Joe Touch has suggested that the answer should be "No" because NATs should try to be invisible to applications on the private side of the NATs. However, this "invisibility" argument is not resonating with me right now, mostly because I am spending a lot of time right now figuring out how to make P2PSIP overlays work through NATs (in which using STUN and ICE play an important role). In my current thinking, NATs are invisible to the extent that routers are invisible: most applications do not need to know they are there, but some applications do and all applications need to be prepared to accept ICMP messages from them. So I current think a NAT _should_ decrement the TTL field (though I am willing to be convinced otherwise ...). Note that this implies that a NAT needs to generate an ICMP "Time Exceeded" message when the TTL reaches 0, and also implies that a NAT will show up in a traceroute. Comments? Does anyone see a good reason why a NAT _should not_ decrement the TTL field (other than the "try to be invisible" argument)? Are there security implications to this question? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 24 09:20: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 1HgKwT-0002io-UB; Tue, 24 Apr 2007 09:20:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgKwS-0002ig-SS for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 09:20:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKwS-0002iY-Iu for behave@ietf.org; Tue, 24 Apr 2007 09:20:24 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKwR-0004VG-7B for behave@ietf.org; Tue, 24 Apr 2007 09:20:24 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3ODJklf028899; Tue, 24 Apr 2007 06:19:47 -0700 (PDT) Message-ID: <462E03E2.2070604@isi.edu> Date: Tue, 24 Apr 2007 06:19:30 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Philip Matthews References: <80F3480A-35A2-44BA-9EF8-D4733AAE8858@magma.ca> In-Reply-To: <80F3480A-35A2-44BA-9EF8-D4733AAE8858@magma.ca> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Behave WG Subject: [BEHAVE] Re: Should NATs decrement the TTL field? 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="===============0434305532==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0434305532== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEAAEB8C787306B4680213F0E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEAAEB8C787306B4680213F0E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Philip Matthews wrote: > Rather than continuing the general discussion on whether a NAT is a rou= ter > (see separate thread), I now think it is more productive to discuss > specific behaviors. To this end, I will ask: > Should a NAT decrement the TTL field in the IP header when > forwarding a packet? >=20 > Joe Touch has suggested that the answer should be "No"... I will claim that the answer *IS* "no". =2E.. > So I current think a NAT _should_ decrement the TTL field > (though I am willing to be convinced otherwise ...). If they're routers, they MUST decrement the TTL field, and do all the rest of what 1812 requires. I think it's necessary to realize that: - on the public side, NATs are RFC1122 end hosts - on the private side, they almost look like routers, except when they do not So I'll presume you're proposing a new requirement for the private side view; I disagree that the public side can, should, or ever will consider them anything but end hosts that source and sink packets. This would require a set of other actions, notably that all ICMPs originating from the private side - from end hosts or from routers - be translated into 1122-meaningful ICMPs originating from the host side of the NAT. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigEAAEB8C787306B4680213F0E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLgPiE5f5cImnZrsRAsE1AKChNob4EQpJbtcFOJfWMbyEcxEdnwCePULR 8bYfdsCwwBPVs1jRhjGTrf8= =d2Pb -----END PGP SIGNATURE----- --------------enigEAAEB8C787306B4680213F0E-- --===============0434305532== 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 --===============0434305532==-- From behave-bounces@ietf.org Tue Apr 24 09:22: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 1HgKyP-00046T-NU; Tue, 24 Apr 2007 09:22:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgKyN-00041N-5C for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 09:22:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKyM-00040g-QL; Tue, 24 Apr 2007 09:22:22 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKyL-00053l-DS; Tue, 24 Apr 2007 09:22:22 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3ODLdu9029256; Tue, 24 Apr 2007 06:21:40 -0700 (PDT) Message-ID: <462E0453.9090509@isi.edu> Date: Tue, 24 Apr 2007 06:21:23 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Joe Touch , Pyda Srisuresh , behave@ietf.org, tsvwg@ietf.org, "Anantha Ramaiah (ananth)" , "Mahesh Govind (mgovind)" , "Dan Wing (dwing)" , "Faisal Siyavudeen (fsiyavud)" Subject: Re: [Tsvwg] Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <700710.98945.qm@web33309.mail.mud.yahoo.com> <462CFD12.6030004@isi.edu> <20070424010200.A28606@openss7.org> In-Reply-To: <20070424010200.A28606@openss7.org> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: , Content-Type: multipart/mixed; boundary="===============0007001078==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0007001078== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27B56B5FADEE997F88F0227E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27B56B5FADEE997F88F0227E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Joe, =2E.. >> > Yes, I do. And I think this is necessary for exactly every reason an= yone >> > else does NOT want to generate a new error code. NATs are NOT router= s. >=20 > I read this as "NATs are not routers", which sounds like a possibly > incorrect assertion. >=20 > I think NATs can (and perhaps must) also be routers (i.e. they can, > and perhaps must, meet the requirements of an Internet router or > Internet host despite their NATishness). As per my other note, that is an interesting position, but adds a requirement that is not already there. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig27B56B5FADEE997F88F0227E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLgRTE5f5cImnZrsRAqWsAJ4rcCOtcwIyWoVyYRXzRnLTkESJHgCeKkOA 79nUrO9GqFDkcDz/S+mXiQs= =us2x -----END PGP SIGNATURE----- --------------enig27B56B5FADEE997F88F0227E-- --===============0007001078== 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 --===============0007001078==-- From behave-bounces@ietf.org Tue Apr 24 10:58: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 1HgMTV-0002Nv-W1; Tue, 24 Apr 2007 10:58:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgMTT-0002Np-R8 for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 10:58:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMTT-0002Nh-Hd for behave@ietf.org; Tue, 24 Apr 2007 10:58:35 -0400 Received: from 67.111.218.99.ptr.us.xo.net ([67.111.218.99] helo=cuda.ubicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMTS-0006RR-6O for behave@ietf.org; Tue, 24 Apr 2007 10:58:35 -0400 X-ASG-Debug-ID: 1177426708-47ec00000000-9RCVFZ X-Barracuda-URL: http://172.18.1.15:80/cgi-bin/mark.cgi X-Barracuda-Connect: stork.scenix.com[10.10.10.30] X-Barracuda-Start-Time: 1177426708 Received: from STORK.scenix.com (stork.scenix.com [10.10.10.30]) by cuda.ubicom.com (Spam Firewall) with ESMTP id F2821349DE; Tue, 24 Apr 2007 07:58:28 -0700 (PDT) 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 X-ASG-Orig-Subj: RE: [BEHAVE] Should NATs decrement the TTL field? Subject: RE: [BEHAVE] Should NATs decrement the TTL field? Date: Tue, 24 Apr 2007 07:58:28 -0700 Message-ID: In-Reply-To: <80F3480A-35A2-44BA-9EF8-D4733AAE8858@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Should NATs decrement the TTL field? thread-index: AceGccdfpLYbm80ESDeG2AaTn9EgCgAC5ZWw From: "Dave Hudson" To: "Philip Matthews" , "Behave WG" X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at ubicom.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Joe Touch 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: Philip Matthews [mailto:philip_matthews@magma.ca]=20 * Sent: 24 April 2007 14:07 * To: Behave WG * Cc: Joe Touch * Subject: [BEHAVE] Should NATs decrement the TTL field? *=20 * In my current thinking, NATs are invisible to the extent that=20 * routers are invisible: * most applications do not need to know they are there, but=20 * some applications do and all applications need to be prepared=20 * to accept ICMP messages from them. NATs in most non-enterprise uses usually can't be invisible on the private side because they're usually the default gateway for the other hosts on the private network. They frequently also host other services to the private network: DHCP server, HTTP-based configuration, UPnP, etc. The only devices I've seen that are transparent tend to be security appliances such as firewalls and spam filters and I'm curious about how widescale the deployment of transparent NATs might be? * So I current think a NAT _should_ decrement the TTL field=20 * (though I am willing to be convinced otherwise ...). *=20 * Note that this implies that a NAT needs to generate an ICMP=20 * "Time Exceeded" * message when the TTL reaches 0, and also implies that a NAT=20 * will show up in a traceroute. This is the behaviour of pretty-much every low-end NAT I've ever seen tested (and that's a lot of them) - it's also the expected behaviour for the cdrouter test suite which is used by many OEMs for testing such routers (incidently this is the same test suite that has been doing things like verifying hairpinning behaviour since the very early BEHAVE drafts were being written). I can't imagine any OEM I've dealt with not wanting a NAT to show up in a traceroute since they tend to want to use this to diagnose connectivity problems. Regards, Dave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 24 11:19: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 1HgMnY-0004R6-0y; Tue, 24 Apr 2007 11:19:20 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgMnW-0004Qz-Jh for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 11:19:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMnW-0004Qn-A5 for behave@ietf.org; Tue, 24 Apr 2007 11:19:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMnU-00048S-Ez for behave@ietf.org; Tue, 24 Apr 2007 11:19:18 -0400 Received: from [127.0.0.1] (126.sub-75-214-160.myvzw.com [75.214.160.126]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3OFIDXM025608; Tue, 24 Apr 2007 08:18:16 -0700 (PDT) Message-ID: <462E1FA5.5090204@isi.edu> Date: Tue, 24 Apr 2007 08:17:57 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Dave Hudson Subject: Re: [BEHAVE] Should NATs decrement the TTL field? References: In-Reply-To: X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Behave WG , Philip Matthews 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="===============0056913895==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0056913895== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA0B81C1D0341A35C072E31F4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA0B81C1D0341A35C072E31F4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dave Hudson wrote: > * -----Original Message----- > * From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 > * Sent: 24 April 2007 14:07 > * To: Behave WG > * Cc: Joe Touch > * Subject: [BEHAVE] Should NATs decrement the TTL field? > *=20 > * In my current thinking, NATs are invisible to the extent that=20 > * routers are invisible: > * most applications do not need to know they are there, but=20 > * some applications do and all applications need to be prepared=20 > * to accept ICMP messages from them. >=20 > NATs in most non-enterprise uses usually can't be invisible on the > private side ... Folks, We really need to distinguish between what SOME NATs do (or can do) and what ALL NATs MUST do. The MUSTs define what it is to be a NAT, a router, or a host. Everything else is interesting, but not relevant IMO. --- Further, this underscores my position that what a NAT is depends on what side you're looking at. From the public side, IMO they're hosts. From the private side, IMO, they're routers. IMO, that actually provides a reasonable definition of what a NAT is. To that end, ICMP code 13's could rightly be sent back to private-side hosts, but that side is almost never interesting. It's the public side behavior we need to determine, and IMO that's entirely already specified by RFC1122. > * So I current think a NAT _should_ decrement the TTL field=20 > * (though I am willing to be convinced otherwise ...). > *=20 > * Note that this implies that a NAT needs to generate an ICMP=20 > * "Time Exceeded" > * message when the TTL reaches 0, and also implies that a NAT=20 > * will show up in a traceroute. >=20 > This is the behaviour of pretty-much every low-end NAT I've ever seen The key question is "what should a host do when this happens". Hosts don't decrement the TTL; they just receive the packet. TIME_EXCEEDED is not the appropriate response. This isn't a clue that NATs are routers, but rather that they are already visible to the rest of the Internet in ways that many don't want to believe. =2E.. > I can't imagine any OEM I've dealt with not wanting a NAT to show up in= > a traceroute since they tend to want to use this to diagnose > connectivity problems. Agreed - from the inside, not from the outside. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigA0B81C1D0341A35C072E31F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLh+lE5f5cImnZrsRAoelAKDxrG0GDrxY4r/76tJxKIFwi63AtwCfZIES rR/WygI7Qr5uM6ocHbVHAaE= =rKUK -----END PGP SIGNATURE----- --------------enigA0B81C1D0341A35C072E31F4-- --===============0056913895== 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 --===============0056913895==-- From behave-bounces@ietf.org Tue Apr 24 11:32:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMzx-0007td-Py; Tue, 24 Apr 2007 11:32:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgMzx-0007s2-FE for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 11:32:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMzx-0007rm-56 for behave@ietf.org; Tue, 24 Apr 2007 11:32:09 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMzv-00077Y-O8 for behave@ietf.org; Tue, 24 Apr 2007 11:32:09 -0400 Received: from [127.0.0.1] (126.sub-75-214-160.myvzw.com [75.214.160.126]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3OFV1Up028862; Tue, 24 Apr 2007 08:31:05 -0700 (PDT) Message-ID: <462E229C.8030600@isi.edu> Date: Tue, 24 Apr 2007 08:30:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Joe Touch References: <80F3480A-35A2-44BA-9EF8-D4733AAE8858@magma.ca> <462E03E2.2070604@isi.edu> In-Reply-To: <462E03E2.2070604@isi.edu> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Behave WG , Philip Matthews Subject: [BEHAVE] Re: Should NATs decrement the TTL field? 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="===============0282357751==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0282357751== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E4879D5686926DE5BA57432" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E4879D5686926DE5BA57432 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe Touch wrote: >=20 > Philip Matthews wrote: >> Rather than continuing the general discussion on whether a NAT is a ro= uter >> (see separate thread), I now think it is more productive to discuss >> specific behaviors. To this end, I will ask: >> Should a NAT decrement the TTL field in the IP header when >> forwarding a packet? >> >> Joe Touch has suggested that the answer should be "No"... >=20 > I will claim that the answer *IS* "no". To clarify - the answer is "you can't expect it to be YES", and to be a router you MUST expect then answer to be "YES". Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig6E4879D5686926DE5BA57432 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLiKcE5f5cImnZrsRAu6kAJ0XQ8xQo6ReqMeALdhFLuuUANrGvQCeMtf+ uPJmtY0MM1qgQtSH+myvLvI= =OHaF -----END PGP SIGNATURE----- --------------enig6E4879D5686926DE5BA57432-- --===============0282357751== 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 --===============0282357751==-- From behave-bounces@ietf.org Tue Apr 24 11:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgN1t-0008TS-NC; Tue, 24 Apr 2007 11:34:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgF2X-0002Ol-M0 for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 03:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgF2Q-0002Nh-Mm; Tue, 24 Apr 2007 03:02:10 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgF2P-0000y5-Bl; Tue, 24 Apr 2007 03:02:10 -0400 Received: from ns.pigworks.openss7.net (IDENT:I/CTbbIQo3l2FGBtcDVyzqPLqgM0uNu2@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l3O720l13408; Tue, 24 Apr 2007 01:02:00 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l3O720928772; Tue, 24 Apr 2007 01:02:00 -0600 Date: Tue, 24 Apr 2007 01:02:00 -0600 From: "Brian F. G. Bidulock" To: Joe Touch Subject: Re: [Tsvwg] Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Message-ID: <20070424010200.A28606@openss7.org> Mail-Followup-To: Joe Touch , Pyda Srisuresh , behave@ietf.org, tsvwg@ietf.org, "Anantha Ramaiah (ananth)" , "Mahesh Govind (mgovind)" , "Dan Wing (dwing)" , "Faisal Siyavudeen (fsiyavud)" References: <700710.98945.qm@web33309.mail.mud.yahoo.com> <462CFD12.6030004@isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.2.5.1i In-Reply-To: <462CFD12.6030004@isi.edu>; from touch@ISI.EDU on Mon, Apr 23, 2007 at 11:38:10AM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Tue, 24 Apr 2007 11:34:09 -0400 Cc: behave@ietf.org, tsvwg@ietf.org, "Anantha Ramaiah \(ananth\)" , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0642192792==" Errors-To: behave-bounces@ietf.org --===============0642192792== Content-Type: application/pgp; x-action=sign; format=text Content-Disposition: inline; filename="msg.pgp" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe, Joe Touch wrote: (Mon, 23 Apr 2007 11:38:10) > >> Then the part that routes must obey RFC1812 rules. If the part that > >> routes can respond in lieu of the part that NATs, then that's fine. But > >> when the part that NATs acts, it can't act like the router. > >> > > [suresh] So, if the part that does "NAT function" tells the part that does > > "route fucntion" that the router cannot forward the packet > > That's nonsensical and 1812 does not apply. NAT functions are not > required on routers, and routers do not expect such signals from NAT > functions. I read this as "routers are not necessarily NATs", which sounds like a correct assertion. > > I will go with whatever the WG decides in the end. DO you think it is really > > necessary to invent a new ICMP error code for the error cause we are talking > > about? I think not. My 2c. > > Yes, I do. And I think this is necessary for exactly every reason anyone > else does NOT want to generate a new error code. NATs are NOT routers. I read this as "NATs are not routers", which sounds like a possibly incorrect assertion. I think NATs can (and perhaps must) also be routers (i.e. they can, and perhaps must, meet the requirements of an Internet router or Internet host despite their NATishness). Therefore, for a NAT to use an ICMP error code normally used by routers or hosts sounds reasonable to me, provided the NAT-free router and host can interpret the error code as before. - --brian - -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFGLatmMYOP2up1d2URAr1yAJ927uTfbjc96d6VcWGSrlgFY3HCfwCfVau7 dVhz/PdymqR4g5dn/9XOHmM= =ic4g -----END PGP SIGNATURE----- --===============0642192792== 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 --===============0642192792==-- From behave-bounces@ietf.org Tue Apr 24 11:40: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 1HgN7h-0002TZ-Nc; Tue, 24 Apr 2007 11:40:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgN7g-0002TH-6G for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 11:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgN7f-0002T8-St for behave@ietf.org; Tue, 24 Apr 2007 11:40:07 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgN7e-0000AU-Ho for behave@ietf.org; Tue, 24 Apr 2007 11:40:07 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1879960wri for ; Tue, 24 Apr 2007 08:40:06 -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=ARcP9iOkJv1XqpiFKBMqVbzRHfVEV2J3EvwySlyKjpCxN8n5/aUGNh1T4LIMGz+51HnyulG4kwKKr9pCzL6jP/AwvzzCO4SInwCXlzF53I9D+ghB1VbyKV74r+ZQGvgeUjO3tM5+vdN2A7zVNUgk1SWVOiu0YpIZ8JCBkO9hpR8= 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=ddsoIaNqueVpb2jyvjgL/rC/Fsx6uqJ31A/mHfNrBO2S0Dc6E745+16++C7CtV7aZCiJ5QdMMe+iET/RoT/zLGmcB4CtieM9QQfWTBgsb46sEYpv4Jns1EkRfFNl2iDT3pJL8LqfIAnh27JFq92vajqDXRiomEficQzzMMLlMsM= Received: by 10.114.111.1 with SMTP id j1mr3141395wac.1177429205394; Tue, 24 Apr 2007 08:40:05 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Tue, 24 Apr 2007 08:40:05 -0700 (PDT) Message-ID: <894e079b0704240840hd999dd6ka215145cac591907@mail.gmail.com> Date: Tue, 24 Apr 2007 11:40:05 -0400 From: "Medhavi Bhatia" To: "Joe Touch" Subject: Re: [BEHAVE] Should NATs decrement the TTL field? In-Reply-To: <462E1FA5.5090204@isi.edu> MIME-Version: 1.0 References: <462E1FA5.5090204@isi.edu> X-Google-Sender-Auth: 26b028789a7adbd3 X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Behave WG , Philip Matthews 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="===============0827997130==" Errors-To: behave-bounces@ietf.org --===============0827997130== Content-Type: multipart/alternative; boundary="----=_Part_151905_25021032.1177429205328" ------=_Part_151905_25021032.1177429205328 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Joe, I agree with rationale you are using here, but I am not sure NATs were really understood well around the time endpoints and router behavior was defined. TTL is for preventing loops. For all practical purposes NATs are middleboxes and hence not the ultimate destination of the packets. So if we agree with that then they must decrement TTL or manage it in a way to prevent loops. On 4/24/07, Joe Touch wrote: > > > > Dave Hudson wrote: > > * -----Original Message----- > > * From: Philip Matthews [mailto:philip_matthews@magma.ca] > > * Sent: 24 April 2007 14:07 > > * To: Behave WG > > * Cc: Joe Touch > > * Subject: [BEHAVE] Should NATs decrement the TTL field? > > * > > * In my current thinking, NATs are invisible to the extent that > > * routers are invisible: > > * most applications do not need to know they are there, but > > * some applications do and all applications need to be prepared > > * to accept ICMP messages from them. > > > > NATs in most non-enterprise uses usually can't be invisible on the > > private side ... > > Folks, > > We really need to distinguish between what SOME NATs do (or can do) and > what ALL NATs MUST do. > > The MUSTs define what it is to be a NAT, a router, or a host. Everything > else is interesting, but not relevant IMO. > > --- > > Further, this underscores my position that what a NAT is depends on what > side you're looking at. From the public side, IMO they're hosts. From > the private side, IMO, they're routers. IMO, that actually provides a > reasonable definition of what a NAT is. > > To that end, ICMP code 13's could rightly be sent back to private-side > hosts, but that side is almost never interesting. It's the public side > behavior we need to determine, and IMO that's entirely already specified > by RFC1122. > > > * So I current think a NAT _should_ decrement the TTL field > > * (though I am willing to be convinced otherwise ...). > > * > > * Note that this implies that a NAT needs to generate an ICMP > > * "Time Exceeded" > > * message when the TTL reaches 0, and also implies that a NAT > > * will show up in a traceroute. > > > > This is the behaviour of pretty-much every low-end NAT I've ever seen > > The key question is "what should a host do when this happens". Hosts > don't decrement the TTL; they just receive the packet. TIME_EXCEEDED is > not the appropriate response. > > This isn't a clue that NATs are routers, but rather that they are > already visible to the rest of the Internet in ways that many don't want > to believe. > > ... > > I can't imagine any OEM I've dealt with not wanting a NAT to show up in > > a traceroute since they tend to want to use this to diagnose > > connectivity problems. > > Agreed - from the inside, not from the outside. > > Joe > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > > ------=_Part_151905_25021032.1177429205328 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Joe, I agree with rationale you are using here, but I am not sure NATs were really understood well around the time endpoints and router behavior was defined. TTL is for preventing loops. For all practical purposes NATs are middleboxes and hence not the ultimate destination of the packets. So if we agree with that then they must decrement TTL or manage it in a way to prevent loops.

On 4/24/07, Joe Touch <touch@isi.edu> wrote:


Dave Hudson wrote:
> * -----Original Message-----
> * From: Philip Matthews [mailto:philip_matthews@magma.ca]
> * Sent: 24 April 2007 14:07
> * To: Behave WG
> * Cc: Joe Touch
> * Subject: [BEHAVE] Should NATs decrement the TTL field?
> *
> * In my current thinking, NATs are invisible to the extent that
> * routers are invisible:
> * most applications do not need to know they are there, but
> * some applications do and all applications need to be prepared
> * to accept ICMP messages from them.
>
> NATs in most non-enterprise uses usually can't be invisible on the
> private side ...

Folks,

We really need to distinguish between what SOME NATs do (or can do) and
what ALL NATs MUST do.

The MUSTs define what it is to be a NAT, a router, or a host. Everything
else is interesting, but not relevant IMO.

---

Further, this underscores my position that what a NAT is depends on what
side you're looking at. From the public side, IMO they're hosts. From
the private side, IMO, they're routers. IMO, that actually provides a
reasonable definition of what a NAT is.

To that end, ICMP code 13's could rightly be sent back to private-side
hosts, but that side is almost never interesting. It's the public side
behavior we need to determine, and IMO that's entirely already specified
by RFC1122.

> * So I current think a NAT _should_ decrement the TTL field
> * (though I am willing to be convinced otherwise ...).
> *
> * Note that this implies that a NAT needs to generate an ICMP
> * "Time Exceeded"
> * message when the TTL reaches 0, and also implies that a NAT
> * will show up in a traceroute.
>
> This is the behaviour of pretty-much every low-end NAT I've ever seen

The key question is "what should a host do when this happens". Hosts
don't decrement the TTL; they just receive the packet. TIME_EXCEEDED is
not the appropriate response.

This isn't a clue that NATs are routers, but rather that they are
already visible to the rest of the Internet in ways that many don't want
to believe.

...
> I can't imagine any OEM I've dealt with not wanting a NAT to show up in
> a traceroute since they tend to want to use this to diagnose
> connectivity problems.

Agreed - from the inside, not from the outside.

Joe

--
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave



------=_Part_151905_25021032.1177429205328-- --===============0827997130== 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 --===============0827997130==-- From behave-bounces@ietf.org Tue Apr 24 11:53: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 1HgNKJ-0003gg-75; Tue, 24 Apr 2007 11:53:11 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgNKI-0003ft-8p for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 11:53:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNKH-0003fi-VA for behave@ietf.org; Tue, 24 Apr 2007 11:53:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNKG-0003bw-MW for behave@ietf.org; Tue, 24 Apr 2007 11:53:09 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2007 08:53:06 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="415057997:sNHT42013452" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3OFr5S7022605 for ; Tue, 24 Apr 2007 08:53:05 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3OFr5wn006558 for ; Tue, 24 Apr 2007 15:53:05 GMT From: "Dan Wing" To: "'Behave WG'" Date: Tue, 24 Apr 2007 08:53:05 -0700 Message-ID: <05a501c78688$a6242790$9a736b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceGiKWsEU7GlwZlT+ytlHHJklOr+Q== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=745; t=1177429985; x=1178293985; c=relaxed/simple; s=sjdkim7002; 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:=20ICMP=20sent=20by=20a=20NAT |Sender:=20; bh=LCqGgFUzxgb6mUDEpNvLtIZx2Cwh+O2lBdvpVY1ElnM=; b=du/GAvBlXXShHUxYQo2irPPYinDG0y11JTYDcskYCTsjam38qGMIOFHka9EQ30SAQQV/fNkP LD/O+M9bpB+9ZCxkYE7cI9BP1odTRoUi73QqR2bVR4MOAgDMCzK1vUGf; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [BEHAVE] ICMP sent by a NAT 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 believe I have caught up on the ICMP argument, and have a question: We need NATs to send ICMPs for large packets (for PMTUD, most importantly for TCP's path mtu discovery) if they cannot forward the packet without fragmenting the packet. There seems to be consensus on that, and such a requirement is in BEHAVE's TCP document which is in IESG processing and completed a WGLC last call in BEHAVE (which was also announced in TCPM). But we don't want NATs to send ICMPs if the NAT is unable/unwilling to forward a packet for other reasons (e.g., running out of resources, administrative policy)? I am not able to wrap my head around the logic of doing the first (ICMP 'too big') but the discomfort with doing the second. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 24 12:22: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 1HgNmj-0007Q0-SO; Tue, 24 Apr 2007 12:22:33 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgNmi-0007Pv-Py for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 12:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNmi-0007Pn-GS for behave@ietf.org; Tue, 24 Apr 2007 12:22:32 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNmi-0003Vx-2w for behave@ietf.org; Tue, 24 Apr 2007 12:22:32 -0400 Received: by py-out-1112.google.com with SMTP id f31so1579593pyh for ; Tue, 24 Apr 2007 09:22:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MPrGyEcQJqoANm2QXwQNOFMMU63fKC59YwwWBgKyxP4RxllTFvUWpcPPERx5EVrTF2f6m1XmXaWI/ALBpo/1fJW06VNj/BKON916OpR1DeIbCbNK7Ibzvg9aBHisx9QWA4gGHrIjrdhL7CEuC/aBIQeTWj5BWbiP2CX5sdQGhLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZwB73namHBIZ1urzXONiMhujPFZ1az7ZFHaGKFhdv3AkBgwQtJmFd9axtUzWML5LVK6qW1rqVRaUNqSU6sTloGC7m2Pu0LvLoFCLGHqKdT9wN5xjG2BJQEbLUfHJ1sPk8I+V7Qrezg6i3ADhzAfP8i5+aYZufgf3pg7n7vmwFZs= Received: by 10.35.50.5 with SMTP id c5mr13331071pyk.1177431751541; Tue, 24 Apr 2007 09:22:31 -0700 (PDT) Received: by 10.35.43.16 with HTTP; Tue, 24 Apr 2007 09:22:31 -0700 (PDT) Message-ID: Date: Tue, 24 Apr 2007 21:52:31 +0530 From: "Mayank Dev Sondhi" To: "=?ISO-8859-1?Q?R=E9mi_Denis-Courmont?=" Subject: Re: [BEHAVE] TCP framing in TURN In-Reply-To: <200704201249.50462.remi.denis-courmont@nokia.com> MIME-Version: 1.0 References: <462599F1.2050102@gmail.com> <200704201249.50462.remi.denis-courmont@nokia.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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="===============0087774206==" Errors-To: behave-bounces@ietf.org --===============0087774206== Content-Type: multipart/alternative; boundary="----=_Part_47138_33064920.1177431751372" ------=_Part_47138_33064920.1177431751372 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline In our implementation we use the below to differentiate framed vs. unframed for backward compat. Makes me kinda wish for a versioning scheme in the protocol as more folks adopt the draft standard.(unless we have one now, haven't thoroughly checked the latest turn - 03) -Mayank On 4/20/07, R=E9mi Denis-Courmont wrote: > > On Wednesday 18 April 2007 07:09:21 ext Evgeniy Khramtsov wrote: > > From draft-ietf-behave-turn-03.txt, para 5: > > > > "The first octet of this framing is 0x02 to indicate STUN messages or > > 0x03 to indicate end-to-end data to or from the active destination. > > Note that the first octet is always distinguishable from an unframed > > STUN request or response (which is always 0x00 or 0x01)." > > > Could you explain me why do you need to additionaly frame STUN messages > > since all STUN messages have always 0x00 or 0x01 in their first octet > > and we can simply distinguish them from the end-to-end data frame? Am I > > misreading something? > > Sure, we could avoid framing STUN messages (I vaguely remember this being > already pointed out at the last meeting). > > However, the end-to-end data framing will probably need to be changed to > something that sets either or both of the higher-order two bits of the > framing (since STUN always sets the first two bits to zero). Could be > something like 0x4001PQRT then two bytes length, and then 0xPQRT bytes of > TCP > data. > > -- > R=E9mi Denis-Courmont > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_47138_33064920.1177431751372 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
In our implementation we use the below to differentiate framed vs. unf= ramed for backward compat. Makes me kinda wish for a versioning scheme in t= he protocol as more folks adopt the draft standard.(unless we have one now,= haven't thoroughly checked the latest turn - 03)
 
-Mayank

 
On 4/20/07, = R=E9mi Denis-Courmont <remi.denis-courmont@nokia.com> wrote:
On Wednesday 18 April 2007 07:09= :21 ext Evgeniy Khramtsov wrote:
>  From draft-ietf-behave-= turn-03.txt , para 5:
>
> "The first octet of this framing is 0x02 to = indicate STUN messages or
> 0x03 to indicate end-to-end data to or fr= om the active destination.
> Note that the first octet is always dist= inguishable from an unframed
> STUN request or response (which is always 0x00 or 0x01)."
=
> Could you explain me why do you need to additionaly frame STUN mes= sages
> since all STUN messages have always 0x00 or 0x01 in their fir= st octet
> and we can simply distinguish them from the end-to-end data frame?= Am I
> misreading something?

Sure, we could avoid framing STU= N messages (I vaguely remember this being
already pointed out at the las= t meeting).

However, the end-to-end data framing will probably need to be chang= ed to
something that sets either or both of the higher-order two bits of= the
framing (since STUN always sets the first two bits to zero). Could = be
something like 0x4001PQRT then two bytes length, and then 0xPQRT bytes = of TCP
data.

--
R=E9mi Denis-Courmont


_____________= __________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave

------=_Part_47138_33064920.1177431751372-- --===============0087774206== 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 --===============0087774206==-- From behave-bounces@ietf.org Tue Apr 24 12:49: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 1HgOCz-0005hb-NL; Tue, 24 Apr 2007 12:49:41 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgOCw-0005I7-Pf for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 12:49:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOCw-0005Bd-8F for behave@ietf.org; Tue, 24 Apr 2007 12:49:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HgOCu-0004nt-Qy for behave@ietf.org; Tue, 24 Apr 2007 12:49:38 -0400 Received: from [127.0.0.1] (126.sub-75-214-160.myvzw.com [75.214.160.126]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3OGmkQD018256; Tue, 24 Apr 2007 09:48:51 -0700 (PDT) Message-ID: <462E34BB.8090907@isi.edu> Date: Tue, 24 Apr 2007 09:47:55 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Medhavi Bhatia Subject: Re: [BEHAVE] Should NATs decrement the TTL field? References: <462E1FA5.5090204@isi.edu> <894e079b0704240840hd999dd6ka215145cac591907@mail.gmail.com> In-Reply-To: <894e079b0704240840hd999dd6ka215145cac591907@mail.gmail.com> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Behave WG , Philip Matthews 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="===============1445954603==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1445954603== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE537BEA4ADD54336D8F35021" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE537BEA4ADD54336D8F35021 address, they source and sink packets, and things behind them are intended to be invisible. That's no different from a end host that sinks IP packets and generates some backend messages internally (e.g., on its SATA link to the disk) or inside its internal interconnects. > So if we agree with that then they must decrement TTL or > manage it in a way to prevent loops. IMO, if we're going to revise the definition of a NAT, there are some requirements: A- to the public side, obey 1122 B- to the private side, obey 1812 This means that for packets going from public->private, the TTL must be decremented. It also means that for packets going from private->public, the TTL need not be decremented. I think that's OK, since a loop through a single NAT would require going public->private at some point. If you always go private->public, there can be no loop. However, this presumes we're redefining a NAT to fit better (IMO) into the Internet architecture to remove these ambiguities (e.g., what ICMP codes to send at what time). I'm in favor of that - and might even want to participate - but I didn't think that was in the charter of this WG. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigE537BEA4ADD54336D8F35021 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLjTbE5f5cImnZrsRAnrZAJ9DLdHFxoRD/hrIndnCaW+aAo7bpgCg9uvI z494S+UKNoCIRPVONwnTUhQ= =ywA6 -----END PGP SIGNATURE----- --------------enigE537BEA4ADD54336D8F35021-- --===============1445954603== 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 --===============1445954603==-- From behave-bounces@ietf.org Tue Apr 24 14: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 1HgPKF-0002xK-Ss; Tue, 24 Apr 2007 14:01:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgPKE-0002xE-9G for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 14:01:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgPKD-0002x6-V7 for behave@ietf.org; Tue, 24 Apr 2007 14:01:13 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HgPKC-0006PQ-HI for behave@ietf.org; Tue, 24 Apr 2007 14:01:13 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3OI1Bem013732 for ; Tue, 24 Apr 2007 11:01:11 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 9670E10B3B for ; Tue, 24 Apr 2007 11:01:11 -0700 (PDT) X-AuditID: 11807124-a049cbb000000872-60-462e45e79ee9 Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay6.apple.com (Apple SCV relay) with ESMTP id 8CCDE10044 for ; Tue, 24 Apr 2007 11:01:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <651322.42957.qm@web33307.mail.mud.yahoo.com> References: <651322.42957.qm@web33307.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] Re: Are NATs routers? Date: Tue, 24 Apr 2007 11:01:08 -0700 To: Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Apr 24, 2007, at 05:12, Pyda Srisuresh wrote: > > [suresh] From a routing persepctive, NAT are are not invisble. A > NAT is as > visible as any router is in a network. What NATs do is to make the > private > networks invisble to the public side. I agree, The adddress/port > assignment > part in a NAT is often not visible to the outside. But, that does > not effect > the routing function. I remember the days when we would have said that a NAT is a kind of gateway between separate address realms. Did the phrase "address realm" fall out of favor again? -- j h woodyatt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 24 15:24: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 1HgQce-00043b-Sw; Tue, 24 Apr 2007 15:24:20 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgQcd-0003zq-Bm for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 15:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgQcc-0003x8-Vz for behave@ietf.org; Tue, 24 Apr 2007 15:24:18 -0400 Received: from cod.sandelman.ca ([192.139.46.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgQcb-00073C-NB for behave@ietf.org; Tue, 24 Apr 2007 15:24:18 -0400 Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id 15CA312377; Tue, 24 Apr 2007 15:24:17 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D41D44E7A2; Tue, 24 Apr 2007 15:24:08 -0400 (EDT) From: Michael Richardson To: Philip Matthews Subject: Re: [BEHAVE] Should NATs decrement the TTL field? In-Reply-To: Message from Philip Matthews of "Tue, 24 Apr 2007 09:06:59 EDT." <80F3480A-35A2-44BA-9EF8-D4733AAE8858@magma.ca> References: <80F3480A-35A2-44BA-9EF8-D4733AAE8858@magma.ca> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Tue, 24 Apr 2007 15:24:08 -0400 Message-ID: <1582.1177442648@marajade.sandelman.ca> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Behave WG , Joe Touch 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Philip" == Philip Matthews writes: Philip> specific behaviors. To this end, I will ask: Philip> Should a NAT decrement the TTL field in the IP header when Philip> forwarding a packet? ABSOLUTELY. If it doesn't do that, then I can't see it. I need to see it to know that I'm being screwed over. Philip> In my current thinking, NATs are invisible to the extent Philip> that routers are invisible: I agree. Philip> Note that this implies that a NAT needs to generate an ICMP Philip> "Time Exceeded" message when the TTL reaches 0, and also Philip> implies that a NAT will show up in a traceroute. Yes. I don't like calling NAT boxes "home routers", because they don't behave as routers from both sides. Unfortunately, I've lost that war with the "market" - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRi5ZVoCLcPvd0N1lAQICygf+Mahl8+96okIsRY1GbRR5aDf1XGUXXeEJ ywJHNvHIrqTqhlw+aQhQ2f6U+vfTCroJ+PC+MlyAG3L2l61UtH3p5fGwXRFIsbvZ BURmbXNCp78ZITwTJ2nMqbK5qJT82mj59LF68Qm/pJi4c384PT14wuVFW5kRd6uO +798DIZ+3Uss6MiUrNxYxXoiPI59N1wPQZZ+EXlpxTOdHZqZgNaUvgDJBvoJ9ElA xNv+fka+JuyxxXoSmNSkHozxZNAAN7JKdvFByWig7L54UxBwyYgSTV6OBCBBq5ye G8/mDp5D0F7YoPGzgsPYmtDAfbqoKq4XoLK4TLhnksrgtYFX+Ny97A== =jZAo -----END PGP SIGNATURE----- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 24 20:39: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 1HgVXG-0001wv-AJ; Tue, 24 Apr 2007 20:39:06 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgVXE-0001wR-Od for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 20:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgVXE-0001wA-EM for behave@ietf.org; Tue, 24 Apr 2007 20:39:04 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgVXD-0002G3-2Q for behave@ietf.org; Tue, 24 Apr 2007 20:39:04 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 87D6049AA; Tue, 24 Apr 2007 20:39:02 -0400 (EDT) From: Sam Hartman To: Saikat Guha References: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> Date: Tue, 24 Apr 2007 20:39:02 -0400 In-Reply-To: <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> (Saikat Guha's message of "Sun, 22 Apr 2007 10:28:19 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: behave Subject: [BEHAVE] Re: DISCUSS and COMMENT: draft-ietf-behave-tcp 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 >>>>> "Saikat" == Saikat Guha writes: Saikat> 2. Scope clarification: Clarify connections to the NAT Saikat> itself (e.g. an HTTP-management interface) are Saikat> out-of-scope of this document. How to deal with such Saikat> connections (be they TCP or UDP) is complex, which an Saikat> implementation-guideline document could address. For the record, I think my comment triggered this. Personally, I think the WG has made the document worse rather than better by moving in this direction. It's not bad enough that I'm going to enter a discuss, but please do not make the change on my account. I think that if you were going to create a document that had positive impact you would address this issue or at least discuss the challenges. Note however that my comment is non-blocking. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 24 21:19: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 1HgWAE-0006v0-3T; Tue, 24 Apr 2007 21:19:22 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgWAD-0006uv-9O for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 21:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWAC-0006un-WA for behave@ietf.org; Tue, 24 Apr 2007 21:19:20 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgWAB-0000vY-MZ for behave@ietf.org; Tue, 24 Apr 2007 21:19:20 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2007 18:19:16 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="140214881:sNHT3405667014" 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 l3P1JGAU009281; Tue, 24 Apr 2007 18:19:16 -0700 Received: from dwingwxp (dhcp-128-107-163-142.cisco.com [128.107.163.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3P1JGEi028277; Wed, 25 Apr 2007 01:19:16 GMT From: "Dan Wing" To: "'Sam Hartman'" , "'Saikat Guha'" Subject: RE: [BEHAVE] Re: DISCUSS and COMMENT: draft-ietf-behave-tcp Date: Tue, 24 Apr 2007 18:19:15 -0700 Message-ID: <026a01c786d7$bd9de240$05716b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceG0mISAizyiJDUSdSUWpEHjydv5AABLLkA In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1302; t=1177463956; x=1178327956; 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=20DISCUSS=20and=20COMMENT=3A=20draft -ietf-behave-tcp |Sender:=20; bh=MxubDuuMXwP0rG3TzY6ZXc1CrvigcwW68W5RH+ZZF+8=; b=fm9SmJptxZOThK3dXGqCB7c0ZRQbD34X68gGU8LVdx61OLQasw7SAR3GpinvIf3fMqeDIBNb oIfJxz91TYYGSBpheWnjW05ACFVVQ6mIr+aKdKOC948bCy6Tiu8KoaJZ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'behave' 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 Sam Hartman wrote: > >>>>> "Saikat" == Saikat Guha writes: > Saikat> 2. Scope clarification: Clarify connections to the NAT > Saikat> itself (e.g. an HTTP-management interface) are > Saikat> out-of-scope of this document. How to deal with such > Saikat> connections (be they TCP or UDP) is complex, which an > Saikat> implementation-guideline document could address. > > For the record, I think my comment triggered this. Yes. > Personally, I > think the WG has made the document worse rather than better by moving > in this direction. > > It's not bad enough that I'm going to enter a discuss, but please do > not make the change on my account. > > I think that if you were going to create a document that had positive > impact you would address this issue or at least discuss the > challenges. The authors and I exchanged several messages about your original comment and still don't understand what change you are suggesting. Would you have time to explain your comment in a phone call with us? If it's not important, I guess that sentence can just be backed out, but I know you created that comment because you wanted the document improved. > Note however that my comment is non-blocking. Understood. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 24 22:00: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 1HgWnC-0001Yb-2w; Tue, 24 Apr 2007 21:59:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgWnB-0001YS-9m for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 21:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWnA-0001YJ-UV for behave@ietf.org; Tue, 24 Apr 2007 21:59:36 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgWn9-00086J-KU for behave@ietf.org; Tue, 24 Apr 2007 21:59:36 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 21:59:30 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 21:59:25 -0400 From: Saikat Guha To: Sam Hartman In-Reply-To: References: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> Date: Tue, 24 Apr 2007 21:59:25 -0400 Message-Id: <1177466365.25477.8.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 25 Apr 2007 01:59:25.0671 (UTC) FILETIME=[59DA1F70:01C786DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: behave Subject: [BEHAVE] Re: DISCUSS and COMMENT: draft-ietf-behave-tcp 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="===============0267862948==" Errors-To: behave-bounces@ietf.org --===============0267862948== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Q1SPM9e+JTcEk2tW5Izf" --=-Q1SPM9e+JTcEk2tW5Izf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-24 at 20:39 -0400, Sam Hartman wrote: > >>>>> "Saikat" =3D=3D Saikat Guha writes: > Saikat> 2. Scope clarification: Clarify connections to the NAT > Saikat> itself (e.g. an HTTP-management interface) are > Saikat> out-of-scope of this document. How to deal with such > Saikat> connections (be they TCP or UDP) is complex, which an > Saikat> implementation-guideline document could address. >=20 > I think that if you were going to create a document that had positive > impact you would address this issue or at least discuss the > challenges. I am not completely sure I understand your concerns. Can you clarify the issue or illustrate a case where some NAT behavior in this regard breaks applications? cheers, --=20 Saikat --=-Q1SPM9e+JTcEk2tW5Izf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGLrX9nFltqi691/oRAlebAJ9MlatD1JWDDNWcPOjbL2+AA+1flwCfVqJh bbD9qsJ7Be3wJcMAyYHk2CQ= =0s5i -----END PGP SIGNATURE----- --=-Q1SPM9e+JTcEk2tW5Izf-- --===============0267862948== 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 --===============0267862948==-- From behave-bounces@ietf.org Tue Apr 24 23:35: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 1HgYHf-00086A-Cz; Tue, 24 Apr 2007 23:35:11 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgYHe-000862-AJ for behave-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 23:35:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgYHe-00085u-0M for behave@ietf.org; Tue, 24 Apr 2007 23:35:10 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgYHc-0003FV-8z for behave@ietf.org; Tue, 24 Apr 2007 23:35:09 -0400 Received: by ug-out-1314.google.com with SMTP id 72so279745ugd for ; Tue, 24 Apr 2007 20:35:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:x-accept-language:mime-version:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=RFsUU+07dc2mKWCJf1ln1PoovyuCKXGBxZuXRA40cMT3Z+rpSbIAQh8DXmQrtTW8ACnj4xe6/EuhZwOX+MU53P5/6mXwHuysHFjTXOI0pkw0X8IDlGkYFPQMjjMr6a7S383wTYwtQxg2pLN98VL7ZmdH9Zk5yLc9tfwOT2L2/3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=K32V8YGf8NCMc6kWcYTB3/ZowpzJTDAmN6cCvJhDIBTkzA8Pital1cqfvqDX3ILAnqVeAODVqg0//Q9tXBBS9UAZEIOFhTDNt8QE3LFMuQxbrz6CxFgjY7MXjQNgrb82oNz06R4FQGf3q3pBLOnagrAhsxu2yNGaRtWmKfwehlw= Received: by 10.67.50.17 with SMTP id c17mr183148ugk.1177472107532; Tue, 24 Apr 2007 20:35:07 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTP id c22sm1039534ika.2007.04.24.20.35.04; Tue, 24 Apr 2007 20:35:05 -0700 (PDT) Message-ID: <462ECC6F.4090801@gmail.com> Date: Wed, 25 Apr 2007 13:35:11 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 CC: behave@ietf.org Subject: Re: [BEHAVE] TCP framing in TURN References: <462599F1.2050102@gmail.com> <200704201249.50462.remi.denis-courmont@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Mayank Dev Sondhi wrote: > In our implementation we use the below to differentiate framed vs. > unframed > for backward compat. Makes me kinda wish for a versioning scheme in the > protocol as more folks adopt the draft standard.(unless we have one now, > haven't thoroughly checked the latest turn - 03) I'm not quite sure what versioning scheme you are talking about. All 'new' packets MUST have Magic Cookie in the header, thus you can differentiate them from 'old' packets. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 25 05:08:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdUT-0000CF-Ap; Wed, 25 Apr 2007 05:08:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgdUS-0000C6-Ha for behave-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 05:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdUP-0000Bi-5K for behave@ietf.org; Wed, 25 Apr 2007 05:08:41 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdUN-0008Sm-RJ for behave@ietf.org; Wed, 25 Apr 2007 05:08:41 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 86C0B49AA; Wed, 25 Apr 2007 05:08:38 -0400 (EDT) From: Sam Hartman To: Saikat Guha References: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> <1177466365.25477.8.camel@sioux.systems.cs.cornell.edu> Date: Wed, 25 Apr 2007 05:08:38 -0400 In-Reply-To: <1177466365.25477.8.camel@sioux.systems.cs.cornell.edu> (Saikat Guha's message of "Tue, 24 Apr 2007 21:59:25 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: behave Subject: [BEHAVE] Re: DISCUSS and COMMENT: draft-ietf-behave-tcp 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 >>>>> "Saikat" == Saikat Guha writes: Saikat> On Tue, 2007-04-24 at 20:39 -0400, Sam Hartman wrote: >> >>>>> "Saikat" == Saikat Guha writes: Saikat> 2. Scope clarification: Clarify connections to the NAT Saikat> itself (e.g. an HTTP-management interface) are Saikat> out-of-scope of this document. How to deal with such Saikat> connections (be they TCP or UDP) is complex, which an Saikat> implementation-guideline document could address. >> I think that if you were going to create a document that had >> positive impact you would address this issue or at least >> discuss the challenges. Saikat> I am not completely sure I understand your concerns. Can Saikat> you clarify the issue or illustrate a case where some NAT Saikat> behavior in this regard breaks applications? One of the purposes of behave is to make it easy for NAT vendors to get it right. So, you need to provide enough implementation guidance that you actually get that result. I'm implementing a NAT on top of a commodity OS--say stripped down arm Linux or something like that. But the point is I have a normal TCP stack as well as my NAT. I receive a TCP packet. If it is a locally destined syn to a port I have nothing running on, I should respond with a reset. If it is a packet to a port that is a not-yet-allocated NAT mapping, your document claims I should respond a few seconds later with an ICMP message. Absent looking into the future, I need to do something clever. For some platforms I can assume any port that doesn't have anything locally bound is a potential NAT mapping and use that behavior. For other platforms that would be highly undesirable. For example I don't think you can convince Windows connection sharing or OS X 's NAT functionality to treat things this way. I'm curious how you propose that Linux implement this; it's definitely going to be tricky to get the configuration right. By ignoring these issues, you increase the probability that people will produce boxes that don't do what you expect and don't do what your users expect. If people who try and follow your rules run into market acceptance problems because they ignored some tricky case and produced a broken product, then they will ignore your rules in the future. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 25 09:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghdI-0001De-PQ; Wed, 25 Apr 2007 09:34:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HghdH-0001DZ-Cn for behave-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 09:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghdH-0001DQ-33 for behave@ietf.org; Wed, 25 Apr 2007 09:34:07 -0400 Received: from web33303.mail.mud.yahoo.com ([68.142.206.118]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HghdF-00018y-Js for behave@ietf.org; Wed, 25 Apr 2007 09:34:07 -0400 Received: (qmail 84717 invoked by uid 60001); 25 Apr 2007 13:34:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=niGS4y8FbVGS3j6r0Lpn6dNcJ9pu0TlneaKFdYBLyGow0lRZg3BnxwuPzgF+mL4ySnLBmLfqGj2fQbBzsMcA92FkWAZmfVkAsv3uRKgNlhBh8TaW1hvMw5yZHp60WLRkHgjKSlYK5l/P/Iy/e0bTwM5xE+U/A8F7PdOtWYrV3eI=; X-YMail-OSG: 6lTatGoVM1kWP.5WbvpsPBHeBvJmIqmxQUlROkATQ6W7uWc3420dG0LyDJ_8kL__w9a1cfaMAAEan0iy17BR9wlNGOM5vp0yeDuOnY29X9Sprz85iH0- Received: from [69.236.67.182] by web33303.mail.mud.yahoo.com via HTTP; Wed, 25 Apr 2007 06:34:04 PDT Date: Wed, 25 Apr 2007 06:34:04 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Re: Are NATs routers? To: james woodyatt , Behave WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <837404.84350.qm@web33303.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 --- james woodyatt wrote: > On Apr 24, 2007, at 05:12, Pyda Srisuresh wrote: > > > > [suresh] From a routing persepctive, NAT are are not invisble. A > > NAT is as > > visible as any router is in a network. What NATs do is to make the > > private > > networks invisble to the public side. I agree, The adddress/port > > assignment > > part in a NAT is often not visible to the outside. But, that does > > not effect > > the routing function. > > I remember the days when we would have said that a NAT is a kind of > gateway between separate address realms. Did the phrase "address > realm" fall out of favor again? > [suresh] No, the phrase has not fallen out of favor, AFAIK. NAT fucntions as transparant router to hosts in different realms, by mapping addresses from one realm to another. regards, suresh > > -- > j h woodyatt > > > > > _______________________________________________ > 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 Apr 25 16:48:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgoPs-00017h-PD; Wed, 25 Apr 2007 16:48:44 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgoPr-00017c-U3 for behave-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 16:48:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgoPr-00017U-KR for behave@ietf.org; Wed, 25 Apr 2007 16:48:43 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgoPq-0003hj-Be for behave@ietf.org; Wed, 25 Apr 2007 16:48:43 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 16:48:37 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 16:48:32 -0400 From: Saikat Guha To: Sam Hartman In-Reply-To: References: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> <1177466365.25477.8.camel@sioux.systems.cs.cornell.edu> Date: Wed, 25 Apr 2007 16:48:31 -0400 Message-Id: <1177534111.32585.3.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 25 Apr 2007 20:48:32.0194 (UTC) FILETIME=[15ED2A20:01C7877B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: behave , Dan Wing Subject: [BEHAVE] Re: DISCUSS and COMMENT: draft-ietf-behave-tcp 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="===============2011456677==" Errors-To: behave-bounces@ietf.org --===============2011456677== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Vo5G6iyKA/jhGU1n65N8" --=-Vo5G6iyKA/jhGU1n65N8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-04-25 at 05:08 -0400, Sam Hartman wrote:=20 > I receive a TCP packet. If it is a locally destined syn to a port I > have nothing running on, I should respond with a reset. If it is a > packet to a port that is a not-yet-allocated NAT mapping, your > document claims I should respond a few seconds later with an ICMP > message. Absent looking into the future, I need to do something > clever. For some platforms I can assume any port that doesn't have > anything locally bound is a potential NAT mapping and use that > behavior. For other platforms that would be highly undesirable. =20 Ah ok, I think I understand your concern now. For such devices, the following implementation would be compliant. - the NAT part only allocates mappings in a fixed port range. Say ports 45000--55000. Or perhaps has an allocation black-list=20 (port 80, 22, etc.) - the host part uses ports outside that range (or in the black-list) - when a SYN arrives in the allocation range, the NAT follows BEHAVE - when a SYN arrives outside the allocation range, the NAT follows 1122 Would the following text address your concern? Below the justification for REQ-4 (unsolicited SYN, delayed ICMP req): "For NATs that combine NAT functionality with end-host functionality (e.g. an end-host that also serves as a NAT for other hosts behind it), this requirement applies only to SYNs intended for the NAT'ed hosts and not to SYNs intended for the NAT itself. One way to determine whether the inbound SYN is intended for a NAT'ed host or for the NAT itself is for such an implementation to allocate NAT mappings from one port range, and allocate ports for local endpoints from a different non-overlapping port range. More dynamic implementations can be imagined." cheers, --=20 Saikat --=-Vo5G6iyKA/jhGU1n65N8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGL76fnFltqi691/oRAhP5AJ9+eVSw9kqk/ERemzot/vNE4a1pAwCeOPK7 ldznJgmrLiWOgr74OOJxyZs= =/XWN -----END PGP SIGNATURE----- --=-Vo5G6iyKA/jhGU1n65N8-- --===============2011456677== 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 --===============2011456677==-- From behave-bounces@ietf.org Wed Apr 25 21:15:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgsaS-0002cI-BF; Wed, 25 Apr 2007 21:15:56 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HgsaQ-0002c4-RF for behave-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 21:15:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgsaQ-0002bw-HR for behave@ietf.org; Wed, 25 Apr 2007 21:15:54 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgsaP-0005WR-BR for behave@ietf.org; Wed, 25 Apr 2007 21:15:54 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B20204002; Wed, 25 Apr 2007 21:15:52 -0400 (EDT) From: Sam Hartman To: Saikat Guha References: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> <1177466365.25477.8.camel@sioux.systems.cs.cornell.edu> <1177534111.32585.3.camel@sioux.systems.cs.cornell.edu> Date: Wed, 25 Apr 2007 21:15:52 -0400 In-Reply-To: <1177534111.32585.3.camel@sioux.systems.cs.cornell.edu> (Saikat Guha's message of "Wed, 25 Apr 2007 16:48:31 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: behave , Dan Wing Subject: [BEHAVE] Re: DISCUSS and COMMENT: draft-ietf-behave-tcp 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 That text is fine, although note it interacts badly with your other desire that when possible ports not be remapped. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 00:53: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 1Hgvyc-0006nk-Dc; Thu, 26 Apr 2007 00:53:06 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hgvya-0006ne-Tl for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 00:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgvya-0006nT-Js for behave@ietf.org; Thu, 26 Apr 2007 00:53:04 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgvyZ-0001U3-AU for behave@ietf.org; Thu, 26 Apr 2007 00:53:04 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 25 Apr 2007 21:53:03 -0700 X-IronPort-AV: i="4.14,452,1170662400"; d="scan'208"; a="770802762:sNHT44795576" 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 l3Q4r2lS023599; Wed, 25 Apr 2007 21:53:02 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l3Q4qvwo025666; Thu, 26 Apr 2007 04:52:57 GMT In-Reply-To: References: <462CDD8C.7060501@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] Re: Are NATs routers? Date: Wed, 25 Apr 2007 21:52:23 -0700 To: Jim Dixon X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1365; t=1177563182; x=1178427182; 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]=20Re=3A=20Are=20NATs=20routers? |Sender:=20; bh=BKfIbCj2Xea2hjLBngRg/EwMJNm2c4wt/AxlfIZsZbo=; b=FKmPNLNhRt+ewAOVCkaH/w/l4zssFoU9GNiefidRimkmYjrkQpJuqU4+UAfiLIMso3dPpbhX VBsgHSQRlfu8T0lCKDWZ+uPg0VpRMYLIWnTdV9CzrTDEv8AKa+U9WZmw; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Behave WG , Joe Touch 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 Apr 23, 2007, at 9:46 AM, Jim Dixon wrote: > I just googled on 'cisco nat' and got 1,630,000 > hits. The first sets out the use of NAT in IOS. Cisco thinks everything is a router - except the 1/2 of cisco that thinks everything is a switch - and the part that thinks everything is a Unified Communication Device - and I should not forget the large part that disagrees with all of the above.... I googled 'cisco dog' and got about the same number of hits. Cisco often call thing that take VoIP calls and puts them on the PSTN as routers - I get 1,780,000 hits for "cisco router voip". And linksys sell things they call routers that are not capable of speaking any IP routing protocol. The only conclusion I can come to is Cisco not exactly sure what they think a router is but they would be glad to sell you one - regardless of whatever it is you want a router to be. Anyways - I think that people use the term router to mean many things in many contexts. I assumed we were using it in terms of the RFC that seem most related to this but I understand the confusion now. So unless someone has a better canonical definition of what a router is, I propose we define it as a device that is compliant with RFC 1812 and be clear about what we mean by the term "router". Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 01:01: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 1Hgw6r-0006AV-09; Thu, 26 Apr 2007 01:01:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hgw6p-0006AP-Ry for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 01:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgw6p-0006AH-IP for behave@ietf.org; Thu, 26 Apr 2007 01:01:35 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgw6o-0004D0-9V for behave@ietf.org; Thu, 26 Apr 2007 01:01:35 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 25 Apr 2007 22:01:33 -0700 X-IronPort-AV: i="4.14,452,1170662400"; d="scan'208"; a="56347783:sNHT46804698" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3Q51X4M009484; Wed, 25 Apr 2007 22:01:33 -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 l3Q51WA9012937; Thu, 26 Apr 2007 05:01:33 GMT In-Reply-To: <80F3480A-35A2-44BA-9EF8-D4733AAE8858@magma.ca> References: <80F3480A-35A2-44BA-9EF8-D4733AAE8858@magma.ca> 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] Should NATs decrement the TTL field? Date: Wed, 25 Apr 2007 22:00:58 -0700 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=992; t=1177563693; x=1178427693; c=relaxed/simple; s=sjdkim5002; 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]=20Should=20NATs=20decrement=20the=20TTL=20fi eld? |Sender:=20; bh=FgUccsmS38yADygyFcpniHNS4CItBcR6YfCjFjBDt/c=; b=nyo+NtpMcIpjjgA+Xq7P2SX3Y+kNQ7Uigwygj8vhtJnCUYpmHf2mY8CGxns0CESBp3wJmIhn oXysOdQJr0fIKTyp9S/LNqvFp01rVwtvPaDrBweNJrPwwYmh2Ios9szp; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Behave WG , Joe Touch 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 Apr 24, 2007, at 6:06 AM, Philip Matthews wrote: > Does anyone see a good reason why a NAT _should not_ decrement the > TTL field > (other than the "try to be invisible" argument)? > Are there security implications to this question? I think so - an important security property is the properties described in the "Privacy and Topology Hiding" section of draft-ietf- v6ops-nap-06 (note this draft has been approved and will be an RFC soon). Requiring decrement of TTL would reveal internal topology information which is a big deal in cases where you are trying to hide if you are currently in europe of US for privacy reasons. Obviously lots of NATs are deployed where people don't care about topology hiding but this is a big concern in some deployments. I can't imagine how requiring that NATs do, or don't, decrement the TTL will help the P2PSIP stuff much but perhaps I am just not seeing the importance. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 07:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh2Wc-0003No-Tn; Thu, 26 Apr 2007 07:52:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hh2Wc-0003MX-8l for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 07:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh2Wb-0003MP-VY for behave@ietf.org; Thu, 26 Apr 2007 07:52:37 -0400 Received: from ik-out-1112.google.com ([66.249.90.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh2Wa-0003vq-Dy for behave@ietf.org; Thu, 26 Apr 2007 07:52:37 -0400 Received: by ik-out-1112.google.com with SMTP id c30so566639ika for ; Thu, 26 Apr 2007 04:52:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:x-accept-language:mime-version:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WFf+20dQL0/dNnMUquI7SugkwKpc/X/fqOpudqHKB9nFb72eJq5K+u90pCeEaJ7MasMlD9rPu0wXag73/0UdfGYhYRK/H0HrJUvXOzzSC/vy0+iXveDD+gUoqYt20HvY+qcx/fxzXKE+PrqahapKrea849csQzohHqM68Jev6pQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=di4wE/ciJIMrpXBLpfgidythbI4NEUGzplq5B/gS4J01rEHCN7HU380Rs9HVY7bMSOTsBnvjjjHTCWW4dlnIAXtOcnIj9mtQUk/+4Jv81MMgK2DIulQfA8hEqIe52qNkbtMc850fdG+Oxsz4GKbUXprXLuUswFRpBo+I1dTeoyo= Received: by 10.82.155.10 with SMTP id c10mr3139411bue.1177588355490; Thu, 26 Apr 2007 04:52:35 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTP id z40sm185419ikz.2007.04.26.04.52.15; Thu, 26 Apr 2007 04:52:25 -0700 (PDT) Message-ID: <46309266.20700@gmail.com> Date: Thu, 26 Apr 2007 21:52:06 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 CC: behave@ietf.org Subject: Re: [BEHAVE] Successful Responses in TURN References: <462B0FEE.7030701@gmail.com> <200704230745.29312.remi.denis-courmont@nokia.com> In-Reply-To: <200704230745.29312.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: >Since this is not explicitly specified, my understanding is that it sends a >normal successful Allocate response with 0 as lifetime. > > And what should the server set as a 'RELAY-ADDRESS'? Is it possible to omit this attribute in the deallocation responses since it doesn't matter in this case? >Considering the "base" STUN specification, a Request always gets either a >Response or an Error Response as an answer. > Could you point to the section of the STUN I-D where it is saying that Request _always_ (MUST?) gets a Response? I can't find it, really :) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 08:46: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 1Hh3Mv-00042X-Ft; Thu, 26 Apr 2007 08:46:41 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hh3Mt-00041a-Tu for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 08:46:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3Mt-0003zx-JU for behave@ietf.org; Thu, 26 Apr 2007 08:46:39 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh3Ms-00052l-Aq for behave@ietf.org; Thu, 26 Apr 2007 08:46:39 -0400 Received: by ug-out-1314.google.com with SMTP id 72so491921ugd for ; Thu, 26 Apr 2007 05:46:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=qnr3FRHNKyQ3DMvwlTZkguert0ZCcYBHyZZUAm1zJpGc8AAPukQ+xOuUfeB8fyL/5YEohvM7uyPuAwjQwZ1hv2bG5yA7N9lpy6qQ3BqZrdrqb+GV6462DgqMvkp7qKuww6AOTsLFN8HAAJaeM7CA/EhCRU9Ui+w1S4vYAaQse28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=qUz+Nizu+Vkw3C0T+drcKvnB+SxZYfylBqPU+Ivu7sTkf+USuQgH24fZ7EO8mBllNu2mj9cruQ+OLNtEc73f43uVnUc+B3AEyg7Cb4+yH1NHIRj4tLNc0ViKBeQSmfK3RIVtM+xIIiPs8zq3U0oWA21+kVs6qsLpQZ0tNNTWjR4= Received: by 10.82.169.4 with SMTP id r4mr3219618bue.1177591597392; Thu, 26 Apr 2007 05:46:37 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTP id y37sm22505iky.2007.04.26.05.46.20; Thu, 26 Apr 2007 05:46:31 -0700 (PDT) Message-ID: <46309F1C.3090005@gmail.com> Date: Thu, 26 Apr 2007 22:46:20 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [BEHAVE] TCP listen/connect in TURN 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 draft-ietf-behave-turn-03 para 4.1 says: "For TCP connections, the Connection Request allows the client to ask the server to open a connection to the peer. This also adds a permission to accept an incoming TCP connection from the remote address of the peer." AFAIK, it is not possible to accept()/connect() on/from the same port simultaneously (at least with Berkley sockets). I just wonder how to implement such behavior of the TURN server? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 11:02:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5UV-0008Pk-69; Thu, 26 Apr 2007 11:02:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hh5UU-0008Pf-7m for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 11:02:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5UT-0008PX-UT for behave@ietf.org; Thu, 26 Apr 2007 11:02:37 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh5US-0004rZ-Gj for behave@ietf.org; Thu, 26 Apr 2007 11:02:37 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 26 Apr 2007 08:02:36 -0700 X-IronPort-AV: i="4.14,455,1170662400"; d="scan'208"; a="56453075:sNHT51444963" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3QF2ZL7012870; Thu, 26 Apr 2007 08:02:35 -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 l3QF2ZA9011808; Thu, 26 Apr 2007 15:02:35 GMT In-Reply-To: <894e079b0704240840hd999dd6ka215145cac591907@mail.gmail.com> References: <462E1FA5.5090204@isi.edu> <894e079b0704240840hd999dd6ka215145cac591907@mail.gmail.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] Should NATs decrement the TTL field? Date: Wed, 25 Apr 2007 22:05:45 -0700 To: Medhavi Bhatia X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3840; t=1177599755; x=1178463755; c=relaxed/simple; s=sjdkim8002; 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]=20Should=20NATs=20decrement=20the=20TTL=20fi eld? |Sender:=20; bh=2DHI3h+MLUDMPzck3cCSt8dU8bh0dW8oc0Gjg35IScI=; b=Tp2QCtz+5elk5lgROMKOQcvuj0yKncaN++WCNygSwgWUMZybFViUUbpT5R3jLYW5vXODv8fg qs1CwqzJRrXTaNZQj0CIxSWqB+F6230CEViOWees4hwukVp3BM9tAuVS; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Behave WG , Philip Matthews , Joe Touch 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 seen this loop argument before and I seem to recall the conclusion of it was as long a NATs don't increment the TTL when going from the public side to private side, that the TTL will still stop all loops. I might be wrong. Cullen PS - what Joe said about modeling NATs as generally looking like host on outside and router on inside seemed like a good guideline to try and figure out what they should do. On Apr 24, 2007, at 8:40 AM, Medhavi Bhatia wrote: > Joe, I agree with rationale you are using here, but I am not sure > NATs were really understood well around the time endpoints and > router behavior was defined. TTL is for preventing loops. For all > practical purposes NATs are middleboxes and hence not the ultimate > destination of the packets. So if we agree with that then they must > decrement TTL or manage it in a way to prevent loops. > > On 4/24/07, Joe Touch wrote: > > Dave Hudson wrote: > > * -----Original Message----- > > * From: Philip Matthews [mailto:philip_matthews@magma.ca] > > * Sent: 24 April 2007 14:07 > > * To: Behave WG > > * Cc: Joe Touch > > * Subject: [BEHAVE] Should NATs decrement the TTL field? > > * > > * In my current thinking, NATs are invisible to the extent that > > * routers are invisible: > > * most applications do not need to know they are there, but > > * some applications do and all applications need to be prepared > > * to accept ICMP messages from them. > > > > NATs in most non-enterprise uses usually can't be invisible on the > > private side ... > > Folks, > > We really need to distinguish between what SOME NATs do (or can do) > and > what ALL NATs MUST do. > > The MUSTs define what it is to be a NAT, a router, or a host. > Everything > else is interesting, but not relevant IMO. > > --- > > Further, this underscores my position that what a NAT is depends on > what > side you're looking at. From the public side, IMO they're hosts. From > the private side, IMO, they're routers. IMO, that actually provides a > reasonable definition of what a NAT is. > > To that end, ICMP code 13's could rightly be sent back to private-side > hosts, but that side is almost never interesting. It's the public side > behavior we need to determine, and IMO that's entirely already > specified > by RFC1122. > > > * So I current think a NAT _should_ decrement the TTL field > > * (though I am willing to be convinced otherwise ...). > > * > > * Note that this implies that a NAT needs to generate an ICMP > > * "Time Exceeded" > > * message when the TTL reaches 0, and also implies that a NAT > > * will show up in a traceroute. > > > > This is the behaviour of pretty-much every low-end NAT I've ever > seen > > The key question is "what should a host do when this happens". Hosts > don't decrement the TTL; they just receive the packet. > TIME_EXCEEDED is > not the appropriate response. > > This isn't a clue that NATs are routers, but rather that they are > already visible to the rest of the Internet in ways that many don't > want > to believe. > > ... > > I can't imagine any OEM I've dealt with not wanting a NAT to show > up in > > a traceroute since they tend to want to use this to diagnose > > connectivity problems. > > Agreed - from the inside, not from the outside. > > Joe > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > > _______________________________________________ > 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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 15:49:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9y4-0005oc-3r; Thu, 26 Apr 2007 15:49:28 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hh9y2-0005XE-GP for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 15:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9y1-0005RI-Uk for behave@ietf.org; Thu, 26 Apr 2007 15:49:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh9xz-0005Dt-Uo for behave@ietf.org; Thu, 26 Apr 2007 15:49:25 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2007 12:49:22 -0700 X-IronPort-AV: i="4.14,457,1170662400"; d="scan'208"; a="141052490:sNHT42429087" 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 l3QJnMMP003004; Thu, 26 Apr 2007 12:49:22 -0700 Received: from dwingwxp (dhcp-128-107-114-150.cisco.com [128.107.114.150]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3QJnMMF012911; Thu, 26 Apr 2007 19:49:22 GMT From: "Dan Wing" To: "'Evgeniy Khramtsov'" , "'Behave WG'" Subject: RE: [BEHAVE] TCP listen/connect in TURN Date: Thu, 26 Apr 2007 12:49:22 -0700 Message-ID: <08a801c7883b$fcaea360$05716b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceIAPVKdHcIi5sLQoyydPJbBtak4QAOqy8A In-Reply-To: <46309F1C.3090005@gmail.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=970; t=1177616962; x=1178480962; 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[BEHAVE]=20TCP=20listen/connect=20in=20TURN |Sender:=20; bh=E3Duvj5uSA2Om1ygThKO1be+OwPuNTQqTpMw4c+wVDw=; b=hjk1597LcyMhHAdMj8sY6pfZEZUtOHolHWF5IrnBvEdWmoklntGnlUrG0CjREo3/wJcw0Icw VF+7GUoDMhZY0xj5zuQ8GLneM4SDV62srG+1RrpG11VZlnQ0xO8RdGzV+KYBflnVL7V8FLZmon Z6bJcwTefoYkSDbx9I86enXiI=; 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: 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 You should just need to connect() -- TCP simultaneous open will handle the case where the SYNs cross (see figure 10 in RFC761). -d > -----Original Message----- > From: Evgeniy Khramtsov [mailto:xramtsov@gmail.com] > Sent: Thursday, April 26, 2007 5:46 AM > To: Behave WG > Subject: [BEHAVE] TCP listen/connect in TURN > > draft-ietf-behave-turn-03 para 4.1 says: > > "For TCP connections, the Connection Request allows the client to ask > the server to open a connection to the peer. This also adds a > permission > to accept an incoming TCP connection from the remote address > of the peer." > > AFAIK, it is not possible to accept()/connect() on/from the same port > simultaneously (at least with Berkley sockets). I just wonder how to > implement such behavior of the TURN server? > > > _______________________________________________ > 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 Thu Apr 26 17:12:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBGU-0007PD-61; Thu, 26 Apr 2007 17:12:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhBGT-0007NR-Gr for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:12:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBGT-0007NJ-6C for behave@ietf.org; Thu, 26 Apr 2007 17:12:33 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhBGR-0007Nj-Qi for behave@ietf.org; Thu, 26 Apr 2007 17:12:33 -0400 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 17:12:31 -0400 Received: from [192.168.11.3] ([24.59.192.172]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 17:12:30 -0400 Subject: Re: [BEHAVE] TCP listen/connect in TURN From: Saikat Guha To: Evgeniy Khramtsov In-Reply-To: <46309F1C.3090005@gmail.com> References: <46309F1C.3090005@gmail.com> Organization: Cornell University Date: Thu, 26 Apr 2007 17:12:31 -0400 Message-Id: <1177621951.15291.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 26 Apr 2007 21:12:30.0595 (UTC) FILETIME=[99B17D30:01C78847] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Content-Type: multipart/mixed; boundary="===============0484038282==" Errors-To: behave-bounces@ietf.org --===============0484038282== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZqNbzojgFuYFhX8I1vJT" --=-ZqNbzojgFuYFhX8I1vJT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-04-26 at 22:46 +1000, Evgeniy Khramtsov wrote: > AFAIK, it is not possible to accept()/connect() on/from the same port=20 > simultaneously (at least with Berkley sockets). I just wonder how to=20 > implement such behavior of the TURN server? Actually, it is possible. Perhaps a bug or undocumented feature, but it works on Linux and Windows for sure, OSX as well I believe and by extension on BSD too. 1: a =3D socket() 2: c =3D socket() 3: setsockopt(a, SO_REUSEADDR) 4: bind(a, port) 5: setsockopt(b, SO_REUSEADDR) 6: bind(c, port) 7: listen(a) 8: connect(c, remote) The above sequence succeeds and does what is expected. Interestingly, swapping lines 6 and 7 doesn't work; neither does swapping lines 7 and 8 IIRC. Calling listen(c) in line 8 doesn't work, but that's expected. Having and additional socket c2 with bind(c2, port) before line 7 and connect(c2, remote2) after line 7 also works. For current OSs, as long as: 1. All sockets are bound to the local port before listen/connect is called on any one of them. 2. Listen is called on at most one socket and is called before all connect's It all works. --=20 Saikat --=-ZqNbzojgFuYFhX8I1vJT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGMRW/nFltqi691/oRAgLeAJ0Q4P6zEsKXB1eB2O0+buipjj41FQCcCCdM m6n2YT90HYD97gAi281PDtg= =W/qH -----END PGP SIGNATURE----- --=-ZqNbzojgFuYFhX8I1vJT-- --===============0484038282== 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 --===============0484038282==-- From behave-bounces@ietf.org Thu Apr 26 17:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBKy-0001UL-GQ; Thu, 26 Apr 2007 17:17:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhBKx-0001UF-G4 for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBKx-0001U7-6Z for behave@ietf.org; Thu, 26 Apr 2007 17:17:11 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhBKv-0007wG-Pw for behave@ietf.org; Thu, 26 Apr 2007 17:17:11 -0400 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 17:17:09 -0400 Received: from [192.168.11.3] ([24.59.192.172]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 17:17:08 -0400 Subject: RE: [BEHAVE] TCP listen/connect in TURN From: Saikat Guha To: Dan Wing In-Reply-To: <08a801c7883b$fcaea360$05716b80@amer.cisco.com> References: <08a801c7883b$fcaea360$05716b80@amer.cisco.com> Organization: Cornell University Date: Thu, 26 Apr 2007 17:17:12 -0400 Message-Id: <1177622232.15291.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 26 Apr 2007 21:17:08.0595 (UTC) FILETIME=[3F64EC30:01C78848] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Content-Type: multipart/mixed; boundary="===============2122450648==" Errors-To: behave-bounces@ietf.org --===============2122450648== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xu746lx07H4EB7+N+SFv" --=-xu746lx07H4EB7+N+SFv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-04-26 at 12:49 -0700, Dan Wing wrote: > You should just need to connect() -- TCP simultaneous open will handle th= e > case where the SYNs cross (see figure 10 in RFC761). If the remote NAT does not have endpoint independent mappings (non-BEHAVE compliant NAT) but the local NAT has either endpoint independent or address dependent filtering (both BEHAVE recommended) then ... calling just connect() and waiting for TCP S-O will not work since the remote side will be using a different address/port tuple than what the local side expects. however, calling both listen() and connect() will work. connect() will punch the hole for the remote address. The remote SYN will come in (passing the address dependent filtering test). It'll be ignored by the socket which connect() was called on (5-tuple mismatch), but will be picked up by the socket listen() was called on (destination addr/port matches local binding). --=20 Saikat --=-xu746lx07H4EB7+N+SFv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGMRbYnFltqi691/oRAmbSAJ0Th/4X2iwg9D+w/EuD89CRexVSOgCfahH7 BIEEt03lUSxf9GL7S0PBUr0= =rS5o -----END PGP SIGNATURE----- --=-xu746lx07H4EB7+N+SFv-- --===============2122450648== 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 --===============2122450648==-- From behave-bounces@ietf.org Thu Apr 26 17:45: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 1HhBml-0008Vs-BP; Thu, 26 Apr 2007 17:45:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhBmk-0008Rv-EC for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:45:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBmk-0008Q1-3K for behave@ietf.org; Thu, 26 Apr 2007 17:45:54 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhBmi-0004Yb-S1 for behave@ietf.org; Thu, 26 Apr 2007 17:45:54 -0400 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 17:45:52 -0400 Received: from [192.168.11.3] ([24.59.192.172]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 17:45:51 -0400 From: Saikat Guha To: Sam Hartman In-Reply-To: References: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> <1177466365.25477.8.camel@sioux.systems.cs.cornell.edu> <1177534111.32585.3.camel@sioux.systems.cs.cornell.edu> Organization: Cornell University Date: Thu, 26 Apr 2007 17:45:54 -0400 Message-Id: <1177623954.15291.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 26 Apr 2007 21:45:51.0813 (UTC) FILETIME=[42831F50:01C7884C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: behave , Dan Wing Subject: [BEHAVE] Re: DISCUSS and COMMENT: draft-ietf-behave-tcp 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="===============1067904422==" Errors-To: behave-bounces@ietf.org --===============1067904422== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-P0tlwGfLEZ7vAHEWXwNN" --=-P0tlwGfLEZ7vAHEWXwNN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-04-25 at 21:15 -0400, Sam Hartman wrote: > That text is fine, although note it interacts badly with your other > desire that when possible ports not be remapped. Not sure I understood the last part (about remapping). In the naive implementation suggested in the previous mail, the NAT functionality is completely isolated from endhost functionality by partitioning the port space. Inside the NAT port space, it can be BEHAVE compliant. e.g. when the same NAT'ed host uses the same local port for multiple connections, the same mapped port must be used (with the added constraint now that the port lies in the port space partition used by the NAT).=20 --=20 Saikat --=-P0tlwGfLEZ7vAHEWXwNN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGMR2SnFltqi691/oRAuuTAJ4wDZNPrBzBZnjQyDYpaz0F+9CivQCfXjtO DsncMFQmF6cPxwELmJ2iMUY= =yOBk -----END PGP SIGNATURE----- --=-P0tlwGfLEZ7vAHEWXwNN-- --===============1067904422== 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 --===============1067904422==-- From behave-bounces@ietf.org Thu Apr 26 18:03: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 1HhC3w-0002Ls-1c; Thu, 26 Apr 2007 18:03:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhC3v-0002JF-4e for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 18:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhC3u-0002HY-Qw for behave@ietf.org; Thu, 26 Apr 2007 18:03:38 -0400 Received: from ns2.dixons.org ([217.147.86.2] helo=post.planetlink.ltd.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhC3t-00088X-IX for behave@ietf.org; Thu, 26 Apr 2007 18:03:38 -0400 Received: from 82-32-46-174.cable.ubr06.azte.blueyonder.co.uk ([82.32.46.174] helo=westbury.dixons.org) by post.planetlink.ltd.uk with esmtp (Exim 4.50) id 1HhC3l-0006aY-2u; Thu, 26 Apr 2007 23:03:29 +0100 Received: from jdd (helo=localhost) by westbury.dixons.org with local-esmtp (Exim 4.50) id 1HhC3H-0003YQ-Rv; Thu, 26 Apr 2007 23:02:59 +0100 Date: Thu, 26 Apr 2007 23:02:59 +0100 (BST) From: Jim Dixon To: Cullen Jennings Subject: Re: [BEHAVE] Re: Are NATs routers? In-Reply-To: <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> Message-ID: References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Behave WG , Joe Touch 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 Wed, 25 Apr 2007, Cullen Jennings wrote: > > I just googled on 'cisco nat' and got 1,630,000 > > hits. The first sets out the use of NAT in IOS. > > Cisco thinks everything is a router - except the 1/2 of cisco that Juniper also routinely does NAT. Everybody does NAT. This conversation follows from a statement that routers never do address translation, which is simply nonsense. It's not true. It's false. Routers do network address translation every day, everywhere. It is sensible to talk about where routing functionality or switching functionality or NAT resides in a system such as a router. But to assert that the boxes everyone spends so much money on are not routers is absurd. It says 'router' on the box, it says 'router' on the purchase order, it says 'router' on the inventory. It's a router. Does anyone have a router than _doesn't_ do NAT? -- Jim Dixon jddixon@gmail.com cellphone 415 / 570 3608 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 18:56: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 1HhCsx-0006JA-0b; Thu, 26 Apr 2007 18:56:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhCsv-0006J4-2s for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 18:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCsu-0006Iw-Pb for behave@ietf.org; Thu, 26 Apr 2007 18:56:20 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhCst-0001ZQ-GQ for behave@ietf.org; Thu, 26 Apr 2007 18:56:20 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 55DEB33C1A; Thu, 26 Apr 2007 15:56:28 -0700 (PDT) Date: Thu, 26 Apr 2007 15:56:28 -0700 From: Eric Rescorla To: Jim Dixon Subject: Re: [BEHAVE] Re: Are NATs routers? In-Reply-To: References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070426225628.55DEB33C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Behave WG , Joe Touch 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 At Thu, 26 Apr 2007 23:02:59 +0100 (BST), Jim Dixon wrote: > > On Wed, 25 Apr 2007, Cullen Jennings wrote: > > > > I just googled on 'cisco nat' and got 1,630,000 > > > hits. The first sets out the use of NAT in IOS. > > > > Cisco thinks everything is a router - except the 1/2 of cisco that > > Juniper also routinely does NAT. Everybody does NAT. > > This conversation follows from a statement that routers never do > address translation, which is simply nonsense. It's not true. It's > false. Routers do network address translation every day, everywhere. > > It is sensible to talk about where routing functionality or switching > functionality or NAT resides in a system such as a router. But to > assert that the boxes everyone spends so much money on are not routers > is absurd. It says 'router' on the box, it says 'router' on the > purchase order, it says 'router' on the inventory. It's a router. > > Does anyone have a router than _doesn't_ do NAT? I'm sure I'm going to regret jumping in here, but... I think you're confusing the device's capabilities with the role it plays in the network. To take a concrete example, I'm typing this on a FreeBSD box with two NICs, one wireless and one wireline. It not forwarding between those interfaces now, but making it do so is a simple matter of setting a sysctl, at which point you would have every right to expect it to obey 1812. Is it a router or not? I assure you it doesn't say so on the box. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 19:00: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 1HhCwf-0000xK-KN; Thu, 26 Apr 2007 19:00:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhCwe-0000vD-Er for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 19:00:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCwe-0000v0-5G for behave@ietf.org; Thu, 26 Apr 2007 19:00:12 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhCwa-0002KB-FY for behave@ietf.org; Thu, 26 Apr 2007 19:00:12 -0400 Received: from Quinthar ([75.7.24.197]) by quinthar.com for ; Thu, 26 Apr 2007 16:00:03 -0700 From: "David Barrett" To: "'IETF BEHAVE WG'" Date: Thu, 26 Apr 2007 16:00:02 -0700 Message-ID: <006301c78856$9fb961c0$7101a8c0@Quinthar> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceIVp385Xy6wbVhRKWJWwNt+Anfvg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: [BEHAVE] Source-port randomzation in Linux 2.6.21 release 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="===============0301556812==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0301556812== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C7881B.F35A89C0" This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C7881B.F35A89C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I saw the announcement that Linux 2.6.21 kernel has been released: http://kernelnewbies.org/Linux_2_6_21 One thing that stuck out in the changelist was "NAT port randomization", which was described later as "optional source port randomization support for SNAT". However, I haven't found a more accessible explanation for this. Can anybody explain what this is? It sounds an awful lot like endpoint-dependent mapping (aka, symmetric NAT), which I believe isn't BEHAVE compliant. Should we talk with the NetFilter guys to let them know this and thus recommend that this new option not be used? -david ------=_NextPart_000_0064_01C7881B.F35A89C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I saw the announcement that Linux 2.6.21 kernel has = been released:

 

http://kernelnewbies.org/L= inux_2_6_21

 

One thing that stuck out in the changelist was = “NAT port randomization”, which was described later as “optional = source port randomization support for SNAT”.  However, I = haven’t found a more accessible explanation for this.  =

 

Can anybody explain what this is?  It sounds an = awful lot like endpoint-dependent mapping (aka, symmetric NAT), which I believe = isn’t BEHAVE compliant.  Should we talk with the NetFilter guys to let = them know this and thus recommend that this new option not be = used?

 

-david

 

 

------=_NextPart_000_0064_01C7881B.F35A89C0-- --===============0301556812== 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 --===============0301556812==-- From behave-bounces@ietf.org Thu Apr 26 19:11: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 1HhD7D-0004q0-E3; Thu, 26 Apr 2007 19:11:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhD7C-0004pv-0l for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 19:11:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhD7B-0004pm-NS for behave@ietf.org; Thu, 26 Apr 2007 19:11:05 -0400 Received: from ns2.dixons.org ([217.147.86.2] helo=post.planetlink.ltd.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhD7A-0004eI-BA for behave@ietf.org; Thu, 26 Apr 2007 19:11:05 -0400 Received: from 82-32-46-174.cable.ubr06.azte.blueyonder.co.uk ([82.32.46.174] helo=westbury.dixons.org) by post.planetlink.ltd.uk with esmtp (Exim 4.50) id 1HhD78-0006wh-3f; Fri, 27 Apr 2007 00:11:02 +0100 Received: from jdd (helo=localhost) by westbury.dixons.org with local-esmtp (Exim 4.50) id 1HhD6f-0003bU-KN; Fri, 27 Apr 2007 00:10:33 +0100 Date: Fri, 27 Apr 2007 00:10:33 +0100 (BST) From: Jim Dixon To: Eric Rescorla Subject: Re: [BEHAVE] Re: Are NATs routers? In-Reply-To: <20070426225628.55DEB33C1A@delta.rtfm.com> Message-ID: References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> <20070426225628.55DEB33C1A@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Thu, 26 Apr 2007, Eric Rescorla wrote: > > Juniper also routinely does NAT. Everybody does NAT. > > > > This conversation follows from a statement that routers never do > > address translation, which is simply nonsense. It's not true. It's > > false. Routers do network address translation every day, everywhere. > > > > It is sensible to talk about where routing functionality or switching > > functionality or NAT resides in a system such as a router. But to > > assert that the boxes everyone spends so much money on are not routers > > is absurd. It says 'router' on the box, it says 'router' on the > > purchase order, it says 'router' on the inventory. It's a router. > > > > Does anyone have a router than _doesn't_ do NAT? > > I'm sure I'm going to regret jumping in here, but... > > I think you're confusing the device's capabilities with the role it > plays in the network. To take a concrete example, I'm typing this on a > FreeBSD box with two NICs, one wireless and one wireline. It not > forwarding between those interfaces now, but making it do so is a > simple matter of setting a sysctl, at which point you would have every > right to expect it to obey 1812. Is it a router or not? I assure you > it doesn't say so on the box. To say that an elephant is a mammal is not to say that all mammals are elephants. Your FreeBSD box is capable of routing. It is also capable of doing network address translation. (I have exactly this setup at home in the UK, BTW - a PC with a cable connection on one side and a couple of home networks on the other. It routes traffic and also does NAT.) But it's not a dedicated router and it's not being used as such. The question here is whether all of these gazillions of machines which are bought and sold as routers are actually such. The claim is that if they do NAT they cannot be called routers - even though that's exactly what everyone calls them. A long time ago some US state legislature decided that it would be more convenient if pi had a value of 3 and legislated accordingly. Another futile gesture ;-) -- Jim Dixon jddixon@gmail.com cellphone 415 / 570 3608 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 19:12: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 1HhD8c-0006Lh-7r; Thu, 26 Apr 2007 19:12:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhD8b-0006Lc-FZ for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 19:12:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhD8b-0006LU-65 for behave@ietf.org; Thu, 26 Apr 2007 19:12:33 -0400 Received: from buggy.corp.yahoo.com ([207.126.225.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhD8Z-0004te-SH for behave@ietf.org; Thu, 26 Apr 2007 19:12:33 -0400 Received: (from lloydh@localhost) by buggy.corp.yahoo.com (8.12.3/8.12.3) id l3QNCVAG048716; Thu, 26 Apr 2007 16:12:31 -0700 (PDT) (envelope-from lloydh) Date: Thu, 26 Apr 2007 16:12:31 -0700 From: Lloyd Hilaiel To: David Barrett Subject: Re: [BEHAVE] Source-port randomzation in Linux 2.6.21 release Message-ID: <20070426231230.GE84280@buggy.corp.yahoo.com> References: <006301c78856$9fb961c0$7101a8c0@Quinthar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006301c78856$9fb961c0$7101a8c0@Quinthar> User-Agent: Mutt/1.4.2.1i X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'IETF 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 /-- Around 4 PM on [04/26/07] (dbarrett@quinthar.com) "said" -- >One thing that stuck out in the changelist was "NAT port randomization", >which was described later as "optional source port randomization support for >SNAT". However, I haven't found a more accessible explanation for this. > >Can anybody explain what this is? It sounds an awful lot like >endpoint-dependent mapping (aka, symmetric NAT), which I believe isn't >BEHAVE compliant. Should we talk with the NetFilter guys to let them know >this and thus recommend that this new option not be used? sounds more to me like random port allocation behavior, but is orthogonal to port mapping behavior. Meaning a NAT may be "full cone" and still allocate new ports randomly... +#define IP_NAT_RANGE_PROTO_RANDOM 4 /* add randomness to "port" selection */ + /* Start from random port to avoid prediction */ + if (range->flags & IP_NAT_RANGE_PROTO_RANDOM) + port = net_random(); + best, lloyd -- lloydh@yahoo-inc.com | on taken thrive granted be never http://docs.yahoo.com/info/values/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 19:14: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 1HhDAc-000054-Sb; Thu, 26 Apr 2007 19:14:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhDAc-00004z-Ef for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 19:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhDAc-00004r-5E for behave@ietf.org; Thu, 26 Apr 2007 19:14:38 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhDAa-0005Pm-Sc for behave@ietf.org; Thu, 26 Apr 2007 19:14:38 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E5B4B33C1A; Thu, 26 Apr 2007 16:14:45 -0700 (PDT) Date: Thu, 26 Apr 2007 16:14:45 -0700 From: Eric Rescorla To: Jim Dixon Subject: Re: [BEHAVE] Re: Are NATs routers? In-Reply-To: References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> <20070426225628.55DEB33C1A@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070426231445.E5B4B33C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 At Fri, 27 Apr 2007 00:10:33 +0100 (BST), Jim Dixon wrote: > On Thu, 26 Apr 2007, Eric Rescorla wrote: > > I think you're confusing the device's capabilities with the role it > > plays in the network. To take a concrete example, I'm typing this on a > > FreeBSD box with two NICs, one wireless and one wireline. It not > > forwarding between those interfaces now, but making it do so is a > > simple matter of setting a sysctl, at which point you would have every > > right to expect it to obey 1812. Is it a router or not? I assure you > > it doesn't say so on the box. > > To say that an elephant is a mammal is not to say that all mammals are > elephants. Your FreeBSD box is capable of routing. It is also capable > of doing network address translation. (I have exactly this setup at > home in the UK, BTW - a PC with a cable connection on one side and a > couple of home networks on the other. It routes traffic and also does > NAT.) But it's not a dedicated router and it's not being used as such. I've used FreeBSD boxes as dedicated routers plenty of times. > The question here is whether all of these gazillions of machines which > are bought and sold as routers are actually such. The claim is that > if they do NAT they cannot be called routers - even though that's exactly > what everyone calls them. No. The claim here is that if they are *configured* as NATs then they do not need to comply with RFC 1812. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 19:15: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 1HhDAy-00008y-45; Thu, 26 Apr 2007 19:15:00 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhDAw-00008s-SP for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 19:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhDAw-00008k-Iz for behave@ietf.org; Thu, 26 Apr 2007 19:14:58 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhDAu-0005S1-Il for behave@ietf.org; Thu, 26 Apr 2007 19:14:57 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 41F7D3A02022; Thu, 26 Apr 2007 16:14:56 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 6FED73A02021; Thu, 26 Apr 2007 16:14:54 -0700 (PDT) Message-ID: <4631326E.1070602@acm.org> Date: Thu, 26 Apr 2007 16:14:54 -0700 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.10 (X11/20070328) MIME-Version: 1.0 To: Jim Dixon Subject: Re: [BEHAVE] Re: Are NATs routers? References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Behave WG , Joe Touch 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 Jim Dixon wrote: > On Wed, 25 Apr 2007, Cullen Jennings wrote: > >>> I just googled on 'cisco nat' and got 1,630,000 >>> hits. The first sets out the use of NAT in IOS. >> Cisco thinks everything is a router - except the 1/2 of cisco that > > Juniper also routinely does NAT. Everybody does NAT. > > This conversation follows from a statement that routers never do > address translation, which is simply nonsense. It's not true. It's > false. Routers do network address translation every day, everywhere. > > It is sensible to talk about where routing functionality or switching > functionality or NAT resides in a system such as a router. But to > assert that the boxes everyone spends so much money on are not routers > is absurd. It says 'router' on the box, it says 'router' on the > purchase order, it says 'router' on the inventory. It's a router. > > Does anyone have a router than _doesn't_ do NAT? Yes, this model does not do NAT: http://www.amazon.com/DEWALT-DW616-Heavy-Fixed-Router/dp/B00006JKX9/ref=pd_bbs_5/102-7320701-6896967?ie=UTF8&s=hi&qid=1177628771&sr=8-5 Well, it says router on the box. -- 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 Apr 26 19:19: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 1HhDF4-0005iR-F1; Thu, 26 Apr 2007 19:19:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhDF2-0005iM-F5 for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 19:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhDF2-0005iC-5R for behave@ietf.org; Thu, 26 Apr 2007 19:19:12 -0400 Received: from ns2.dixons.org ([217.147.86.2] helo=post.planetlink.ltd.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhDF0-0006Dn-Te for behave@ietf.org; Thu, 26 Apr 2007 19:19:12 -0400 Received: from 82-32-46-174.cable.ubr06.azte.blueyonder.co.uk ([82.32.46.174] helo=westbury.dixons.org) by post.planetlink.ltd.uk with esmtp (Exim 4.50) id 1HhDEy-0006zL-Mh; Fri, 27 Apr 2007 00:19:08 +0100 Received: from jdd (helo=localhost) by westbury.dixons.org with local-esmtp (Exim 4.50) id 1HhDEW-0003cs-9S; Fri, 27 Apr 2007 00:18:40 +0100 Date: Fri, 27 Apr 2007 00:18:40 +0100 (BST) From: Jim Dixon To: Marc Petit-Huguenin Subject: Re: [BEHAVE] Re: Are NATs routers? In-Reply-To: <4631320C.6010105@petit-huguenin.org> Message-ID: References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> <4631320C.6010105@petit-huguenin.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Thu, 26 Apr 2007, Marc Petit-Huguenin wrote: > > Does anyone have a router than _doesn't_ do NAT? > > Yes, this model does not do NAT: > > http://www.amazon.com/DEWALT-DW616-Heavy-Fixed-Router/dp/B00006JKX9/ref=pd_bbs_5/102-7320701-6896967?ie=UTF8&s=hi&qid=1177628771&sr=8-5 > > Well, it says router on the box. I experimented and found that if you put a network address on a piece of paper under this router, it will translate it into tiny little bits of paper. Unfortunately the translation is fairly random. :-| -- Jim Dixon jddixon@gmail.com cellphone 415 / 570 3608 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 19:33: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 1HhDT1-0007Nn-75; Thu, 26 Apr 2007 19:33:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhDT0-0007Ni-FM for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 19:33:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhDT0-0007Na-5v for behave@ietf.org; Thu, 26 Apr 2007 19:33:38 -0400 Received: from ns2.dixons.org ([217.147.86.2] helo=post.planetlink.ltd.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhDSy-0008AO-TH for behave@ietf.org; Thu, 26 Apr 2007 19:33:38 -0400 Received: from 82-32-46-174.cable.ubr06.azte.blueyonder.co.uk ([82.32.46.174] helo=westbury.dixons.org) by post.planetlink.ltd.uk with esmtp (Exim 4.50) id 1HhDSw-00076a-R8; Fri, 27 Apr 2007 00:33:34 +0100 Received: from jdd (helo=localhost) by westbury.dixons.org with local-esmtp (Exim 4.50) id 1HhDSU-0003ds-JY; Fri, 27 Apr 2007 00:33:06 +0100 Date: Fri, 27 Apr 2007 00:33:06 +0100 (BST) From: Jim Dixon To: Eric Rescorla Subject: Re: [BEHAVE] Re: Are NATs routers? In-Reply-To: <20070426231445.E5B4B33C1A@delta.rtfm.com> Message-ID: References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> <20070426225628.55DEB33C1A@delta.rtfm.com> <20070426231445.E5B4B33C1A@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Thu, 26 Apr 2007, Eric Rescorla wrote: > I've used FreeBSD boxes as dedicated routers plenty of times. As have I. So? > > The question here is whether all of these gazillions of machines which > > are bought and sold as routers are actually such. The claim is that > > if they do NAT they cannot be called routers - even though that's exactly > > what everyone calls them. > > No. The claim here is that if they are *configured* as NATs then they > do not need to comply with RFC 1812. The claim which got me involved in this conversation was: --------------------------------------------------------------- > NATs translate IP headers; that's something routers never do. --------------------------------------------------------------- It's a simple claim. And it's simply wrong. To me, if you use a FreeBSD machine as a router, well then it's a router. The fact that it also does network address translation doesn't change this at all. It routes, so it's a router. I have had arguments with people about this and can generally understand the other side's position. They want to restrict the use of the term 'router' to dedicated bits of hardware that are sold as routers and used as such. However, the argument on this list has been much more extreme: that all of these boxes sold as and bought as routers aren't routers, even though the manufacturers, the operators, and everyone else thinks that they are. -- Jim Dixon jddixon@gmail.com cellphone 415 / 570 3608 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 19:44: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 1HhDdO-0002xt-N1; Thu, 26 Apr 2007 19:44:22 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhDdN-0002sL-HB for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 19:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhDdN-0002qc-75 for behave@ietf.org; Thu, 26 Apr 2007 19:44:21 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhDdL-0001IZ-Rz for behave@ietf.org; Thu, 26 Apr 2007 19:44:21 -0400 Received: from Quinthar ([75.7.24.197]) by quinthar.com for ; Thu, 26 Apr 2007 16:44:17 -0700 From: "David Barrett" To: "'Lloyd Hilaiel'" Subject: RE: [BEHAVE] Source-port randomzation in Linux 2.6.21 release Date: Thu, 26 Apr 2007 16:44:17 -0700 Message-ID: <008001c7885c$ce39c610$7101a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070426231230.GE84280@buggy.corp.yahoo.com> Thread-Index: AceIWRubpMFbm+SXTJ6kEt7qRJXH+AAA6nWQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'IETF 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, that's no problem then. Thanks for clarifying. > -----Original Message----- > From: Lloyd Hilaiel [mailto:lloydh@yahoo-inc.com] > Sent: Thursday, April 26, 2007 4:13 PM > To: David Barrett > Cc: 'IETF BEHAVE WG' > Subject: Re: [BEHAVE] Source-port randomzation in Linux 2.6.21 release > > /-- Around 4 PM on [04/26/07] (dbarrett@quinthar.com) "said" -- > >One thing that stuck out in the changelist was "NAT port randomization", > >which was described later as "optional source port randomization support > for > >SNAT". However, I haven't found a more accessible explanation for this. > > > >Can anybody explain what this is? It sounds an awful lot like > >endpoint-dependent mapping (aka, symmetric NAT), which I believe isn't > >BEHAVE compliant. Should we talk with the NetFilter guys to let them > know > >this and thus recommend that this new option not be used? > > sounds more to me like random port allocation behavior, but is > orthogonal to port mapping behavior. Meaning a NAT may be "full > cone" and still allocate new ports randomly... > > +#define IP_NAT_RANGE_PROTO_RANDOM 4 /* add randomness to "port" selection > */ > > + /* Start from random port to avoid prediction */ > + if (range->flags & IP_NAT_RANGE_PROTO_RANDOM) > + port = net_random(); > + > > best, > lloyd > > -- > lloydh@yahoo-inc.com | on taken thrive granted be never > http://docs.yahoo.com/info/values/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 26 21:29: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 1HhFHO-0007xB-Ct; Thu, 26 Apr 2007 21:29:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhFHN-0007x5-BY for behave-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 21:29:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhFHN-0007wx-20 for behave@ietf.org; Thu, 26 Apr 2007 21:29:45 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhFHL-0002so-Rx for behave@ietf.org; Thu, 26 Apr 2007 21:29:45 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH4003YWUTG9R@usaga01-in.huawei.com> for behave@ietf.org; Thu, 26 Apr 2007 18:29:41 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JH4009MQUTF5Y@usaga01-in.huawei.com> for behave@ietf.org; Thu, 26 Apr 2007 18:29:40 -0700 (PDT) Date: Thu, 26 Apr 2007 20:27:57 -0500 From: Spencer Dawkins Subject: Re: [BEHAVE] Re: Are NATs routers? To: Behave WG Message-id: <19b601c7886b$4b7c8b40$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> <20070426225628.55DEB33C1A@delta.rtfm.com> <20070426231445.E5B4B33C1A@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Isn't this thread getting a little "off" for an IETF working group? Perhaps we could focus back a bit. Thanks, Spencer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 27 01:34: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 1HhJ6a-0008HB-BK; Fri, 27 Apr 2007 01:34:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhJ6Z-0008H6-38 for behave-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 01:34:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJ6Y-0008Gy-LU for behave@ietf.org; Fri, 27 Apr 2007 01:34:50 -0400 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhJ6Y-0000Lp-9R for behave@ietf.org; Fri, 27 Apr 2007 01:34:50 -0400 Received: by an-out-0708.google.com with SMTP id d30so521454and for ; Thu, 26 Apr 2007 22:34:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QEBBahq1VPqonbOPs3UJl6BZN3GCOq/b8AuJpvgfHYQ8jbsQz1rsRLdCxUPG/UnHuDFTxI8dUtI9Y5LtTWdpQtTfAy7yFR+nuMEHir7ZgCy0zp9LddT51X4wbsPUEH0HqT+8QjiFKphL83LwWHcBDU8St/rrqZr22HrgVjvO+qA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qdkQ07vd1UgOCBdNSGg3dgyGXbHCehaYe5JmF5joCWBotIgQCcBjnBt6S1PUDa46MMHXA1yIzCBZu1dcF1XHcUzOQNmPZBp1vG3gQYeTHM0oReVQLI7GIN2B3eJFrYCJAfp88dPqVNBu4x+WQbs5tmBWvXJRG89xPKDC21hXfJA= Received: by 10.114.72.1 with SMTP id u1mr882499waa.1177652089435; Thu, 26 Apr 2007 22:34:49 -0700 (PDT) Received: by 10.114.95.6 with HTTP; Thu, 26 Apr 2007 22:34:49 -0700 (PDT) Message-ID: Date: Fri, 27 Apr 2007 15:34:49 +1000 From: "Evgeniy Khramtsov" To: "Saikat Guha" Subject: Re: [BEHAVE] TCP listen/connect in TURN In-Reply-To: <1177621951.15291.19.camel@localhost.localdomain> MIME-Version: 1.0 References: <46309F1C.3090005@gmail.com> <1177621951.15291.19.camel@localhost.localdomain> X-Spam-Score: 0.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Content-Type: multipart/mixed; boundary="===============0750202347==" Errors-To: behave-bounces@ietf.org --===============0750202347== Content-Type: multipart/alternative; boundary="----=_Part_80954_33005597.1177652089380" ------=_Part_80954_33005597.1177652089380 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 2007/4/27, Saikat Guha : > > On Thu, 2007-04-26 at 22:46 +1000, Evgeniy Khramtsov wrote: > > AFAIK, it is not possible to accept()/connect() on/from the same port > > simultaneously (at least with Berkley sockets). I just wonder how to > > implement such behavior of the TURN server? > > Actually, it is possible. Perhaps a bug or undocumented feature, but it > works on Linux and Windows for sure, OSX as well I believe and by > extension on BSD too. > > 1: a = socket() > 2: c = socket() > 3: setsockopt(a, SO_REUSEADDR) > 4: bind(a, port) > 5: setsockopt(b, SO_REUSEADDR) > 6: bind(c, port) > 7: listen(a) > 8: connect(c, remote) > > The above sequence succeeds and does what is expected. > > Interestingly, swapping lines 6 and 7 doesn't work; neither does > swapping lines 7 and 8 IIRC. Calling listen(c) in line 8 doesn't work, > but that's expected. Having and additional socket c2 with bind(c2, port) > before line 7 and connect(c2, remote2) after line 7 also works. > > For current OSs, as long as: > 1. All sockets are bound to the local port before listen/connect is > called on any one of them. > 2. Listen is called on at most one socket and is called before all > connect's > It all works. > > > -- > Saikat > > That's really cool, but this 'dirty hack' will not work on mulitple Connect Requests since we cannot bind another socket for connection on the same port after line 8. IMHO :) ------=_Part_80954_33005597.1177652089380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2007/4/27, Saikat Guha <saikat@cs.cornell.edu>:
On Thu, 2007-04-26 at 22:46 +1000, Evgeniy Khramtsov wrote:
> AFAIK, it is not possible to accept()/connect() on/from the same port
> simultaneously (at least with Berkley sockets). I just wonder how to
> implement such behavior of the TURN server?

Actually, it is possible. Perhaps a bug or undocumented feature, but it
works on Linux and Windows for sure, OSX as well I believe and by
extension on BSD too.

1: a = socket()
2: c = socket()
3: setsockopt(a, SO_REUSEADDR)
4: bind(a, port)
5: setsockopt(b, SO_REUSEADDR)
6: bind(c, port)
7: listen(a)
8: connect(c, remote)

The above sequence succeeds and does what is expected.

Interestingly, swapping lines 6 and 7 doesn't work; neither does
swapping lines 7 and 8 IIRC. Calling listen(c) in line 8 doesn't work,
but that's expected. Having and additional socket c2 with bind(c2, port)
before line 7 and connect(c2, remote2) after line 7 also works.

For current OSs, as long as:
1. All sockets are bound to the local port before listen/connect is
called on any one of them.
2. Listen is called on at most one socket and is called before all
connect's
It all works.


--
Saikat


That's really cool, but this 'dirty hack' will not work on mulitple Connect Requests since we cannot bind another socket for connection on the same port after line 8. IMHO :)
------=_Part_80954_33005597.1177652089380-- --===============0750202347== 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 --===============0750202347==-- From behave-bounces@ietf.org Fri Apr 27 02:27:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJvW-0006pL-2E; Fri, 27 Apr 2007 02:27:30 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhJvU-0006pD-8E for behave-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 02:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJvT-0006p4-SG for behave@ietf.org; Fri, 27 Apr 2007 02:27:27 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhJvR-0006Wu-BR for behave@ietf.org; Fri, 27 Apr 2007 02:27:27 -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 l3R6RMK9032063; Fri, 27 Apr 2007 09:27:23 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:27:22 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:27:22 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:27:21 +0300 Received: from esdhcp04055.research.nokia.com (esdhcp04055.research.nokia.com [172.21.40.55]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3R6RKlK001858; Fri, 27 Apr 2007 09:27:20 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Source-port randomzation in Linux 2.6.21 release Date: Fri, 27 Apr 2007 09:27:26 +0300 User-Agent: KMail/1.9.6 References: <006301c78856$9fb961c0$7101a8c0@Quinthar> In-Reply-To: <006301c78856$9fb961c0$7101a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704270927.26995.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 27 Apr 2007 06:27:21.0988 (UTC) FILETIME=[1CE8EC40:01C78895] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 27 April 2007 02:00:02 ext David Barrett wrote: > Can anybody explain what this is? > It sounds an awful lot like=20 > endpoint-dependent mapping (aka, symmetric NAT), which I believe isn't > BEHAVE compliant. Should we talk with the NetFilter guys to let them know > this and thus recommend that this new option not be used? It's an option to the SNAT/MASQUERADE port that forces endpoint+port-depend= ant=20 mapping. I DID complain on netfilter-devel when it was submitted, but nobod= y=20 seemed to care. http://lists.netfilter.org/pipermail/netfilter-devel/2007-January/thread.ht= ml#26612 Apparently, the point is to prevent Skype there (that's a VERY LAME way to = do=20 this). =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 Apr 27 02:44: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 1HhKBt-0007Dl-UX; Fri, 27 Apr 2007 02:44:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhKBs-0007DS-Nd for behave-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 02:44:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKBp-0007C3-5M for behave@ietf.org; Fri, 27 Apr 2007 02:44:21 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhKBk-0002GQ-Aa for behave@ietf.org; Fri, 27 Apr 2007 02:44:21 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 02:44:10 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 02:44:06 -0400 Subject: Re: [BEHAVE] TCP listen/connect in TURN From: Saikat Guha To: Evgeniy Khramtsov In-Reply-To: References: <46309F1C.3090005@gmail.com> <1177621951.15291.19.camel@localhost.localdomain> Date: Fri, 27 Apr 2007 02:44:05 -0400 Message-Id: <1177656245.2463.2.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 27 Apr 2007 06:44:06.0029 (UTC) FILETIME=[735D6BD0:01C78897] X-Spam-Score: 0.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: , Content-Type: multipart/mixed; boundary="===============0668681312==" Errors-To: behave-bounces@ietf.org --===============0668681312== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1cNP+RpbbertAUHQzsoR" --=-1cNP+RpbbertAUHQzsoR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-04-27 at 15:34 +1000, Evgeniy Khramtsov wrote: > 2007/4/27, Saikat Guha : > Having and additional socket c2 with bind(c2, port) > before line 7 and connect(c2, remote2) after line 7 also > works.=20 > That's really cool, but this 'dirty hack' will not work on mulitple > Connect Requests since we cannot bind another socket for connection on > the same port after line 8. IMHO :) True, although the server can preallocate a pool of sockets for a connection and keep them bound. It can then support multiple requests from the same port until that pool runs dry. The size of the pool can vary at creation time of course. --=20 Saikat --=-1cNP+RpbbertAUHQzsoR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGMZu1nFltqi691/oRAtNiAJwIfQJ5wXdejzUD3mv9My5QBOBOzACfe1d1 jiHE6gzbEXeeOTGm2Wm5ftw= =vMdF -----END PGP SIGNATURE----- --=-1cNP+RpbbertAUHQzsoR-- --===============0668681312== 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 --===============0668681312==-- From behave-bounces@ietf.org Fri Apr 27 11:07: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 1HhS31-0003Hw-Vp; Fri, 27 Apr 2007 11:07:47 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhS31-0003Co-22 for behave-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:07:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhS30-0003Cf-Of for behave@ietf.org; Fri, 27 Apr 2007 11:07:46 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhS2z-0007vv-J6 for behave@ietf.org; Fri, 27 Apr 2007 11:07:46 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 361D949AF; Fri, 27 Apr 2007 11:07:45 -0400 (EDT) From: Sam Hartman To: Saikat Guha References: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> <1177466365.25477.8.camel@sioux.systems.cs.cornell.edu> <1177534111.32585.3.camel@sioux.systems.cs.cornell.edu> <1177623954.15291.32.camel@localhost.localdomain> Date: Fri, 27 Apr 2007 11:07:45 -0400 In-Reply-To: <1177623954.15291.32.camel@localhost.localdomain> (Saikat Guha's message of "Thu, 26 Apr 2007 17:45:54 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: behave , Dan Wing Subject: [BEHAVE] Re: DISCUSS and COMMENT: draft-ietf-behave-tcp 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 >>>>> "Saikat" == Saikat Guha writes: Saikat> On Wed, 2007-04-25 at 21:15 -0400, Sam Hartman wrote: >> That text is fine, although note it interacts badly with your >> other desire that when possible ports not be remapped. Saikat> Not sure I understood the last part (about remapping). Your document indicates that it is desirable for the inner port to be the same as the outer port--or at least I think I remember that from behave-nat-udp. Obviously there are a lot of situations where you don't get that. This creates another. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 27 13:39: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 1HhUPm-0002WZ-Nj; Fri, 27 Apr 2007 13:39:26 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhUPl-0002WT-Dg for behave-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 13:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUPl-0002WK-3y for behave@ietf.org; Fri, 27 Apr 2007 13:39:25 -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 1HhUPj-0002p6-Gs for behave@ietf.org; Fri, 27 Apr 2007 13:39:25 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RHdFv6004718; Fri, 27 Apr 2007 20:39:17 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 20:38:52 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 20:38:48 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 20:38:43 +0300 Received: from [128.16.65.34] (essapo-nirac2528.europe.nokia.com [10.162.252.8]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RHcfeg031638; Fri, 27 Apr 2007 20:38:41 +0300 In-Reply-To: <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> References: <378E78E5F361564BB066432F6415764B037C23C0@xmb-sjc-228.amer.cisco.com> <1177252099.4543.28.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <7B2424C4-BD4E-43C2-853D-FB0567E295F5@nokia.com> From: Lars Eggert Date: Fri, 27 Apr 2007 18:38:38 +0100 To: ext Saikat Guha X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 27 Apr 2007 17:38:43.0253 (UTC) FILETIME=[E66A2E50:01C788F2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Sam Hartman , behave Subject: [BEHAVE] Re: DISCUSS and COMMENT: draft-ietf-behave-tcp 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="===============0476600197==" Errors-To: behave-bounces@ietf.org --===============0476600197== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-72--327660268; protocol="application/pkcs7-signature" --Apple-Mail-72--327660268 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-4-22, at 15:28, ext Saikat Guha wrote: > 1. PMTU support requirement: The new version now explicitly recommends > PMTU support using RFC 2119 terminology. Previous version was > silent on > this issue and implicitly depended on the corresponding UDP > recommendation. > > REQ-9: If a NAT translates TCP, it SHOULD translate ICMP > Destination > Unreachable "Fragmentation Needed and Don't Fragment > was > Set" (Type 3, Code 4) messages. The paragraph following REQ-9 says: Furthermore, TCP's connection establishment and maintenance mechanisms also behave much more efficiently when ICMP Destination Unreachable messages arrive in response to outgoing TCP segments. Those messages are type-3 messages other than code-4, which is the only one REQ-9 talks about. Should this be rephrased as: REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination Unreachable (Type 3) messages. And then explaining in the justification that code 4 is especially important for preventing black holes, but the other codes are also recommended to translate, because TCP's connection establishment and maintenance mechanisms also behave much more efficiently when ICMP Destination Unreachable messages arrive in response to outgoing TCP segments? Lars --Apple-Mail-72--327660268 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA0MjcxNzM4MzlaMCMGCSqGSIb3DQEJBDEWBBTS0N/ikrC/R9r2 gPsJhsnOdsOfRjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEABhb/5mRTRhoxQLcRTrkAJ0GnGVM8t0XhpWwJe0Q/RBWWOV/QW8MM iphPBirUCq6+wecTfoNaSmQKieI/AB/N0sqzPZBjy7VWekbXIgmmy0nNN8zvrFdNjiMmUbOf43VN Nr3tRonIPrzmpC3BstsG7QIqqkLo5zYfQMeyI71vBPdzKmSb/wF39MGswUnml/sQzdDGN9mTRh5L ncFeZK/aiGILMHKFhafrT9CThcaHih7k/TIHwLjEEZKgBwIb7mkxRCO/m28u1O0rInDMOXJimHb2 OJrDq3lsMmCj/RQdcJaOWxzQ9pPmYsKslmyrWyrvF+v9U8hJx4l5NjqdS/Xs/AAAAAAAAA== --Apple-Mail-72--327660268-- --===============0476600197== 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 --===============0476600197==-- From behave-bounces@ietf.org Fri Apr 27 13:51: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 1HhUbm-0005tq-Rh; Fri, 27 Apr 2007 13:51:50 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhUbl-0005tk-1Q for behave-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 13:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUbk-0005tX-IE for behave@ietf.org; Fri, 27 Apr 2007 13:51:48 -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 1HhUbj-0005TL-3n for behave@ietf.org; Fri, 27 Apr 2007 13:51:48 -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 l3RHpcrE008241; Fri, 27 Apr 2007 20:51:39 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 20:51:34 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 20:51:28 +0300 Received: from [128.16.65.34] (essapo-nirac2528.europe.nokia.com [10.162.252.8]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RHpRni008377; Fri, 27 Apr 2007 20:51:27 +0300 In-Reply-To: References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> <20070426225628.55DEB33C1A@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <14B976B5-C766-491F-A85E-DB35811A4BFB@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] Re: Are NATs routers? Date: Fri, 27 Apr 2007 18:51:25 +0100 To: ext Jim Dixon X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 27 Apr 2007 17:51:29.0634 (UTC) FILETIME=[AF36A420:01C788F4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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: , Content-Type: multipart/mixed; boundary="===============1793090952==" Errors-To: behave-bounces@ietf.org --===============1793090952== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-73--326893409; protocol="application/pkcs7-signature" --Apple-Mail-73--326893409 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-4-27, at 0:10, ext Jim Dixon wrote: > The question here is whether all of these gazillions of machines which > are bought and sold as routers are actually such. The claim is that > if they do NAT they cannot be called routers - even though that's > exactly > what everyone calls them. People can _call_ these boxes whatever they like. If the box in question does not fully implement RC1812, it _is not_ a standards-compliant IP router. (And yes, some boxes that you buy can be configured to obey or not obey all of RFC1812, depending on what functions are enabled.) Lars --Apple-Mail-73--326893409 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA0MjcxNzUxMjZaMCMGCSqGSIb3DQEJBDEWBBTJSvCLnQQrsqCw ip5qItO9TVGPcjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAo9DcSEiswOZQtmTsqPGca+AcpZ/3iw6OXftNEuLfz21nF4Ydy69O BZbHnI+47yHCtxD3PO0raUL/yV1171vBp8E3IZoGQO9NKvjrs7Bj7/nq2xCQZOyugQ5uWq7A4JOO Yvn+g4MLfJapcBPDs7b3PJ5eoHYZGEIuJe/bb9tY1vt9O2ZzNXoQaGERgZ4i3iYtJPsrtRiiX+lE hX4Goxr0HBDw24zYhCHJrfrVtevn2nGHvnz9qCfoMsdgxJ8OYqGBsAt7KvbsXLmBagewCYqMI5nP dHRc9Z0JX17ZCOOfirlq2Ih4F0AXerlnNABmCu8Z9O7T7KS+hCBRv0l6FdAirAAAAAAAAA== --Apple-Mail-73--326893409-- --===============1793090952== 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 --===============1793090952==-- From behave-bounces@ietf.org Fri Apr 27 14:12:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUw9-0003mr-Nd; Fri, 27 Apr 2007 14:12:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhUw9-0003mm-4g for behave-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 14:12:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUw8-0003me-RS for behave@ietf.org; Fri, 27 Apr 2007 14:12:52 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUw7-0003iT-DH for behave@ietf.org; Fri, 27 Apr 2007 14:12:52 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RICOkP000776; Fri, 27 Apr 2007 21:12:48 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 21:12:36 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 13:12:30 -0500 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: Are NATs routers? Date: Fri, 27 Apr 2007 13:12:29 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F80F058@daebe103.NOE.Nokia.com> In-Reply-To: <14B976B5-C766-491F-A85E-DB35811A4BFB@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: Are NATs routers? Thread-Index: AceI9ro0dPuFiAy4RYOuUtKFzRUXZgAAIzjQ References: <462CDD8C.7060501@isi.edu><741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com><20070426225628.55DEB33C1A@delta.rtfm.com> <14B976B5-C766-491F-A85E-DB35811A4BFB@nokia.com> From: To: , X-OriginalArrivalTime: 27 Apr 2007 18:12:30.0013 (UTC) FILETIME=[9E7536D0:01C788F7] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 >> The question here is whether all of these gazillions of machines which=20 >> are bought and sold as routers are actually such. The claim is that=20 >> if they do NAT they cannot be called routers - even though that's=20 >> exactly what everyone calls them. > >People can _call_ these boxes whatever they like. > >If the box in question does not fully implement RC1812, it _is=20 >not_ a standards-compliant IP router. > >(And yes, some boxes that you buy can be configured to obey or=20 >not obey all of RFC1812, depending on what functions are enabled.) I agree. A few years ago, I bought a home 'router' with built in=20 'firewall' functionality. It turns out, there was no firewall, just a NAT. I guess the marketing department though 'firewall' was more of a value add, than NAT. I think in this working group, we should really follow standard definations of what a NAT, router (and firewall) are, not just what is listed as=20 functionality on product literature. John _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 27 14:57:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVct-0006B7-B0; Fri, 27 Apr 2007 14:57:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HhVcs-0006B1-Ix for behave-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 14:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVcs-0006At-9S for behave@ietf.org; Fri, 27 Apr 2007 14:57:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVcq-000659-P8 for behave@ietf.org; Fri, 27 Apr 2007 14:57:02 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2007 11:56:56 -0700 X-IronPort-AV: i="4.14,462,1170662400"; d="scan'208"; a="416441907:sNHT4435155658" 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 l3RIusRn023077; Fri, 27 Apr 2007 11:56:54 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3RIurZT028203; Fri, 27 Apr 2007 18:56:53 GMT From: "Dan Wing" To: "'Sam Hartman'" , "'Saikat Guha'" Date: Fri, 27 Apr 2007 11:56:53 -0700 Message-ID: <0ba601c788fd$d273b410$05716b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceI3dEQsUmrFc2FQ3e8RuHwXfFc0gAHykzw In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1671; t=1177700214; x=1178564214; 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=20DISCUSS=20and=20COMMENT=3A=20draft-ietf-behave-tcp |Sender:=20; bh=mckpazUSsSsFtW+O77Sg1/fWDXnKKk77sGF5oSLbiSQ=; b=zYHiebb1Z9rzwQhB2FdHhZviyKKMm1jHJa505fNAwIoNoyXASYaDJy0LWY2y06BBkgSzJ1Jz X++gxKFVV1eVjwJE+qdcHDpsQa2XzNyMLG0u7qZVD5cUEV1BS5m1UKYA; 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'behave' Subject: [BEHAVE] RE: DISCUSS and COMMENT: draft-ietf-behave-tcp 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 > >>>>> "Saikat" == Saikat Guha writes: > > Saikat> On Wed, 2007-04-25 at 21:15 -0400, Sam Hartman wrote: > >> That text is fine, although note it interacts badly with your > >> other desire that when possible ports not be remapped. > > Saikat> Not sure I understood the last part (about remapping). > > Your document indicates that it is desirable for the inner port to be > the same as the outer port--or at least I think I remember that from > behave-nat-udp. Behave-nat-udp (now RFC4787) talked about preservation of port numbers, but didn't make a recommendation for or against port preservation. The WG consensus is that port preservation is bad (because it allows and encourages applications to be sloppy and not signal ports, thus causing failure when two applications behind the same NAT expect to be allocated the same public port), yet there are applications that only work in the presence of a NAT that does attempt its best to preserve ports. One requirement related to this which is in RFC4787 is: "REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading". a) If the host's source port was in the range 0-1023, it is RECOMMENDED the NAT's source port be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port be in that range." > Obviously there are a lot of situations where you > don't get that. This creates another. Agreed. But because RFC4787 didn't encourage re-using ports this shouldn't be too significant a complication. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 29 00:20: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 1Hi0tX-0005CP-IU; Sun, 29 Apr 2007 00:20:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hi0tW-0005CK-D5 for behave-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 00:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi0tW-0005CC-3R for behave@ietf.org; Sun, 29 Apr 2007 00:20:18 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hi0tU-00079R-Rj for behave@ietf.org; Sun, 29 Apr 2007 00:20:18 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 28 Apr 2007 21:20:14 -0700 X-IronPort-AV: i="4.14,465,1170662400"; d="scan'208"; a="56909928:sNHT43838136" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3T4KEU8007541; Sat, 28 Apr 2007 21:20:14 -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 l3T4HFA9024148; Sun, 29 Apr 2007 04:20:13 GMT In-Reply-To: <19b601c7886b$4b7c8b40$ad600240@china.huawei.com> References: <462CDD8C.7060501@isi.edu> <741E54BE-B498-40C9-A6B5-01DD740ADB6E@cisco.com> <20070426225628.55DEB33C1A@delta.rtfm.com> <20070426231445.E5B4B33C1A@delta.rtfm.com> <19b601c7886b$4b7c8b40$ad600240@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <115C3A7A-F6C4-4D52-A196-F1512455B402@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] Re: Are NATs routers? Date: Sat, 28 Apr 2007 21:16:40 -0700 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=421; t=1177820414; x=1178684414; c=relaxed/simple; s=sjdkim7002; 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=20Are=20NATs=20routers? |Sender:=20; bh=mhWtXLykS63U90j/Jy9EvaLI/wLHApGSz4/Fc4JXZ5k=; b=o2bHlct5/UeSmBnw97y1PkY5smiyDAKqDdZYokPgzO1lgLyrmh5qXDztpCkVwzkJxrOnQM00 Wh+QGLpaaxduSJ7OTvlE3OxE6ztV2BlLW1V7LWfbkV2vmQbrLvURCJK1; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Apr 26, 2007, at 6:27 PM, Spencer Dawkins wrote: > Isn't this thread getting a little "off" for an IETF working group? > > Perhaps we could focus back a bit. +1 All jokes aside - the important thing is that we mean the same thing when we use a word. Luckily we seem to mostly agree what a NAT is and I will attempt to be more precise when I use the R word in this group in the future. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 30 02:15:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiPAB-0004Hp-A7; Mon, 30 Apr 2007 02:15:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HiPAA-0004EX-2o for behave-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 02:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiPA9-0004EO-67 for behave@ietf.org; Mon, 30 Apr 2007 02:15:05 -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 1HiPA7-0000IK-Md for behave@ietf.org; Mon, 30 Apr 2007 02:15:05 -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 l3U6EpIx003665; Mon, 30 Apr 2007 09:15:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 09:15:00 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 09:15:00 +0300 Received: from esdhcp04146.research.nokia.com (esdhcp04146.research.nokia.com [172.21.41.46]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3U6EwPI031661; Mon, 30 Apr 2007 09:14:58 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Source-port randomzation in Linux 2.6.21 release Date: Mon, 30 Apr 2007 09:15:08 +0300 User-Agent: KMail/1.9.6 References: <006301c78856$9fb961c0$7101a8c0@Quinthar> <20070426231230.GE84280@buggy.corp.yahoo.com> In-Reply-To: <20070426231230.GE84280@buggy.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704300915.08827.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 30 Apr 2007 06:15:00.0339 (UTC) FILETIME=[E2178430:01C78AEE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 27 April 2007 02:12:31 ext Lloyd Hilaiel wrote: > sounds more to me like random port allocation behavior, but is > orthogonal to port mapping behavior. Meaning a NAT may be "full > cone" and still allocate new ports randomly... I haven't had a chance to try yet. But the patch submitter explicitly=20 cited "blocking Skype" as the use case. As such, I presume it's randomizing= =20 mapped port per endpoint (=E0 la OpenBSD). =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 Apr 30 03:22: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 1HiQCr-0005m9-PZ; Mon, 30 Apr 2007 03:21:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HiQCq-0005m1-7t for behave-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 03:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiQCn-0005lj-5j for behave@ietf.org; Mon, 30 Apr 2007 03:21:53 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiQCk-0000dQ-LB for behave@ietf.org; Mon, 30 Apr 2007 03:21:52 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 03:21:45 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 03:21:40 -0400 Subject: Re: [BEHAVE] Source-port randomzation in Linux 2.6.21 release From: Saikat Guha To: =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont In-Reply-To: <200704300915.08827.remi.denis-courmont@nokia.com> References: <006301c78856$9fb961c0$7101a8c0@Quinthar> <20070426231230.GE84280@buggy.corp.yahoo.com> <200704300915.08827.remi.denis-courmont@nokia.com> Date: Mon, 30 Apr 2007 03:21:39 -0400 Message-Id: <1177917700.28239.20.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 30 Apr 2007 07:21:40.0647 (UTC) FILETIME=[32761370:01C78AF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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="===============2107549136==" Errors-To: behave-bounces@ietf.org --===============2107549136== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8CdJ0odS207zyhXJ//Yt" --=-8CdJ0odS207zyhXJ//Yt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 2007-04-30 at 09:15 +0300, R=C3=A9mi Denis-Courmont wrote: > I haven't had a chance to try yet. But the patch submitter explicitly=20 > cited "blocking Skype" as the use case. As such, I presume it's randomizi= ng=20 > mapped port per endpoint (=C3=A0 la OpenBSD). Hmmm, so Skype works behind non endpoint-independent NATs as well [1]. It uses TURN-like relaying for that. So the port-randomization wouldn't block Skype. I haven't looked at the patch, but my guess would be that they want to block Skype from becoming a supernode (i.e. a node that relays for other people). Port-randomization would get at that AFAIR. That said, the randomized behavior appears to not be the default. Same for OpenBSD's pf. Both require the administrator to explicitly invoke the functionality, and in so doing take the NAT out of BEHAVE compliance.=20 I'd hope that the associated documentation conspicuously informs the admin that using that setting will break many applications and will make his NAT non-standards compliant while adding no more security than less invasive Skype supernode prevention approaches such as payload inspection [2].=20 [1] http://saikat.guha.cc/pub/iptps06-skype/ [2] http://www1.cs.columbia.edu/~salman/skype/index.html --=20 Saikat --=-8CdJ0odS207zyhXJ//Yt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGNZkDnFltqi691/oRAo1OAJ9CuxUHCd7yhakyIsF9zMflETOWsACeIm8n HFuTB0MOG27MohLGBw4ACUA= =O4UO -----END PGP SIGNATURE----- --=-8CdJ0odS207zyhXJ//Yt-- --===============2107549136== 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 --===============2107549136==-- From behave-bounces@ietf.org Mon Apr 30 15:51: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 1Hibth-0005tE-Cu; Mon, 30 Apr 2007 15:50:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HibtK-00059J-NN for behave-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 15:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HibtJ-00057p-Jo; Mon, 30 Apr 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HibtI-000338-Uy; Mon, 30 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C6F3F2AC83; Mon, 30 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hibso-0001lT-Ii; Mon, 30 Apr 2007 15:50:02 -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: Mon, 30 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-tcp-07.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 : NAT Behavioral Requirements for TCP Author(s) : S. Guha, et al. Filename : draft-ietf-behave-tcp-07.txt Pages : 21 Date : 2007-4-30 This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-07.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-tcp-07.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-tcp-07.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-4-30145619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-tcp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-tcp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-30145619.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--