From behave-bounces@ietf.org Thu Mar 01 09:15: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 1HMm4M-00051L-UT; Thu, 01 Mar 2007 09:15:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMm4L-0004zS-HU for behave@ietf.org; Thu, 01 Mar 2007 09:15:41 -0500 Received: from web33309.mail.mud.yahoo.com ([68.142.206.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMm4K-0000p8-8B for behave@ietf.org; Thu, 01 Mar 2007 09:15:41 -0500 Received: (qmail 70404 invoked by uid 60001); 1 Mar 2007 14:15: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=U0dxtroxDbaO06jxMME+FuoRIBXYoqm0a7r662iqkseXrdT6udU4eI7IQlHEG6aHIBzEUnB1vwJ4BP9go/l1we9erZNDCEy96amllxA6Ol2w5EfldjVc2yPg5f7T6CwxQZDpx48gFFHoOM+l5+kaWc85pjsSTk3P98hiWh8nkBU=; X-YMail-OSG: DLuL3tMVM1mj9LcY1cfjAWVxNal47lA99RIfvunSrLsKBHAi8u..eUkg_X_9KGxRTsCg9LdABs8hOHARMLGBJXKLGKId1yZTFr0ezE3o1VWGkfmO6v2TSpzbn2d7g_7QEl3zrKXGhAU- Received: from [69.236.102.196] by web33309.mail.mud.yahoo.com via HTTP; Thu, 01 Mar 2007 06:15:39 PST Date: Thu, 1 Mar 2007 06:15:39 -0800 (PST) From: Pyda Srisuresh Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now To: Cullen Jennings In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <684736.64650.qm@web33309.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Behave WG' , 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 --- Cullen Jennings wrote: > > On Feb 28, 2007, at 7:46 AM, Pyda Srisuresh wrote: > > > Note, this is different from "Behave Compliant NAT". If you like, I > > could add a line that BEHAVE complaint NAT devices are good > > examples of "P2P > > friendly NAT" devices. > > Help me understand the difference between the two? If this is an > effort to define P2P Friendly NATs to be the things that the WG > disagreed with you about when doing the existing drafts, I doubt that > represents WG consensus. > [suresh] Cullen - I have no intent to do anything outside WG consensus in any draft, including the p2p-state draft. And, I had not done this before. The term "P2P-friendly NAT" is defined in p2p-state draft as follows. A P2P-friendly NAT is a NAT device that maintains the endpoint identity of a P2P host application when the P2P application initiates a session. P2P-friendly NAT devices permit traversal of P2P applications traffic across themselves. NAT devices employing Address-Independent Mapping are examples of P2P-friendly NAT devices. As you can see the only requirement attributed to this term is Endpoint-Independent mapping. This draft is focused solely on NAT traversal for p2P applications. Whereas, RFC 4787 and TCP/ICMP Behave drafts are more holistic and have a total of 32 (14+9+9) requirements for BEHAVE compliance. For example, they each have mandatory timeout requirement that many NATs out there do not comply with yet. This is why I said that the term "P2P Friendly NAT" is different from "Behave Compliant NAT". Hope you understand. regards, suresh _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 01 11:32: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 1HMoCr-0000SO-0v; Thu, 01 Mar 2007 11:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMoCp-0000SE-MH; Thu, 01 Mar 2007 11:32:35 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMoCb-0007Br-Oy; Thu, 01 Mar 2007 11:32:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9E37E26EA0; Thu, 1 Mar 2007 16:32:21 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMoCb-0003Yl-HK; Thu, 01 Mar 2007 11:32:21 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 01 Mar 2007 11:32:21 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: behave@ietf.org Subject: [BEHAVE] Last Call: draft-ietf-behave-tcp (NAT Behavioral Requirements for TCP) to BCP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org 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 IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'NAT Behavioral Requirements for TCP ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14296&rfc_flag=0 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 01 13:22: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 1HMpuX-0005ol-Cq; Thu, 01 Mar 2007 13:21:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMpuV-0005o0-RI for behave@ietf.org; Thu, 01 Mar 2007 13:21:47 -0500 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 1HMpuJ-0003VE-C4 for behave@ietf.org; Thu, 01 Mar 2007 13:21:47 -0500 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 13:21:34 -0500 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); Thu, 1 Mar 2007 13:21:34 -0500 Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now From: Saikat Guha To: Pyda Srisuresh In-Reply-To: <684736.64650.qm@web33309.mail.mud.yahoo.com> References: <684736.64650.qm@web33309.mail.mud.yahoo.com> Date: Thu, 01 Mar 2007 13:21:33 -0500 Message-Id: <1172773293.9151.19.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.9.91 (2.9.91-3.fc7) X-OriginalArrivalTime: 01 Mar 2007 18:21:34.0126 (UTC) FILETIME=[713A84E0:01C75C2E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'Behave WG' , 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: , Content-Type: multipart/mixed; boundary="===============0629194395==" Errors-To: behave-bounces@ietf.org --===============0629194395== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VDnk4DHqN79okYZU0UON" --=-VDnk4DHqN79okYZU0UON Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-03-01 at 06:15 -0800, Pyda Srisuresh wrote: > As you can see the only requirement attributed to this term is > Endpoint-Independent mapping. This draft is focused solely on NAT travers= al for > p2P applications. Whereas, RFC 4787 and TCP/ICMP Behave drafts are more > holistic and have a total of 32 (14+9+9) requirements for BEHAVE complian= ce. > For example, they each have mandatory timeout requirement that many NATs = out > there do not comply with yet. Just made a quick pass through the document, three comments. 1) In the definition of P2P-Friendly, any particular reason why the other BEHAVE requirements are left out? For example, a NAT that instantly responds with a RST packet to any and all inbound-SYN packets is _not_ P2P friendly even if it had endpoint independent mappings. According to the current definition, it would be classified as P2P friendly. 2) The document currently does not talk about keepalive packets. IMHO keepalives should be in scope, particularly since datapath authentication is (advocated in section 6.1). P2P developers must perform both datapath auth and keepalives in NAT'ed environments. 3) The document defines Endpoint-Dependent mapping and filtering, as has been pointed out to basically refer to *non*-Endpoint-Independent mapping and filtering defined in BEHAVE documents. Instead of defining new terms, suggest using negated versions of established terms. 2c --=20 Saikat --=-VDnk4DHqN79okYZU0UON Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBF5xmtnFltqi691/oRAqJFAJ466eMHSbJf5nRULqtKBvwe0y98SgCfYs6p CR7IZKJRhyPwLtP7b5WtlkQ= =sJUc -----END PGP SIGNATURE----- --=-VDnk4DHqN79okYZU0UON-- --===============0629194395== 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 --===============0629194395==-- From behave-bounces@ietf.org Thu Mar 01 15:51: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 1HMsEX-0001F2-Th; Thu, 01 Mar 2007 15:50:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsE0-0000be-H8; Thu, 01 Mar 2007 15:50:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMsE0-0001Y7-55; Thu, 01 Mar 2007 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 16B9232956; Thu, 1 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMsDz-0002ff-V7; Thu, 01 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-nat-icmp-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --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 ICMP protocol Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-nat-icmp-03.txt Pages : 24 Date : 2007-3-1 This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the ICMP protocol. The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-03.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-nat-icmp-03.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-nat-icmp-03.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-3-1143612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-nat-icmp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-nat-icmp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-1143612.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 Thu Mar 01 20:21: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 1HMwRq-0005n0-On; Thu, 01 Mar 2007 20:20:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMwRo-0005kN-Tf for behave@ietf.org; Thu, 01 Mar 2007 20:20:36 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMwRn-0008N4-HT for behave@ietf.org; Thu, 01 Mar 2007 20:20:36 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2007 17:20:32 -0800 X-IronPort-AV: i="4.14,239,1170662400"; d="scan'208"; a="363653305:sNHT52640408" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l221KWe5013151 for ; Thu, 1 Mar 2007 17:20:32 -0800 Received: from dwingwxp (dhcp-128-107-163-112.cisco.com [128.107.163.112]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l221KWDk028767 for ; Thu, 1 Mar 2007 17:20:32 -0800 (PST) From: "Dan Wing" To: "BEHAVE Working Group" Date: Thu, 1 Mar 2007 17:20:31 -0800 Message-ID: <042901c75c68$f88ca6f0$70a36b80@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: AcdPJmzwKD4393x3QgS1ncYUhlhdVgNQedqg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1721; t=1172798432; x=1173662432; 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:=20poll=3A=20=20RE=3A=20protocol=20design=20techniques, =20draft- ford-behave-app |Sender:=20; bh=jTDcq9lO7bjFtxXIirUmHL/2Yo+K/OHrg51R6sB3Dw0=; b=GzuFl3hhaIuB2UrZR9QbL4ikoJ0FeBWmGqJJCKNtAYidd08ORkDx2vmejjGU9z5nEqGQEMuq mbMUp+WxMyGi3KonrgTQWsT/s9jMopZvkRZeNW95CSirqTgbOtP8UQek; 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: c1c65599517f9ac32519d043c37c5336 Subject: [BEHAVE] poll: RE: protocol design techniques, draft-ford-behave-app X-BeenThere: behave@ietf.org X-Mailman-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 All is quiet -- this tells me you are too busy with draft submissions, you don't care about this milestone, or you don't feel this draft meets the milestone but don't want to say so. I'll give this another week, but I would really like some discussion around adopting this document -- please at least reply yeah, nay, or I-don't-care, privately or to the list. We will also need technical reviewers before adopting the document as a WG item; volunteering is encouraged. Thanks! -d > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, February 12, 2007 8:21 PM > To: BEHAVE Working Group > Subject: protocol design techniques, draft-ford-behave-app > > We have the following milestone on our charter: > > Submit a BCP that discusses protocol design > techniques for using the existing set of NAT > traversal approaches to IESG > > In essence: describe how to do something like ICE. > > The document draft-ford-behave-app appears to meet this milestone. > > At the last IETF meeting, there was some discussion around adopting > draft-ford-behave-app. Several people had concerns that the authors > would not be able to incorporate feedback from meetings if the authors > were not present at the meetings (physically or via audio + Jabber). > > This situation hasn't changed, but I nonetheless suggest that we adopt > this document as a WG document. > > I am also soliciting a volunteer to present the document in Prague so > that working group feedback can be brought back to the authors for > incorporation into the next version. > > Please reply to me or the list with any comments or suggestions. > > -d > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Mar 02 09:30: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 1HN8lV-0001Us-Fu; Fri, 02 Mar 2007 09:29:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8lU-0001Li-AS for behave@ietf.org; Fri, 02 Mar 2007 09:29:44 -0500 Received: from web33302.mail.mud.yahoo.com ([68.142.206.117]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HN8lR-00045W-Re for behave@ietf.org; Fri, 02 Mar 2007 09:29:44 -0500 Received: (qmail 37388 invoked by uid 60001); 2 Mar 2007 14:29:41 -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=4rRkRn0YjdRjJBisW5x/fbTgw5QbJSkQJ3J3qeI0uoxMBkUHP/Pl8PCxLw0X35XaVSyNQaDa0U4XiwBuX2C9wd840DNAtKUtQJCOFttIMpoRSdjqWiD5ZHM9Rn+P9c3MTanAl2tp6KjwRgBFFhExVah9to0FFDOLY8P7XOLhGlI=; X-YMail-OSG: K_pVbXUVM1kDsr_OaVrIG_E3CzsY7eGb8zXYD872OFg_RZxo_MtZemdiO3hqRYZYhPjeYeOeWAI6O4Wpoa1bx.Lzt__7GGd0BNRzPccJq6VhIzhdq7VPoS4Z1t.Tu4zT.DivXhELnmEmMTtGlNNivw-- Received: from [69.236.102.196] by web33302.mail.mud.yahoo.com via HTTP; Fri, 02 Mar 2007 06:29:41 PST Date: Fri, 2 Mar 2007 06:29:41 -0800 (PST) From: Pyda Srisuresh Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now To: Saikat Guha In-Reply-To: <1172773293.9151.19.camel@sioux.systems.cs.cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <183757.37187.qm@web33302.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 'Behave WG' , 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 --- Saikat Guha wrote: > On Thu, 2007-03-01 at 06:15 -0800, Pyda Srisuresh wrote: > > As you can see the only requirement attributed to this term is > > Endpoint-Independent mapping. This draft is focused solely on NAT traversal > for > > p2P applications. Whereas, RFC 4787 and TCP/ICMP Behave drafts are more > > holistic and have a total of 32 (14+9+9) requirements for BEHAVE > compliance. > > For example, they each have mandatory timeout requirement that many NATs > out > > there do not comply with yet. > > Just made a quick pass through the document, three comments. > [suresh] Thank you for your comments. > 1) In the definition of P2P-Friendly, any particular reason why the > other BEHAVE requirements are left out? For example, a NAT that > instantly responds with a RST packet to any and all inbound-SYN packets > is _not_ P2P friendly even if it had endpoint independent mappings. > According to the current definition, it would be classified as P2P > friendly. > [suresh] Saikat - The scope of the draft is restricted to describing techniques used to set up 2-way communication between endoints of a peer-to-peer application. No discussion of timeouts, RST processing, keepalives, fragment handling etc. That is not what the draft is about. Given the restricted scope, the definition of "P2P-friendly NAT" is apt to be restricted to mere Endpoint Independent Mapping. Whereas, the scope of BEHAVE drafts is a holistic description of requirements on NATs from the perspective of complete life-cycle of end-to-end connections. BEHAVE drafts for TCP, UDP and ICMP do not talk about the use of rendezvous servers, Relay servers, port-predition and the like in setting up 2-way communication. Nonetheless, the requirements laid out in the BEHAVE drafts lend themselves to supporting the 2-way communication across NATs. You might say, a "BEHAVE-compliant NAT" adheres to "Necessary and sifficient" requirements for a hollistic operation of all applications, including P2P; whereas a "P2P Friendly NAT" merely states the requirement ("Necessary, but not sufficient") for seting up end-to-end connection between P2P applications. > 2) The document currently does not talk about keepalive packets. IMHO > keepalives should be in scope, particularly since datapath > authentication is (advocated in section 6.1). P2P developers must > perform both datapath auth and keepalives in NAT'ed environments. > [suresh] Please see my note above. The scope is restricted to settign up 2-way communication. Not, beyond that. > 3) The document defines Endpoint-Dependent mapping and filtering, as has > been pointed out to basically refer to *non*-Endpoint-Independent > mapping and filtering defined in BEHAVE documents. Instead of defining > new terms, suggest using negated versions of established terms. > [suresh] Saikat - "Non-Endpoint-Independent Maping" is no less of a new term than "Endpoint-Dependent Mapping". Endpoint Dependent Mapping is easy to read and simply reuses defintions from RFC4787. regards, suresh > 2c > -- > Saikat > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Mar 03 05:16: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 1HNRHU-0007pz-WA; Sat, 03 Mar 2007 05:16:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNRHS-0007pk-UN for behave@ietf.org; Sat, 03 Mar 2007 05:15:58 -0500 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNRHR-0003jt-OJ for behave@ietf.org; Sat, 03 Mar 2007 05:15:58 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1072212wxd for ; Sat, 03 Mar 2007 02:15:57 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=ONZXO+6X4nWPCuoDz4Xvz2dvT+dSv/D66TXb+vlpcMdtezsul4pumAuqPGwVesjrZnGksSZTlBQTsGOeeN/zMGO4/Ukjv2fwVlAi/Hq9cuh3dDjDDeczjXAC224dWZGJj5BC+WTl+wV/5OGEFGwexUe24gTLXSevP7UWW6jPyUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=MgSN23eGxITND8QbdO+L53gHCz8EElbBzdU4sC6Mu8ewskkWFXT3QIqyMdI5WvHawVmHzbxfyUH12wtoJuaW2X43eOzznpvwBZTg0Do2AFYFETz25Yws/yMzXIf6zTK8+U2Wciy1VIkyqMY2fUO1oOLBDxCr3W23cLBKEmSL51U= Received: by 10.90.93.6 with SMTP id q6mr3559478agb.1172916957587; Sat, 03 Mar 2007 02:15:57 -0800 (PST) Received: by 10.90.90.19 with HTTP; Sat, 3 Mar 2007 02:15:57 -0800 (PST) Message-ID: Date: Sat, 3 Mar 2007 15:45:57 +0530 From: "Mayank Dev Sondhi" To: behave@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [BEHAVE] WGLC status and schedule X-BeenThere: behave@ietf.org X-Mailman-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="===============1351937153==" Errors-To: behave-bounces@ietf.org --===============1351937153== Content-Type: multipart/alternative; boundary="----=_Part_24060_27041392.1172916957567" ------=_Part_24060_27041392.1172916957567 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I'm a little confused as to the current agenda for the review of various WGLC documents. I remember that as per the schedule I had before, the ice document was to be considered, however I find other new documents in the review queue. I may not have the correct schedule, could someone please point me to the current schedule so that I don't start reviewing docs that are not being considered for final review. Thanks Mayank ------=_Part_24060_27041392.1172916957567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
      I'm a little confused as to the current agenda for the review of various WGLC documents. I remember that as per the schedule I had before, the ice document was to be considered, however I find other new documents in the review queue.
      I may not have the correct schedule, could someone please point me to the current schedule so that I don't start reviewing docs that are not being considered for final review.
 
Thanks
Mayank
------=_Part_24060_27041392.1172916957567-- --===============1351937153== 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 --===============1351937153==-- From behave-bounces@ietf.org Sat Mar 03 14:13: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 1HNZfL-0007U2-S7; Sat, 03 Mar 2007 14:13:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNZfJ-0007S5-PT for behave@ietf.org; Sat, 03 Mar 2007 14:13:09 -0500 Received: from web33311.mail.mud.yahoo.com ([68.142.206.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HNZch-00073k-UW for behave@ietf.org; Sat, 03 Mar 2007 14:10:29 -0500 Received: (qmail 61223 invoked by uid 60001); 3 Mar 2007 19:10:25 -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=V+i7cKkUr8ALUviOtZZl0fuCJT0l9/2hJ1qgEMcmfq+51fSzfa+M65DpeFYq6vclGM9KH7NdtzHFAUGDI/Q0KzjzimJyACBlH/upxb4oyv+lR6GbeeVEn5FXTaIW6wmGyyaQ/1tQxnOm5+aOp1meMdL1LzQAgqg3JX1KbdSI6ao=; X-YMail-OSG: sSrM3oMVM1mXrimqkCDbtlGn9eKAxGDPjCxopYD2G_pFwUr1esGaUKgIOmoE0Y.HdOVtACFG7qFYfyA0f9Zr6nxUUrn6Ko1JbMO11OyImWLHalQ85Fk4gNTnmxBn0_7MX073uuO_2g9m6TE- Received: from [69.236.102.196] by web33311.mail.mud.yahoo.com via HTTP; Sat, 03 Mar 2007 11:10:25 PST Date: Sat, 3 Mar 2007 11:10:25 -0800 (PST) From: Pyda Srisuresh Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-nat-icmp-03.txt To: behave@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <369203.60623.qm@web33311.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 Dear all, The latest ICMP draft incorporates comments from the last WG meeting, feedback from [ICMP-EXT] authors and comments from a number of individuals that reviewed the draft and sent their comments. Below is a high level summary of changes in this rev. Please review and send your comments on the list. Thanks. 1. For each requirement, the document now explicitly states whether the requirement is necessary for current applications to work properly, or is meant for future applications (future use, rather than current). 2. As sugegsted in the WG meeting, the ICMP draft specifies only the translation of ICMP messages, and leaves the reaction up to each protocol-specific document. REQ-6 is changed to reflect this. 3. In the introduction section, the draft indentifies requirements that relate to ICMP packets going through the NAT versus requirements that relate to ICMP packets being generated by the NAT. 4. The draft now adds [ICMP-EXT] as reference and updates relevant requirements, with feedback from the authors of [ICMP-EXT]. REQ-3, REQ-4 and REQ-5 are changed to reflect this. 5. Security considerations section is updated to add a comment w.r.t. REQ-8. regards, suresh --- Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance > Working Group of the IETF. > > Title : NAT Behavioral Requirements for ICMP protocol > Author(s) : P. Srisuresh, et al. > Filename : draft-ietf-behave-nat-icmp-03.txt > Pages : 24 > Date : 2007-3-1 > > This document specifies the behavioral properties required of the > Network Address Translator (NAT) devices in conjunction with the > ICMP protocol. The objective of this memo is to make NAT devices > more predictable and compatible with diverse application protocols > that traverse the devices. Companion documents provide behavioral > recommendations specific to TCP, UDP and other protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-03.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-nat-icmp-03.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-nat-icmp-03.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. > > _______________________________________________ > 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 Mar 07 14:56: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 1HP2FK-0001H3-1n; Wed, 07 Mar 2007 14:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP2FI-0001Gs-Ao for behave@ietf.org; Wed, 07 Mar 2007 14:56:20 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP2FE-0002C8-Sn for behave@ietf.org; Wed, 07 Mar 2007 14:56:20 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2007 11:56:16 -0800 X-IronPort-AV: i="4.14,261,1170662400"; d="scan'208"; a="46269646:sNHT43326063" 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 l27JuG74002440; Wed, 7 Mar 2007 11:56:16 -0800 Received: from dwingwxp (dhcp-128-107-163-112.cisco.com [128.107.163.112]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l27JuGxR023308; Wed, 7 Mar 2007 19:56:16 GMT From: "Dan Wing" To: "'Mayank Dev Sondhi'" , Subject: RE: [BEHAVE] WGLC status and schedule Date: Wed, 7 Mar 2007 11:56:16 -0800 Message-ID: <0d1601c760f2$aa692c80$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcddfY62fvJpGinYT1KZnxqK0oe7OADdDhvg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1711; t=1173297376; x=1174161376; 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]=20WGLC=20status=20and=20schedule |Sender:=20; bh=XZJ1yJdviO9qfcaTsAJCGrwI7hsMxC7Eqcwe2+eGkLc=; b=Zm8TOavvfw2RCymx56lDJ8KaA2rFsqW+9MPxNEPDNjGN2qnqWzehWwaE1dOPF6du60TaAGuQ 9TfmSiH4VbpjnjutPbTfajZrX+WtPyx4e3Jx8UfzKEWdbYVlD7G+WfQb; 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: 769a46790fb42fbb0b0cc700c82f7081 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: Mayank Dev Sondhi [mailto:msondhi@gmail.com] > Sent: Saturday, March 03, 2007 2:16 AM > To: behave@ietf.org > Subject: [BEHAVE] WGLC status and schedule > > Hi All, > I'm a little confused as to the current agenda for the > review of various WGLC documents. I remember that as per the > schedule I had before, the ice document was to be considered, > however I find other new documents in the review queue. Although several of BEHAVE's documents have a tight relationship with ICE, ICE is a product of the MMUSIC working group. > I may not have the correct schedule, could someone > please point me to the current schedule so that I don't start > reviewing docs that are not being considered for final review. rfc3489bis and turn took longer than expected, which is why I WGLC'd other documents so we could progress them (TCP, p2p-state). BEHAVE's document status is at: http://www.employees.org/behave/document-status.html draft-ietf-behave-p2p-state-02's last call ended yesterday. I have been on vacation the last 4 days and will be reviewing the comments received during last call over the next few days. Rohan submitted turn-03 and it should be posted shortly. As you saw, ICMP-03 was recently submitted. I have not yet built the agenda for IETF, but I know that rfc3489bis, TURN-03, p2p-state, and ICMP will certainly be on the agenda. We will also be talking about our "Submit a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches" milestone, as no-one has commented on adopting draft-ford-behave-app to meet this milestone. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 07 15:55: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 1HP3A6-00074p-U2; Wed, 07 Mar 2007 15:55:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35m-0001v5-5W; Wed, 07 Mar 2007 15:50:34 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HP35l-0007JR-QB; Wed, 07 Mar 2007 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D21D22ACD5; Wed, 7 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35G-000300-Bv; Wed, 07 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --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 : Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-03.txt Pages : 44 Date : 2007-3-7 This specification defines a usage of the Simple Traversal Underneath NAT (STUN) Protocol for asking the STUN server to relay packets towards a client. This usage is useful for elements behind NATs whose mapping behavior is address and port dependent. The extension purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-03.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-turn-03.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-turn-03.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-3-7111815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7111815.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 Mar 07 18:22: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 1HP5SH-0005VJ-V8; Wed, 07 Mar 2007 18:21:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP53V-0006T4-OV for behave@ietf.org; Wed, 07 Mar 2007 17:56:21 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP3mq-0007jK-QZ for behave@ietf.org; Wed, 07 Mar 2007 16:35:08 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2007 13:35:04 -0800 X-IronPort-AV: i="4.14,261,1170662400"; d="scan'208"; a="398377980:sNHT43581996" 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 l27LZ4bP014588 for ; Wed, 7 Mar 2007 13:35:04 -0800 Received: from dwingwxp (dhcp-128-107-101-171.cisco.com [128.107.101.171]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l27LZ4xR017775 for ; Wed, 7 Mar 2007 21:35:04 GMT From: "Dan Wing" To: Date: Wed, 7 Mar 2007 13:35:04 -0800 Message-ID: <0f2e01c76100$77cdaa90$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdhAHeSEDs0y6wDR6uQdGY6DXLPHA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1349; t=1173303304; x=1174167304; 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:=20draft=20BEHAVE=20agenda=20posted |Sender:=20; bh=qLiQOKzu0PAxRqxChxLX4opJxaEBMdJeGtHX4gQ4t5M=; b=QN6/efjfV70Y5rgVU3Eg3P97S29nZCxTWuCYunls3a/2dVOABocTrfJkfo7rRMigt2TEc9SL w1kUuATn03Bya/RP7W+TygaIl/SNCimqX6UK7cL2zaibbrXzfCzixYtd; 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [BEHAVE] draft BEHAVE agenda 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 Draft agenda has been posted here and pasted below: http://www3.ietf.org/proceedings/07mar/agenda/behave.html Please email me with corrections or additions. -d ----- BEHAVE Agenda -- IETF 68, Prague THURSDAY, March 22, 2007, 13:00-15:00 (agenda last revised 2007-03-07 13:20 PST) Chair: Dan Wing, dwing@cisco.com 13:00 Agenda, milestones, and document status, Dan Wing (20 mins) milestones adjusted RFC4787, NAT UDP published draft-ietf-behave-tcp-04, in IESG processing draft-ietf-behave-p2p-state-02, WGLC'd Application behavior milestone (draft-ford-behave-app-05 is the candidate document) 13:20 RFC3489bis, Jonathan Rosenberg (15 mins) draft-ietf-behave-rfc3489bis-05 status: issued WGLC, received a ton of comments 13:35 TURN, Rohan Mahy (15 mins) draft-ietf-behave-turn-03 13:50 NAT Behavior Discovery, Derek MacDonald (10 mins) draft-ietf-behave-nat-behavior-discovery 14:00 ICMP, Dan Wing (10 mins) draft-ietf-behave-nat-icmp-03 Status: nearing WGLC _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 08 15:51: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 1HPPZk-0007nE-4g; Thu, 08 Mar 2007 15:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPYq-0006os-Oy; Thu, 08 Mar 2007 15:50:04 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPYq-0007bH-5e; Thu, 08 Mar 2007 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A0F8A26F0F; Thu, 8 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007GT-8n; Thu, 08 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-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 : Session Traversal Utilities for (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-06.txt Pages : 61 Date : 2007-3-8 Session Traversal Utilities for NAT (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. It allows a client to determine the IP address and port allocated to them by a NAT and to keep NAT bindings open. It can also serve as a check for connectivity between a client and a server in the presence of NAT, and for the client to detect failure of the server. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-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-rfc3489bis-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-rfc3489bis-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-3-8115118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8115118.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 Fri Mar 09 04:06: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 1HPb35-0003kY-MU; Fri, 09 Mar 2007 04:06:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPQWB-0001Dy-5x for behave@ietf.org; Thu, 08 Mar 2007 16:51:23 -0500 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPQW5-0008W1-Ig for behave@ietf.org; Thu, 08 Mar 2007 16:51:23 -0500 Received: from [84.209.225.83] (helo=[192.168.1.131]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1HPQW0-00077q-7Q; Thu, 08 Mar 2007 21:51:12 +0000 Message-ID: <45F0859F.50509@db.org> Date: Thu, 08 Mar 2007 22:52:31 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------080401080402010806020509" X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 is a multi-part message in MIME format. --------------080401080402010806020509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi thanks for this update. I noticed that this version of the draft is almost identical to bis05? my major comment is: The initial STUN Attributes are: 0x8023: FINGERPRINT 0x8022: SERVER 0x8023: ALTERNATE-SERVER 0x8024: REFRESH-INTERVAL FINGERPRINT and ALTERNATE-SERVER values are conflicting. additional comments from bis05 review attached. /alfred Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > Title : Session Traversal Utilities for (NAT) (STUN) > Author(s) : J. Rosenberg, et al. > Filename : draft-ietf-behave-rfc3489bis-06.txt > Pages : 61 > Date : 2007-3-8 > > Session Traversal Utilities for NAT (STUN) is a lightweight protocol > that serves as a tool for application protocols in dealing with NAT > traversal. It allows a client to determine the IP address and port > allocated to them by a NAT and to keep NAT bindings open. It can > also serve as a check for connectivity between a client and a server > in the presence of NAT, and for the client to detect failure of the > server. STUN works with many existing NATs, and does not require any > special behavior from them. As a result, it allows a wide variety of > applications to work through existing NAT infrastructure. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-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-rfc3489bis-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-rfc3489bis-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave --------------080401080402010806020509 Content-Type: text/plain; name="comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="comments.txt" Comments on draft-ietf-behave-rfc3489bis-06 > Section 11.13 REFRESH-INTERVAL > > that are being used for keepalives. The REFRESH-INTERVAL provies a > ^^^^^^^ typo - should be "provides" > Section 11.13 REFRESH-INTERVAL > > represents an interval measured in millseconds. It can be present in > ^^^^^^^^^^^ typo - should be "milliseconds" > Section 9.1.1. Receive Request Message > > generate an error response which includes an ERROR-CORE attribute > ^^^^^^^^^^ typo? I think this should be "ERROR-CODE".. > Section 15.2. STUN Attribute Registry > > 0x8023: FINGERPRINT > 0x8022: SERVER > 0x8023: ALTERNATE-SERVER > 0x8024: REFRESH-INTERVAL it seems like the FINGERPRINT and ALTERNATE-SERVER have got the same value (0x8023) ? --------------080401080402010806020509 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 --------------080401080402010806020509-- From behave-bounces@ietf.org Fri Mar 09 11:57: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 1HPiOy-0001s9-SX; Fri, 09 Mar 2007 11:57:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPiOx-0001s1-Ev for behave@ietf.org; Fri, 09 Mar 2007 11:57:07 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPiOv-0001Ya-5H for behave@ietf.org; Fri, 09 Mar 2007 11:57:07 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 984C35C01E for ; Fri, 9 Mar 2007 09:08:04 -0800 (PST) To: behave@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Fri, 09 Mar 2007 08:57:02 -0800 From: Eric Rescorla Message-Id: <20070309170804.984C35C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Subject: [BEHAVE] Review of draft-ietf-behave-p2p-state-02 X-BeenThere: behave@ietf.org X-Mailman-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 $Id: draft-ietf-behave-p2p-state-02-rev.txt,v 1.1 2007/03/05 19:15:29 ekr Exp $ BACKGROUND This document is a survey of techniques used by various peer-to-peer applications to traverse NAT devices. GENERAL COMMENTS The use of the term "peer-to-peer" is not particularly helpful here. First, it has negative connotations due to its association with filesharing protocols. Second, these techniques are useful even in applications which are not classically P2P. The discussion of the various abstract techniques seems to be weirdly in a vacuum, with the discussions of the concrete techniques (ICE, STUN) relegated mostly to a "Recent Work" section. Since a number of these protocols have been or are standardized in IETF, it would be far more appropriate/useful to discuss them directly. The diagrams are way too dense and quite hard to read. IMO the problem here is that the topologies and the messages are intermixed. I would use separate topologies and ladder diagrams. The concept of P2P-friendly strikes me as negatively useful. Either it's synonymous with Address-Independent Mapping or it doesn't appear to be operationally defined. In either case, I don't see the point of introducing the term. DETAILED COMMENTS S 2. Readers are urged to refer [NAT-TERM] for information on NAT taxonomy and terminology. Traditional NAT [NAT-TRAD] is the most common type of NAT device deployed. Traditional NAT has two main variations - Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT is by far the most commonly deployed NAT device. NAPT allows multiple internal hosts to share a single public IP address simultaneously. When an internal host opens an outgoing TCP or UDP session through a NAPT, the NAPT assigns the session a public IP address and port number so that subsequent response packets from the external endpoint can be received by the NAPT, translated, and forwarded to the internal host. Unless specified otherwise, the term NAT in this document simply refers to Traditional NAT. This seems awkward. We're concerned almost exclusively with NAPT, so why the term Traditional NAT? Are there sections of the document where we're *not* using NAT to refer to Traditional NAT. S 2.1. An endpoint is a session specific tuple on an end host. An endpoint may be represented differently for each IP protocol. For example, a TCP session endpoint is represented as a tuple of (IP Address, TCP port), and a UDP session endpoint is represented as a tuple of (IP Address, UDP Port). Wouldn't it be simpler to just say (IP address, UDP/TCP port)? S 2.2. I think some consistent terminology would help here. In S 2 you write: simultaneously. When an internal host opens an outgoing TCP or UDP session through a NAPT, the NAPT assigns the session a public IP address and port number so that subsequent response packets from the external endpoint can be received by the NAPT, translated, and forwarded to the internal host. Here the term "external endpoint" seems to mean the machine out on the Internet you're talking to. Then in S 2 you write: When a host in a private realm initiates an outgoing session to a host in the public realm through a NAT device, the NAT device assigns an external endpoint to translate the private endpoint so And the "external endpoint" appears to be the transport address on the exterior of hte NAT. This is confusing--and occurs throughout the doc. S 2.3. Isn't this section duplicative of definitions in RFC 4787? The paragraph here would be better as a bulleted list. Why are you referring to "Cone" NATs here? These terms are deprecated. Given how close the IP addresses are here, maybe break up the port #s into two ranges to help readability. S 2.4. Isn't this also duplicative. This would be better as bullets. S 2.7. A P2P application is an application that uses the same endpoint to initiate outgoing sessions to peering hosts as well as accept incoming sessions from peering hosts. Hmm... DNS often initiates zone transfers from port 53. S 2.8. I'm not sure "NAT-friendly" is that helpful a term: 1. In many cases people are trying to workaround the NAT. Holepunching isn't really "friendly" 2. I'm not sure the definition is actually correct: A NAT-friendly P2P application registers with a well-known rendezvous server, used for node registration and peer node discovery purposes. Pursuant to registering with rendezvous server, a P2P-friendly application uses its private endpoint, public endpoint, or a combination thereof to establish peering sessions. One could imagine doing a DHT-based P2P app which registered with dynamic rather than well-known rendezvous servers and it would still traverse NATs just fine. S 3.2. 10.0.0.1 is not a publicly routable IP address. In the second case, the TCP SYN request from B will arrive at NAT A directed to port 62000, but NAT A will reject the connection request because only outgoing connections are allowed. This seems to rely on some unstated assumptions about this NAT. If the NAT device employs Endpoint-Independent Mapping, the public Client can contact external server S to determine the specific public endpoint from which to expect Client-A originated connection. That would be P2P-friendly. However, if the NAT device What does "that" refer to? S 3.3.1. The registry messages here don't seem to do anything very useful. S 3.3.2. It seems extremely strange not to discuss ICE--the protocol that the IETF is standardizing to do this job--in this section. S 3.3.4. This section doesn't seem to me to add much. S 3.4. You need to add some sort of bridge here to the fact that you're now talking about TCP. In particular, if the NAT device has just recently seen and transmitted an outgoing SYN packet with the same addresses and port numbers, then it will consider the session active and allow the incoming SYN through. If clients A and B can Well, maybe. Some firewalls certainly don't do all this and there's no requirement that NATs do so either... You could, for instance, look for the ACK bit.. S 3.5. It's probably worth explaining here why the sequence is predictable, namely that ports are assinged in sequence. It would probably also help to break the second para into a list. Since in practice a P2P application implementing this trick would still need to work even when one of the NATs employ Endpoint-Independent Mapping, the application would need to detect beforehand what kind of NAT is involved on either end and modify its behavior accordingly, increasing the complexity of the algorithm and the general brittleness of the network. How does this happen? S 3.6. This is a variant of the "Simultaneous TCP open" technique that allows peer-to-peer TCP sessions to be created in the presence of some NATs employing Address-Dependent Mapping. Yes? You need to explain what the variiant is. Unfortunately, this trick may be even more fragile and timing- sensitive than the UDP port number prediction trick described earlier. First, even as both NAT devices implement Endpoint-Independent Mapping on the TCP traffic, all the same things can go wrong with each side's attempt to predict the public port numbers that the respective NATs will assign to the new sessions can happen with TCP port prediction as well. I don't understand this sentence. S 4. The results indicate that UDP hole punching is widely supported on more than 80% of the NAT devices, whereas TCP hole punching is supported on just over 60% of the NAT devices tested. The word "supported" seems strange here. Rather, it works, but it's not clear that the support is explicit. The discussion of the various concrete techniques should be moved to the main text. S 5.2. NATs Employing Endpoint-Dependent Mapping gained popularity with client-server applications such as web browsers, which only need to initiate outgoing connections. However, in the recent times, P2P I'm not sure what this sentence is trying to say. Endpoint-Dependent mapping wasn't necessary for Web browsers, just that it wasn't a problem. S 5.4. This sectin appears to be weirdly quasi-normative in terms of suggesting that NATs behave a certain way. Is that consistent with the purpose of this document? S 6.1. Somewhere shouldn't this say you should be using crypto? S 6.2. Again, this section seems semi-normative. Also, some mention of ICE as a defense against this semes appropriate. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Mar 09 16: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 1HPmpN-0003KD-Dj; Fri, 09 Mar 2007 16:40:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmpM-0003K7-8c for behave@ietf.org; Fri, 09 Mar 2007 16:40:40 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPmpH-0002Q6-W1 for behave@ietf.org; Fri, 09 Mar 2007 16:40:40 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Mar 2007 16:40:36 -0500 X-IronPort-AV: i="4.14,268,1170651600"; d="scan'208"; a="115285940:sNHT45767064" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l29LeZ9Q015168 for ; Fri, 9 Mar 2007 16:40:35 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l29LeRZV005646 for ; Fri, 9 Mar 2007 21:40:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 16:40:28 -0500 Received: from [192.168.1.104] ([10.86.243.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 16:40:28 -0500 Message-ID: <45F1D44A.80701@cisco.com> Date: Fri, 09 Mar 2007 16:40:26 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2007 21:40:28.0221 (UTC) FILETIME=[8DCEE6D0:01C76293] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1938; t=1173476435; x=1174340435; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20My=20apologies=20to=20the=20BEHAVE=20working=20group=20on=20r fc3489bis-06 |Sender:=20 |To:=20behave@ietf.org; bh=fgtM7wdNlI/1oLn4aIAghnHo/+jhSjI7d2qFf2TYLrg=; b=TEeSuZjQ5p47OdUdVeB3RWBRF0tPWumULZDu8J+fXxwSaOelQOWVF8xUCpBVHbb67y2c2dJU DI7rpVl+ipXTdsdjv8yyQxnl5y5aNGy9o+h4MjSbTozthThvCo737A7+; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [BEHAVE] My apologies to the BEHAVE working group on rfc3489bis-06 X-BeenThere: behave@ietf.org X-Mailman-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 As folks have already pointed out, rfc3489bis-06 is only slightly different than -05. The only substantive change was to fix the egregious bitfield error in the diagrams. For this, I have to apologize. Tons of comments were made on bis-05, some of them now months old, and I have not yet gotten to them. The fact is that some changes at my day-job ate seriously into IETF time, and I was not able to get to this in a proper way. I had only time for major, major work on one draft, and I chose to allocate that time to ICE instead of rfc3489bis. I am planning to dedicate time this coming week to rfc3489bis, and begin to incorporate comments into a working -07 which I will make available on my site. I hope to have at least some portion of the comments incorporated into that -07 so that there is demonstrable progress on this document. It would be IMMENSELY helpful to me, if those who have already made comments that I have not addressed, can separate out of their comments anything which is a protocol error, bug, inconsistency in the spec or an open issue you feel needs to be discussed, and send that to me privately or to the list at your discretion. One of the problems is that there are probably close to 500 or so comments in the various emails, and this is a staggering piece of work that is hard to attack. By having folks raise the big issues to the top it will help, and I can immediately address those in the working -07. I'd asked folks to really be conservative here and escalate whats really important. Thanks and my apologies, 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 Fri Mar 09 16:50: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 1HPmya-0005m1-GL; Fri, 09 Mar 2007 16:50:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmyY-0005lk-TJ for behave@ietf.org; Fri, 09 Mar 2007 16:50:11 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPmyR-0002Y4-K5 for behave@ietf.org; Fri, 09 Mar 2007 16:50:10 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Mar 2007 16:50:04 -0500 X-IronPort-AV: i="4.14,268,1170651600"; d="scan'208"; a="115286724:sNHT54936568" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l29Lo3JD018820; Fri, 9 Mar 2007 16:50:03 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l29LnwZZ007794; Fri, 9 Mar 2007 21:50:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 16:49:53 -0500 Received: from [192.168.1.104] ([10.86.243.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 16:49:53 -0500 Message-ID: <45F1D67F.6050800@cisco.com> Date: Fri, 09 Mar 2007 16:49:51 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alfred E. Heggestad" Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt References: <45F0859F.50509@db.org> In-Reply-To: <45F0859F.50509@db.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2007 21:49:53.0625 (UTC) FILETIME=[DED0B490:01C76294] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5535; t=1173477003; x=1174341003; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20I-D=20ACTION=3Adraft-ietf-behave-rfc3489bi s-06.txt |Sender:=20 |To:=20=22Alfred=20E.=20Heggestad=22=20; bh=zGvnzIAY0/vtL1tl635jlDdzEioy65+ZQYBHfsaC2t4=; b=Y6oDt/aQVCCHnBUOnsqJsgLv+c+vVhzh/SKgB7Eta+uFm5Fd/IRjCU2qKywTLUCGHaE8J2El 1nKd0icnNUp/HfUpfPqxFNmWzH6b16kn/qAPZFkWTTYi3zJHfN+KAmEy; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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 inline. Alfred E. Heggestad wrote: > Hi > > thanks for this update. I noticed that this version of the draft > is almost identical to bis05? Yes, unfortunately. See my other note to behave on this. > > my major comment is: > > The initial STUN Attributes are: > > 0x8023: FINGERPRINT > 0x8022: SERVER > 0x8023: ALTERNATE-SERVER > 0x8024: REFRESH-INTERVAL > > FINGERPRINT and ALTERNATE-SERVER values are conflicting. Right. I've moved FINGERPRINT to 0x8028. I think this happened because fingerprint used to be in the mandatory range and we had to move it into the optional one in -05. Looks like 0x8026 and 27 were taken by the discovery usage, so I grabbed 0x8028. > > additional comments from bis05 review attached. I've now addressed them in my working -07. Thanks for your patience, Jonathan R. > > > /alfred > > Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Behavior Engineering for Hindrance >> Avoidance Working Group of the IETF. >> >> Title : Session Traversal Utilities for (NAT) (STUN) >> Author(s) : J. Rosenberg, et al. >> Filename : draft-ietf-behave-rfc3489bis-06.txt >> Pages : 61 >> Date : 2007-3-8 >> >> Session Traversal Utilities for NAT (STUN) is a lightweight protocol >> that serves as a tool for application protocols in dealing with NAT >> traversal. It allows a client to determine the IP address and port >> allocated to them by a NAT and to keep NAT bindings open. It can >> also serve as a check for connectivity between a client and a server >> in the presence of NAT, and for the client to detect failure of the >> server. STUN works with many existing NATs, and does not require any >> special behavior from them. As a result, it allows a wide variety of >> applications to work through existing NAT infrastructure. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-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-rfc3489bis-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-rfc3489bis-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. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > > > > > ------------------------------------------------------------------------ > > Comments on draft-ietf-behave-rfc3489bis-06 > > > >>Section 11.13 REFRESH-INTERVAL >> >> that are being used for keepalives. The REFRESH-INTERVAL provies a >> ^^^^^^^ > > > typo - should be "provides" > > > > > >>Section 11.13 REFRESH-INTERVAL >> >> represents an interval measured in millseconds. It can be present in >> ^^^^^^^^^^^ > > > typo - should be "milliseconds" > > > > > >>Section 9.1.1. Receive Request Message >> >> generate an error response which includes an ERROR-CORE attribute >> ^^^^^^^^^^ > > > typo? I think this should be "ERROR-CODE".. > > > > > >>Section 15.2. STUN Attribute Registry >> >> 0x8023: FINGERPRINT >> 0x8022: SERVER >> 0x8023: ALTERNATE-SERVER >> 0x8024: REFRESH-INTERVAL > > > > it seems like the FINGERPRINT and ALTERNATE-SERVER have got > the same value (0x8023) ? -- 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 Fri Mar 09 19: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 1HPprk-0006Rn-Qr; Fri, 09 Mar 2007 19:55:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPprj-0006Rh-3Z for behave@ietf.org; Fri, 09 Mar 2007 19:55:19 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPprd-0005VL-GW for behave@ietf.org; Fri, 09 Mar 2007 19:55:19 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2007 16:55:13 -0800 X-IronPort-AV: i="4.14,269,1170662400"; d="scan'208"; a="119733397:sNHT50658786" 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 l2A0tCkW010597; Fri, 9 Mar 2007 16:55:12 -0800 Received: from dwingwxp ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2A0su1U001086; Sat, 10 Mar 2007 00:55:12 GMT From: "Dan Wing" To: "'Jonathan Rosenberg'" , "'Alfred E. Heggestad'" Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt Date: Fri, 9 Mar 2007 16:55:12 -0800 Message-ID: <0d3001c762ae$c2c217c0$70a36b80@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: <45F1D67F.6050800@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdilQ/q/XjAR4+HTwKf5eeFBWe2twAGVW6Q DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6492; t=1173488112; x=1174352112; 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]=20I-D=20ACTION=3Adraft-ietf-behave-rfc3489bi s-06.txt |Sender:=20; bh=ly2PXVGnc9NQWzOU3RP+ed/Xwqb3kSRUeX+xkmcQuVc=; b=Ru8FOMzoen9jc/+HfCeqbHxhoBHPsnlCJN0shppBt8IzO5L2bPpeoqH7hXs7T9YSAO5mXumn qDbYINEzmuWGn4lNAkmnOLrKrRQlM1LRq2wa7gfGGEE4xWp0c4ywWN4o; 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: bc6181926481d86059e678c9f7cb8b34 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 Jonathan, http://www.employees.org/behave/stun-attributes.html has been updated accordingly. -d > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Friday, March 09, 2007 1:50 PM > To: Alfred E. Heggestad > Cc: behave@ietf.org > Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt > > inline. > > Alfred E. Heggestad wrote: > > > Hi > > > > thanks for this update. I noticed that this version of the draft > > is almost identical to bis05? > > Yes, unfortunately. See my other note to behave on this. > > > > > my major comment is: > > > > The initial STUN Attributes are: > > > > 0x8023: FINGERPRINT > > 0x8022: SERVER > > 0x8023: ALTERNATE-SERVER > > 0x8024: REFRESH-INTERVAL > > > > FINGERPRINT and ALTERNATE-SERVER values are conflicting. > > Right. I've moved FINGERPRINT to 0x8028. I think this > happened because > fingerprint used to be in the mandatory range and we had to > move it into > the optional one in -05. Looks like 0x8026 and 27 were taken by the > discovery usage, so I grabbed 0x8028. > > > > > additional comments from bis05 review attached. > > I've now addressed them in my working -07. > > Thanks for your patience, > Jonathan R. > > > > > > > /alfred > > > > Internet-Drafts@ietf.org wrote: > > > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Behavior Engineering for > Hindrance > >> Avoidance Working Group of the IETF. > >> > >> Title : Session Traversal Utilities for (NAT) (STUN) > >> Author(s) : J. Rosenberg, et al. > >> Filename : draft-ietf-behave-rfc3489bis-06.txt > >> Pages : 61 > >> Date : 2007-3-8 > >> > >> Session Traversal Utilities for NAT (STUN) is a > lightweight protocol > >> that serves as a tool for application protocols in > dealing with NAT > >> traversal. It allows a client to determine the IP > address and port > >> allocated to them by a NAT and to keep NAT bindings > open. It can > >> also serve as a check for connectivity between a client > and a server > >> in the presence of NAT, and for the client to detect > failure of the > >> server. STUN works with many existing NATs, and does > not require any > >> special behavior from them. As a result, it allows a > wide variety of > >> applications to work through existing NAT infrastructure. > >> > >> A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489b > is-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-rfc3489bis-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-rfc3489bis-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. > >> > >> > >> > -------------------------------------------------------------- > ---------- > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > Comments on draft-ietf-behave-rfc3489bis-06 > > > > > > > >>Section 11.13 REFRESH-INTERVAL > >> > >> that are being used for keepalives. The > REFRESH-INTERVAL provies a > >> ^^^^^^^ > > > > > > typo - should be "provides" > > > > > > > > > > > >>Section 11.13 REFRESH-INTERVAL > >> > >> represents an interval measured in millseconds. It can > be present in > >> ^^^^^^^^^^^ > > > > > > typo - should be "milliseconds" > > > > > > > > > > > >>Section 9.1.1. Receive Request Message > >> > >> generate an error response which includes an ERROR-CORE attribute > >> ^^^^^^^^^^ > > > > > > typo? I think this should be "ERROR-CODE".. > > > > > > > > > > > >>Section 15.2. STUN Attribute Registry > >> > >> 0x8023: FINGERPRINT > >> 0x8022: SERVER > >> 0x8023: ALTERNATE-SERVER > >> 0x8024: REFRESH-INTERVAL > > > > > > > > it seems like the FINGERPRINT and ALTERNATE-SERVER have got > > the same value (0x8023) ? > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Mar 12 08:21: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 1HQjVq-0000Yc-U7; Mon, 12 Mar 2007 08:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQjVp-0000YV-Kg for behave@ietf.org; Mon, 12 Mar 2007 08:20:25 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQjVn-0004R8-Mh for behave@ietf.org; Mon, 12 Mar 2007 08:20:25 -0400 Received: (qmail 44735 invoked by uid 60001); 12 Mar 2007 12:19:25 -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=qGJaGJeIHucdkCF6AAIJTeazQNc8Xs9yZ6df8Wpz/zSmTAgcQNJy0MfNKldWLLs5oe2qQYn9vg+GBl5DBb/VTbGONcOlV9s/BVRGA5E2FnBBTLUDZhObJ+/AwsSkAw4NC+rj0+GvfTQB1odJIzRscOmQnxtFyRIVNcwAmDqvYjE=; X-YMail-OSG: 6A7uvAUVM1lIBefeYBQvoYLmvlnyaKqcsps2iYjHnJyQSQIHTu10psh79LPjoKhRHiGMKoDhmX9AJrY2JCss4Fs0SnZYA4g4heZTsYO0X6p5dannLOCzQTwHMKAsT75.gP1vJN.zelU- Received: from [69.236.76.33] by web33312.mail.mud.yahoo.com via HTTP; Mon, 12 Mar 2007 05:19:24 PDT Date: Mon, 12 Mar 2007 05:19:24 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Review of draft-ietf-behave-p2p-state-02 To: Eric Rescorla , behave@ietf.org In-Reply-To: <20070309170804.984C35C01E@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <91885.43519.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Cc: Dan Kegel , 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 Eric, Thank you for your comments. Please see my responses inline. regards, suresh --- Eric Rescorla wrote: > $Id: draft-ietf-behave-p2p-state-02-rev.txt,v 1.1 2007/03/05 19:15:29 ekr Exp > $ > > BACKGROUND > This document is a survey of techniques used by various peer-to-peer > applications to traverse NAT devices. > > GENERAL COMMENTS > The use of the term "peer-to-peer" is not particularly helpful here. > First, it has negative connotations due to its association with > filesharing protocols. Second, these techniques are useful even > in applications which are not classically P2P. > [suresh] There is precedence to using the term "peer-to-peer" in prior behave documents including the most recently published RFC - RFC 4787. > The discussion of the various abstract techniques seems to be weirdly in > a vacuum, with the discussions of the concrete techniques (ICE, STUN) > relegated mostly to a "Recent Work" section. Since a number of these > protocols have been or are standardized in IETF, it would be far > more appropriate/useful to discuss them directly. > [suresh] The document discusses the techniques first. The use of these techniques is reviewed under "Recent Work" section. I will be happy to expand more on the IETF protocols (STUN and ICE), if you like. > The diagrams are way too dense and quite hard to read. IMO the > problem here is that the topologies and the messages are > intermixed. I would use separate topologies and ladder diagrams. > [suresh] I do not understand what you mean by "the topologies and the messages are intermixed" and "use separate topologies and ladder diagrams". What did you mean by "Topology", "message" and "ladder diagram" here? > The concept of P2P-friendly strikes me as negatively useful. Either > it's synonymous with Address-Independent Mapping or it doesn't > appear to be operationally defined. In either case, I don't see > the point of introducing the term. > [suresh] "P2P-friendly NAT" is used to refer a "NAT employing Endpoint Independent Mapping". I could get rid of the term "P2P-friendly NAT" entirely and simply replace this with "NAT employing Endpoint-Independent Mapping", if that works better for you. > > DETAILED COMMENTS > S 2. > Readers are urged to refer [NAT-TERM] for information on NAT > taxonomy and terminology. Traditional NAT [NAT-TRAD] is the most > common type of NAT device deployed. Traditional NAT has two main > variations - Basic NAT and Network Address Port Translator (NAPT). > Of these, NAPT is by far the most commonly deployed NAT device. NAPT > allows multiple internal hosts to share a single public IP address > simultaneously. When an internal host opens an outgoing TCP or UDP > session through a NAPT, the NAPT assigns the session a public IP > address and port number so that subsequent response packets from > the external endpoint can be received by the NAPT, translated, and > forwarded to the internal host. Unless specified otherwise, the > term NAT in this document simply refers to Traditional NAT. > > This seems awkward. We're concerned almost exclusively with > NAPT, so why the term Traditional NAT? [suresh] The techniques are not exclusive to NAPT. The techniques apply to both "Basic NAT" and "NAPT". Hence the reference to traditional NAT. > Are there sections > of the document where we're *not* using NAT to refer to Traditional > NAT. > [suresh] The sentence "Unless specified otherwise, the term NAT in this document simply refers to Traditional NAT" is a customary way to cover the case where the text might evolve to refer other types of NAT. For example, I do refer to "Twice NAT" in the text. > > S 2.1. > An endpoint is a session specific tuple on an end host. An endpoint > may be represented differently for each IP protocol. For example, > a TCP session endpoint is represented as a tuple of (IP Address, > TCP port), and a UDP session endpoint is represented as a tuple > of (IP Address, UDP Port). > > Wouldn't it be simpler to just say (IP address, UDP/TCP port)? > [suresh] Yes, That would be right for a TCP/UDP session. I will simplify the text. Thanks. > S 2.2. > I think some consistent terminology would help here. In S 2 you write: > > simultaneously. When an internal host opens an outgoing TCP or UDP > session through a NAPT, the NAPT assigns the session a public IP > address and port number so that subsequent response packets from > the external endpoint can be received by the NAPT, translated, and > forwarded to the internal host. > > Here the term "external endpoint" seems to mean the machine out on > the Internet you're talking to. > [suresh] Yes. > Then in S 2 you write: > > When a host in a private realm initiates an outgoing session to a > host in the public realm through a NAT device, the NAT device > assigns an external endpoint to translate the private endpoint so > > And the "external endpoint" appears to be the transport address on the > exterior of hte NAT. This is confusing--and occurs throughout the > doc. > [suresh] OK, I will use "public endpoint" to refer NAT assigned public endpoint. The above text will read now as follows. I will fix the text accordignly wherever there is this potential confusion. When a host in a private realm initiates an outgoing session to a host in the public realm through a NAT device, the NAT device assigns a public endpoint to translate the private endpoint so > > S 2.3. > Isn't this section duplicative of definitions in RFC 4787? > [suresh] No. I restate the definition from RFC 4787 and illustrate with an example. > The paragraph here would be better as a bulleted list. > [suresh] How do you mean? > Why are you referring to "Cone" NATs here? These terms are deprecated. > [suresh] OK. I will get rid of the reference. > Given how close the IP addresses are here, maybe break up the port > #s into two ranges to help readability. > [suresh] I am not sure I understand the comment. What do you mean by IP addresses being close? These are RFC 3330 addresses (Please see my comment at tahe start of section 2). I do not follow your comment about breaking port #s into two ranges. > > S 2.4. > Isn't this also duplicative. > > This would be better as bullets. > [suresh] I reuse definitions from RFC 4787 to define this term and illustrate with an example. > > S 2.7. > A P2P application is an application that uses the same endpoint to > initiate outgoing sessions to peering hosts as well as accept > incoming sessions from peering hosts. > > Hmm... DNS often initiates zone transfers from port 53. > [suresh] SO, what is your comment here? Are you sayig that DNS-server shoudl be termed a P2P application, even as it has outgoignand incoming sessiosn on the same port? > > S 2.8. > I'm not sure "NAT-friendly" is that helpful a term: > > 1. In many cases people are trying to workaround the NAT. Holepunching > isn't really "friendly" > 2. I'm not sure the definition is actually correct: > > A NAT-friendly P2P application registers with a well-known > rendezvous server, used for node registration and peer node > discovery purposes. Pursuant to registering with rendezvous > server, a P2P-friendly application uses its private endpoint, > public endpoint, or a combination thereof to establish peering > sessions. > > One could imagine doing a DHT-based P2P app which registered with > dynamic rather than well-known rendezvous servers and it would still > traverse NATs just fine. > [suresh] Any rendezvous server in the public domain has to be known apriori to the application. It doesnt matter whether it learns the address of rendezvous server statically or dynamically. Are you objecting to the use of the wording "well-known rendezvous server"? Would it work for you if I replaced the text with "public domain rendezvous server" instead? > S 3.2. > 10.0.0.1 is not a publicly routable IP address. In the second case, > the TCP SYN request from B will arrive at NAT A directed to port > 62000, but NAT A will reject the connection request because only > outgoing connections are allowed. > > This seems to rely on some unstated assumptions about this NAT. > [suresh] A Tradtional NAT rejects incoming sessions. There is no other assumption here. > > If the NAT device employs Endpoint-Independent Mapping, the public > Client can contact external server S to determine the specific > public endpoint from which to expect Client-A originated > connection. That would be P2P-friendly. However, if the NAT device > > What does "that" refer to? > [suresh] Ability of client B to know the public Endpoint of client A from which a connection will be initiated. > > S 3.3.1. > The registry messages here don't seem to do anything very useful. > [suresh] They register public endpoints for the clients in the server. > > S 3.3.2. > It seems extremely strange not to discuss ICE--the protocol that > the IETF is standardizing to do this job--in this section. > [suresh] The document discusses the general techniques involved first. In this case, it is referign to hairpinnin and the need to register private endpoints. When discussing ICE protocol, I will add text indicating its use of this technique. Thanks. > S 3.3.4. > This section doesn't seem to me to add much. > [suresh] Just the caveat on where UDP hole punching fails. > S 3.4. > You need to add some sort of bridge here to the fact that you're > now talking about TCP. > [suresh] DO you have a suggestion? Thanks. > In particular, if the NAT device has just > recently seen and transmitted an outgoing SYN packet with the same > addresses and port numbers, then it will consider the session > active and allow the incoming SYN through. If clients A and B can > > Well, maybe. Some firewalls certainly don't do all this and there's no > requirement that NATs do so either... You could, for instance, look > for the ACK bit.. > [suresh] The next paragraph discusses the caveats. To be more generic, I could replace the following sentence Even as both peering nodes simultaneously initiate continued SYN retransmission attempts, some remote NAT devices might not let the incoming SYNs through if the NAT session is in end-of-session timeout state. with: Even as both peering nodes simultaneously initiate continued SYN retransmission attempts, some remote NAT devices might not let the incoming SYNs through. > > S 3.5. > It's probably worth explaining here why the sequence is predictable, > namely that ports are assinged in sequence. It would probably also > help to break the second para into a list. [suresh] How do you suggest I break the paragraph into a list. What you have in mind? > > Since in practice a P2P application implementing this trick would > still need to work even when one of the NATs employ > Endpoint-Independent Mapping, the application would need to detect > beforehand what kind of NAT is involved on either end and modify its > behavior accordingly, increasing the complexity of the algorithm and > the general brittleness of the network. > > How does this happen? > [suresh] What are you refering to? > > S 3.6. > This is a variant of the "Simultaneous TCP open" technique that > allows peer-to-peer TCP sessions to be created in the presence of > some NATs employing Address-Dependent Mapping. > > Yes? You need to explain what the variiant is. > [suresh] OK, I will add a few lines here. > > Unfortunately, this trick may be even more fragile and timing- > sensitive than the UDP port number prediction trick described > earlier. First, even as both NAT devices implement > Endpoint-Independent Mapping on the TCP traffic, all the same > things can go wrong with each side's attempt to predict the public > port numbers that the respective NATs will assign to the new > sessions can happen with TCP port prediction as well. > > I don't understand this sentence. > [suresh] Essentially, the sentence says - the prediction of a public port number your local NAT would assign could be wrong. > > S 4. > The results indicate that UDP hole punching is widely > supported on more than 80% of the NAT devices, whereas TCP hole > punching is supported on just over 60% of the NAT devices tested. > > The word "supported" seems strange here. Rather, it works, but it's > not clear that the support is explicit. [suresh] I could use the term "works", if that works for you. > > The discussion of the various concrete techniques should be moved to the main > text. > > > S 5.2. > NATs Employing Endpoint-Dependent Mapping gained popularity with > client-server applications such as web browsers, which only need to > initiate outgoing connections. However, in the recent times, P2P > > I'm not sure what this sentence is trying to say. Endpoint-Dependent > mapping wasn't necessary for Web browsers, just that it wasn't a > problem. > [suresh] Would replacing "gained popularity" with "werent a problem" work for you? Thanks. > > S 5.4. > This sectin appears to be weirdly quasi-normative in terms of suggesting > that NATs behave a certain way. Is that consistent with the purpose of > this document? [suresh] Section 5 is merely a summary of observations. There is no recommendation here. This is consistent with the purpose of this document. > > S 6.1. > Somewhere shouldn't this say you should be using crypto? > [suresh] Sure. I will add that. > S 6.2. > Again, this section seems semi-normative. > > Also, some mention of ICE as a defense against this semes appropriate. > [suresh] OK. Thanks. regards, suresh > > -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Mar 12 12:53: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 1HQnli-0004bS-Ta; Mon, 12 Mar 2007 12:53:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnlh-0004aa-Sn for behave@ietf.org; Mon, 12 Mar 2007 12:53:05 -0400 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQnle-0001HP-4A for behave@ietf.org; Mon, 12 Mar 2007 12:53:05 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 12 Mar 2007 09:53:01 -0700 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga001.fm.intel.com with ESMTP; 12 Mar 2007 09:52:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.14,275,1170662400"; d="scan'208"; a="211070003:sNHT1904774725" Received: from hdsmsx411.amr.corp.intel.com ([10.127.2.70]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 09:52:40 -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] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt Date: Mon, 12 Mar 2007 12:52:39 -0400 Message-ID: In-Reply-To: <0d3001c762ae$c2c217c0$70a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt Thread-Index: AcdkxthNt/kMkIKlSzC+CblCaJktag== From: "Gentry, Mark" To: X-OriginalArrivalTime: 12 Mar 2007 16:52:40.0025 (UTC) FILETIME=[D8668C90:01C764C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jonathan, Possible inconsistency: Should XOR-MAPPED-ADDRESS be in the mandatory range? I probably wouldn't ask except that v0.96 of the Vovida STUN server uses 8020h instead of 0020h for XOR-MAPPED-ADDRESS and Wireshark "recognizes" 8020h (not sure about 0020h) as XOR-MAPPED-ADDRESS.=20 -Mark Gentry -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Friday, March 09, 2007 7:55 PM To: 'Jonathan Rosenberg'; 'Alfred E. Heggestad' Cc: behave@ietf.org Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt Jonathan, http://www.employees.org/behave/stun-attributes.html has been updated accordingly. -d =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Friday, March 09, 2007 1:50 PM > To: Alfred E. Heggestad > Cc: behave@ietf.org > Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt >=20 > inline. >=20 > Alfred E. Heggestad wrote: >=20 > > Hi > >=20 > > thanks for this update. I noticed that this version of the draft > > is almost identical to bis05? >=20 > Yes, unfortunately. See my other note to behave on this. >=20 > >=20 > > my major comment is: > >=20 > > The initial STUN Attributes are: > >=20 > > 0x8023: FINGERPRINT > > 0x8022: SERVER > > 0x8023: ALTERNATE-SERVER > > 0x8024: REFRESH-INTERVAL > >=20 > > FINGERPRINT and ALTERNATE-SERVER values are conflicting. >=20 > Right. I've moved FINGERPRINT to 0x8028. I think this=20 > happened because=20 > fingerprint used to be in the mandatory range and we had to=20 > move it into=20 > the optional one in -05. Looks like 0x8026 and 27 were taken by the=20 > discovery usage, so I grabbed 0x8028. >=20 > >=20 > > additional comments from bis05 review attached. >=20 > I've now addressed them in my working -07. >=20 > Thanks for your patience, > Jonathan R. >=20 > >=20 > >=20 > > /alfred > >=20 > > Internet-Drafts@ietf.org wrote: > >=20 > >> A New Internet-Draft is available from the on-line Internet-Drafts=20 > >> directories. > >> This draft is a work item of the Behavior Engineering for=20 > Hindrance=20 > >> Avoidance Working Group of the IETF. > >> > >> Title : Session Traversal Utilities for (NAT) (STUN) > >> Author(s) : J. Rosenberg, et al. > >> Filename : draft-ietf-behave-rfc3489bis-06.txt > >> Pages : 61 > >> Date : 2007-3-8 > >> =20 > >> Session Traversal Utilities for NAT (STUN) is a=20 > lightweight protocol > >> that serves as a tool for application protocols in=20 > dealing with NAT > >> traversal. It allows a client to determine the IP=20 > address and port > >> allocated to them by a NAT and to keep NAT bindings=20 > open. It can > >> also serve as a check for connectivity between a client=20 > and a server > >> in the presence of NAT, and for the client to detect=20 > failure of the > >> server. STUN works with many existing NATs, and does=20 > not require any > >> special behavior from them. As a result, it allows a=20 > wide variety of > >> applications to work through existing NAT infrastructure. > >> > >> A URL for this Internet-Draft is: > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489b > is-06.txt > >> > >> To remove yourself from the I-D Announcement list, send a=20 > message to=20 > >> i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > >> the message. You can also visit=20 > >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your=20 > >> subscription settings. > >> > >> Internet-Drafts are also available by anonymous FTP. Login=20 > with the=20 > >> username "anonymous" and a password of your e-mail address. After=20 > >> logging in, type "cd internet-drafts" and then "get=20 > >> draft-ietf-behave-rfc3489bis-06.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html or=20 > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-06.txt". > >> =20 > >> 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=20 > 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=20 > 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. > >> > >> > >>=20 > -------------------------------------------------------------- > ---------- > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > Comments on draft-ietf-behave-rfc3489bis-06 > >=20 > >=20 > >=20 > >>Section 11.13 REFRESH-INTERVAL > >> > >> that are being used for keepalives. The=20 > REFRESH-INTERVAL provies a > >> ^^^^^^^ > >=20 > >=20 > > typo - should be "provides" > >=20 > >=20 > >=20 > >=20 > >=20 > >>Section 11.13 REFRESH-INTERVAL > >> > >> represents an interval measured in millseconds. It can=20 > be present in > >> ^^^^^^^^^^^ > >=20 > >=20 > > typo - should be "milliseconds" > >=20 > >=20 > >=20 > >=20 > >=20 > >>Section 9.1.1. Receive Request Message > >> > >> generate an error response which includes an ERROR-CORE attribute > >> ^^^^^^^^^^ > >=20 > >=20 > > typo? I think this should be "ERROR-CODE".. > >=20 > >=20 > >=20 > >=20 > >=20 > >>Section 15.2. STUN Attribute Registry > >> > >> 0x8023: FINGERPRINT > >> 0x8022: SERVER > >> 0x8023: ALTERNATE-SERVER > >> 0x8024: REFRESH-INTERVAL > >=20 > >=20 > >=20 > > it seems like the FINGERPRINT and ALTERNATE-SERVER have got > > the same value (0x8023) ? >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > 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 Mar 12 15:07: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 1HQpri-0001It-CE; Mon, 12 Mar 2007 15:07:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQprg-0001Ih-T8 for behave@ietf.org; Mon, 12 Mar 2007 15:07:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQprb-0006mX-VA for behave@ietf.org; Mon, 12 Mar 2007 15:07:24 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2007 12:07:20 -0700 X-IronPort-AV: i="4.14,275,1170662400"; d="scan'208"; a="400331866:sNHT59347920" 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 l2CJ7J6P012266; Mon, 12 Mar 2007 12:07:19 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2CJ7IxR009703; Mon, 12 Mar 2007 19:07:18 GMT From: "Dan Wing" To: "'Gentry, Mark'" , Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt Date: Mon, 12 Mar 2007 12:07:18 -0700 Message-ID: <035201c764d9$a7ece6f0$c3f0200a@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: AcdkxthNt/kMkIKlSzC+CblCaJktagAEkZqw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8715; t=1173726439; x=1174590439; c=relaxed/simple; s=sjdkim8002; 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]=20I-D=20ACTION=3Adraft-ietf-behave-rfc3489bi s-06.txt |Sender:=20; bh=8bTREiSv/JN5Dfp4vTliDXyyA3QTLxSuQWslcuS1zWU=; b=SzM4zX2d/kronRC9n96tO0mhFyp4cekDENjQVWF1hbqB0w3P28FTW0y2EJWKT6Y5U8qvrJhG XcEp1nX7mycs+faxzGEk5W8q5Aj/rK0KqY1DINDQJH/tCe6KNzP9uEl/; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 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 Regarding Wireshark, 0x8020 was used for XOR-MAPPED-ADDRESS in -02 of rfc3489bis: > grep 8020 draft-ietf-behave-rfc3489bis-*.txt draft-ietf-behave-rfc3489bis-02.txt: 0x8020: XOR-MAPPED-ADDRESS draft-ietf-behave-rfc3489bis-03.txt: Note: Version -02 of this Internet Dr aft used 0x8020 for this The XOR-MAPPED-ADDRESS is in the optional range (above 0x7FFF) so that if an RFC3489bis-compliant server sends it to an old client (that is, a client compatible with only RFC3489), the old client will accept the response. Perhaps we could, instead, use the MAGIC-COOKIE to control the server's behavior and have XOR-MAPPED-ADDRESS be in the mandatory range (which does seem to make sense, except for how we achieve backwards compatability). -d > -----Original Message----- > From: Gentry, Mark [mailto:mark.gentry@intel.com] > Sent: Monday, March 12, 2007 9:53 AM > To: behave@ietf.org > Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt > > > Jonathan, > > Possible inconsistency: > > Should XOR-MAPPED-ADDRESS be in the mandatory range? I probably > wouldn't ask except that v0.96 of the Vovida STUN server uses 8020h > instead of 0020h for XOR-MAPPED-ADDRESS and Wireshark > "recognizes" 8020h > (not sure about 0020h) as XOR-MAPPED-ADDRESS. > > -Mark Gentry > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, March 09, 2007 7:55 PM > To: 'Jonathan Rosenberg'; 'Alfred E. Heggestad' > Cc: behave@ietf.org > Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt > > Jonathan, > > http://www.employees.org/behave/stun-attributes.html has been updated > accordingly. > > -d > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Friday, March 09, 2007 1:50 PM > > To: Alfred E. Heggestad > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt > > > > inline. > > > > Alfred E. Heggestad wrote: > > > > > Hi > > > > > > thanks for this update. I noticed that this version of the draft > > > is almost identical to bis05? > > > > Yes, unfortunately. See my other note to behave on this. > > > > > > > > my major comment is: > > > > > > The initial STUN Attributes are: > > > > > > 0x8023: FINGERPRINT > > > 0x8022: SERVER > > > 0x8023: ALTERNATE-SERVER > > > 0x8024: REFRESH-INTERVAL > > > > > > FINGERPRINT and ALTERNATE-SERVER values are conflicting. > > > > Right. I've moved FINGERPRINT to 0x8028. I think this > > happened because > > fingerprint used to be in the mandatory range and we had to > > move it into > > the optional one in -05. Looks like 0x8026 and 27 were taken by the > > discovery usage, so I grabbed 0x8028. > > > > > > > > additional comments from bis05 review attached. > > > > I've now addressed them in my working -07. > > > > Thanks for your patience, > > Jonathan R. > > > > > > > > > > > /alfred > > > > > > Internet-Drafts@ietf.org wrote: > > > > > >> A New Internet-Draft is available from the on-line > Internet-Drafts > > >> directories. > > >> This draft is a work item of the Behavior Engineering for > > Hindrance > > >> Avoidance Working Group of the IETF. > > >> > > >> Title : Session Traversal Utilities for (NAT) (STUN) > > >> Author(s) : J. Rosenberg, et al. > > >> Filename : draft-ietf-behave-rfc3489bis-06.txt > > >> Pages : 61 > > >> Date : 2007-3-8 > > >> > > >> Session Traversal Utilities for NAT (STUN) is a > > lightweight protocol > > >> that serves as a tool for application protocols in > > dealing with NAT > > >> traversal. It allows a client to determine the IP > > address and port > > >> allocated to them by a NAT and to keep NAT bindings > > open. It can > > >> also serve as a check for connectivity between a client > > and a server > > >> in the presence of NAT, and for the client to detect > > failure of the > > >> server. STUN works with many existing NATs, and does > > not require any > > >> special behavior from them. As a result, it allows a > > wide variety of > > >> applications to work through existing NAT infrastructure. > > >> > > >> A URL for this Internet-Draft is: > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489b > > is-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-rfc3489bis-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-rfc3489bis-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. > > >> > > >> > > >> > > -------------------------------------------------------------- > > ---------- > > >> > > >> _______________________________________________ > > >> Behave mailing list > > >> Behave@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/behave > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > Comments on draft-ietf-behave-rfc3489bis-06 > > > > > > > > > > > >>Section 11.13 REFRESH-INTERVAL > > >> > > >> that are being used for keepalives. The > > REFRESH-INTERVAL provies a > > >> > ^^^^^^^ > > > > > > > > > typo - should be "provides" > > > > > > > > > > > > > > > > > >>Section 11.13 REFRESH-INTERVAL > > >> > > >> represents an interval measured in millseconds. It can > > be present in > > >> ^^^^^^^^^^^ > > > > > > > > > typo - should be "milliseconds" > > > > > > > > > > > > > > > > > >>Section 9.1.1. Receive Request Message > > >> > > >> generate an error response which includes an > ERROR-CORE attribute > > >> ^^^^^^^^^^ > > > > > > > > > typo? I think this should be "ERROR-CODE".. > > > > > > > > > > > > > > > > > >>Section 15.2. STUN Attribute Registry > > >> > > >> 0x8023: FINGERPRINT > > >> 0x8022: SERVER > > >> 0x8023: ALTERNATE-SERVER > > >> 0x8024: REFRESH-INTERVAL > > > > > > > > > > > > it seems like the FINGERPRINT and ALTERNATE-SERVER have got > > > the same value (0x8023) ? > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Mar 12 22:07: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 1HQwQB-00023g-4z; Mon, 12 Mar 2007 22:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQwQ9-0001zd-Oq for behave@ietf.org; Mon, 12 Mar 2007 22:07:25 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQwQ6-0001fG-5Q for behave@ietf.org; Mon, 12 Mar 2007 22:07:25 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 78A483A0210B; Mon, 12 Mar 2007 19:07:19 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id B23723A0210A; Mon, 12 Mar 2007 19:07:15 -0700 (PDT) Message-ID: <45F60753.2020902@acm.org> Date: Mon, 12 Mar 2007 19:07:15 -0700 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: "Gentry, Mark" Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 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 Gentry, Mark wrote: > Jonathan, > > Possible inconsistency: > > Should XOR-MAPPED-ADDRESS be in the mandatory range? I probably > wouldn't ask except that v0.96 of the Vovida STUN server uses 8020h > instead of 0020h for XOR-MAPPED-ADDRESS and Wireshark "recognizes" 8020h > (not sure about 0020h) as XOR-MAPPED-ADDRESS. There is two dissectors for STUN in wireshark 0.99.5. The "STUN" dissector is for RFC 3489, augmented with draft-ietf-behave-rfc3489bis-02 and draft-rosenberg-midcom-turn-08. In this dissector, XOR-MAPPED-ADDRESS is defined as 0x8020. The second dissector, named "STUN2", is for draft-ietf-behave-rfc3489bis-05 and defines XOR-MAPPED-ADDRESS as 0x0020. More explanations about the reasons for supporting two dissectors for STUN here: http://www.wireshark.org/lists/wireshark-dev/200612/msg01633.html > > -Mark Gentry > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, March 09, 2007 7:55 PM > To: 'Jonathan Rosenberg'; 'Alfred E. Heggestad' > Cc: behave@ietf.org > Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt > > Jonathan, > > http://www.employees.org/behave/stun-attributes.html has been updated > accordingly. > > -d > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: Friday, March 09, 2007 1:50 PM >> To: Alfred E. Heggestad >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt >> >> inline. >> >> Alfred E. Heggestad wrote: >> >>> Hi >>> >>> thanks for this update. I noticed that this version of the draft >>> is almost identical to bis05? >> Yes, unfortunately. See my other note to behave on this. >> >>> my major comment is: >>> >>> The initial STUN Attributes are: >>> >>> 0x8023: FINGERPRINT >>> 0x8022: SERVER >>> 0x8023: ALTERNATE-SERVER >>> 0x8024: REFRESH-INTERVAL >>> >>> FINGERPRINT and ALTERNATE-SERVER values are conflicting. >> Right. I've moved FINGERPRINT to 0x8028. I think this >> happened because >> fingerprint used to be in the mandatory range and we had to >> move it into >> the optional one in -05. Looks like 0x8026 and 27 were taken by the >> discovery usage, so I grabbed 0x8028. >> >>> additional comments from bis05 review attached. >> I've now addressed them in my working -07. >> >> Thanks for your patience, >> Jonathan R. >> >>> >>> /alfred >>> >>> Internet-Drafts@ietf.org wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Behavior Engineering for >> Hindrance >>>> Avoidance Working Group of the IETF. >>>> >>>> Title : Session Traversal Utilities for (NAT) (STUN) >>>> Author(s) : J. Rosenberg, et al. >>>> Filename : draft-ietf-behave-rfc3489bis-06.txt >>>> Pages : 61 >>>> Date : 2007-3-8 >>>> >>>> Session Traversal Utilities for NAT (STUN) is a >> lightweight protocol >>>> that serves as a tool for application protocols in >> dealing with NAT >>>> traversal. It allows a client to determine the IP >> address and port >>>> allocated to them by a NAT and to keep NAT bindings >> open. It can >>>> also serve as a check for connectivity between a client >> and a server >>>> in the presence of NAT, and for the client to detect >> failure of the >>>> server. STUN works with many existing NATs, and does >> not require any >>>> special behavior from them. As a result, it allows a >> wide variety of >>>> applications to work through existing NAT infrastructure. >>>> >>>> A URL for this Internet-Draft is: >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489b >> is-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-rfc3489bis-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-rfc3489bis-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. >>>> >>>> >>>> >> -------------------------------------------------------------- >> ---------- >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/behave >>> >>> >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> Comments on draft-ietf-behave-rfc3489bis-06 >>> >>> >>> >>>> Section 11.13 REFRESH-INTERVAL >>>> >>>> that are being used for keepalives. The >> REFRESH-INTERVAL provies a >>>> ^^^^^^^ >>> >>> typo - should be "provides" >>> >>> >>> >>> >>> >>>> Section 11.13 REFRESH-INTERVAL >>>> >>>> represents an interval measured in millseconds. It can >> be present in >>>> ^^^^^^^^^^^ >>> >>> typo - should be "milliseconds" >>> >>> >>> >>> >>> >>>> Section 9.1.1. Receive Request Message >>>> >>>> generate an error response which includes an ERROR-CORE attribute >>>> ^^^^^^^^^^ >>> >>> typo? I think this should be "ERROR-CODE".. >>> >>> >>> >>> >>> >>>> Section 15.2. STUN Attribute Registry >>>> >>>> 0x8023: FINGERPRINT >>>> 0x8022: SERVER >>>> 0x8023: ALTERNATE-SERVER >>>> 0x8024: REFRESH-INTERVAL >>> >>> >>> it seems like the FINGERPRINT and ALTERNATE-SERVER have got >>> the same value (0x8023) ? -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Mar 13 15:58: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 1HRD7u-0005gk-6S; Tue, 13 Mar 2007 15:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRD7s-0005en-Mo; Tue, 13 Mar 2007 15:57:40 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRD7q-00068x-50; Tue, 13 Mar 2007 15:57:40 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2DJvbA5046251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2007 13:57:37 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) To: simple@ietf.org, behave@ietf.org Message-Id: <7A9E866C-74BC-4111-8159-2A7B9165110B@nostrum.com> From: Robert Sparks Date: Tue, 13 Mar 2007 14:57:36 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: Subject: [BEHAVE] dealing with the SIMPLE/BEHAVE conflict X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: simple-chairs@tools.ietf.org, behave-chairs@tools.ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0210619390==" Errors-To: behave-bounces@ietf.org --===============0210619390== Content-Type: multipart/alternative; boundary=Apple-Mail-26-87644206 --Apple-Mail-26-87644206 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Please forgive the crosspost. Unless you have a compelling reason to reply to the lists, please reply only to the chairs. SIMPLE and BEHAVE are meeting at the same time. In order to facilitate having the right people in the right place at =20 the right time, we're adjusting the order of topics in the SIMPLE =20 meeting. The current plan is to follow the agenda below. RjS =E2=96=BC 20m - Administrivia and Planning =E2=80=A2 Chairs =E2=96=BC 15m - Deferred Message Disposition Notification =E2=80=A2 Jerry Shih =E2=80=A2 draft-stafford-simple-dmdn-00.txt =E2=96=BC 10m - Sigcomp Presence Dictionary =E2=80=A2 Miguel Garcia =E2=80=A2 draft-garcia-simple-presence-dictionary-02.txt =E2=96=BC 10m - Vehicle Information Event Package =E2=80=A2 Henning Schulzrinne =E2=80=A2 draft-singh-simple-vehicle-info-00.txt =E2=96=BC 20m - Performance and Scaling Analysis =E2=80=A2 Avshalom Houri =E2=80=A2 = draft-ietf-simple-interdomain-scaling-analysis-00.txt =E2=96=BC 30m - Multiparty IM sessions using MSRP =E2=80=A2 Miguel Garcia/Aki Neimi =E2=80=A2 draft-niemi-simple-chat-06.txt =E2=96=BC 5m - Update: XCON IM sessions using MSRP =E2=80=A2 Mary Barnes =E2=80=A2 draft-boulton-xcon-msrp-conferencing-04.txt =E2=96=BC 10m - Establishing MSRP sessions using ICE =E2=80=A2 Aki Neimi =E2=80=A2 draft-niemi-simple-msrp-ice-00.txt --Apple-Mail-26-87644206 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Please forgive the crosspost. = Unless you have a compelling reason to
reply to the lists, please = reply only to the chairs.

SIMPLE and BEHAVE are = meeting at the same time.

In order to facilitate = having the right people in the right place at the right time, we're = adjusting the order of topics in the SIMPLE meeting. The current plan is = to follow the agenda below.

RjS

=E2=96=BC 20m - = Administrivia and Planning
=E2=80=A2 Chairs
=E2=96=BC 15m - Deferred Message = Disposition Notification
=E2=80=A2 Jerry Shih
=E2=80=A2 = draft-stafford-simple-dmdn-00.txt
=E2=96=BC 10m - = Sigcomp Presence Dictionary
=E2=80=A2 Miguel Garcia
=E2=80=A2 = draft-garcia-simple-presence-dictionary-02.txt
=E2=96=BC 10m - Vehicle Information Event = Package
=E2=80=A2 Henning = Schulzrinne
=E2=80=A2 = draft-singh-simple-vehicle-info-00.txt
=E2=96=BC 20m - Performance and Scaling = Analysis
=E2=80=A2 Avshalom = Houri
=E2=80=A2 = draft-ietf-simple-interdomain-scaling-analysis-00.txt
=E2=96=BC 30m - Multiparty IM sessions = using MSRP
=E2=80=A2 Miguel = Garcia/Aki Neimi
=E2=80=A2 = draft-niemi-simple-chat-06.txt
=E2=96=BC 5m - = Update: XCON IM sessions using MSRP
=E2=80=A2 Mary Barnes
=E2=80=A2 = draft-boulton-xcon-msrp-conferencing-04.txt
=E2=96=BC 10m - Establishing MSRP sessions = using ICE
=E2=80=A2 Aki = Neimi
=E2=80=A2 = draft-niemi-simple-msrp-ice-00.txt

= --Apple-Mail-26-87644206-- --===============0210619390== 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 --===============0210619390==-- From behave-bounces@ietf.org Tue Mar 13 20:54: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 1HRHkG-0007yI-Cu; Tue, 13 Mar 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 1HRHkE-0007yC-VA for behave@ietf.org; Tue, 13 Mar 2007 20:53:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRHkA-0006YB-JF for behave@ietf.org; Tue, 13 Mar 2007 20:53:34 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 13 Mar 2007 17:21:09 -0700 X-IronPort-AV: i="4.14,281,1170662400"; d="scan'208"; a="400852743:sNHT25926926816" 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 l2E0L9jY019614; Tue, 13 Mar 2007 17:21:09 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2E0L0aB005778; Wed, 14 Mar 2007 00:21:09 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 20:21:07 -0400 Received: from [192.168.1.104] ([10.86.242.218]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 20:21:07 -0400 Message-ID: <45F73FF2.6000802@cisco.com> Date: Tue, 13 Mar 2007 20:21:06 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-rfc3489bis-06.txt References: <035201c764d9$a7ece6f0$c3f0200a@amer.cisco.com> In-Reply-To: <035201c764d9$a7ece6f0$c3f0200a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 00:21:07.0465 (UTC) FILETIME=[A8E5CF90:01C765CE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2506; t=1173831669; x=1174695669; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20I-D=20ACTION=3Adraft-ietf-behave-rfc3489bi s-06.txt |Sender:=20; bh=sXbsegutxuR7ZYBj8+6TN5jJHb0623d232/N1hIN9g0=; b=fFuuK0Q9R93qwXV4+vFmuKLBKRsdOiurws9gH6iN3mLkOjxGtzfhlALzCpPaqXQxnJrMIynE 37muBNztB6EotmFpy2BkKZQcsg5RfN4dWVW8thoNtegHiWQsGXgC7NCL; Authentication-Results: sj-dkim-7; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: behave@ietf.org, "'Gentry, Mark'" X-BeenThere: behave@ietf.org X-Mailman-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 inline: Dan Wing wrote: > Regarding Wireshark, 0x8020 was used for XOR-MAPPED-ADDRESS in -02 of > rfc3489bis: > > > grep 8020 draft-ietf-behave-rfc3489bis-*.txt > draft-ietf-behave-rfc3489bis-02.txt: 0x8020: XOR-MAPPED-ADDRESS > draft-ietf-behave-rfc3489bis-03.txt: Note: Version -02 of this > Internet Dr > aft used 0x8020 for this > > The XOR-MAPPED-ADDRESS is in the optional range (above 0x7FFF) so that if an > RFC3489bis-compliant server sends it to an old client (that is, a client > compatible with only RFC3489), the old client will accept the response. > > Perhaps we could, instead, use the MAGIC-COOKIE to control the server's > behavior and have XOR-MAPPED-ADDRESS be in the mandatory range (which does > seem to make sense, except for how we achieve backwards compatability). Actually, that is exactly how it works: > If the response is a type which can carry either MAPPED-ADDRESS or > XOR-MAPPED-ADDRESS (the Binding Response as defined in this > specification meets that criteria), the server examines the magic > cookie in the STUN header. If it has the value 0x2112A442, it > indicates that the client supports this version of the specification. > The server MUST insert a XOR-MAPPED-ADDRESS into the response, > carrying the exclusive-or of the source transport address and magic > cookie. If the magic cookie did not have this value, it indicates > that the client supports the previous version of this specification. > The server MUST insert a MAPPED-ADDRESS attribute into the response, > carrying the souce transport address from the request. Insertion of > either XOR-MAPPED-ADDRESS or MAPPED-ADDRESS happens regardless of the > transport protocol used for the request. So we could put it into the mandatory range I suppose. I can't recall why we moved it out of that range in the first place, as I think the above text has been there for a while. Nonetheless, I think its fine as is. I'd rather keep it optional, just in case a server does the wrong thing and sends it (or sends both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS). -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 Wed Mar 14 23:44: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 1HRgsJ-0007ET-TY; Wed, 14 Mar 2007 23:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRgsE-0006jZ-7T for behave@ietf.org; Wed, 14 Mar 2007 23:43:30 -0400 Received: from mx2-7.spamtrap.magma.ca ([209.217.78.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRgoA-0003CF-Vx for behave@ietf.org; Wed, 14 Mar 2007 23:39:23 -0400 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx2-7.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l2F3dBh4022417; Wed, 14 Mar 2007 23:39:12 -0400 Received: from [10.0.1.3] ([24.139.16.154]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id l2F3d9W1028119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Mar 2007 23:39:11 -0400 In-Reply-To: <0e0801c75aba$9089b7f0$5600a8c0@Quinthar> References: <0e0801c75aba$9089b7f0$5600a8c0@Quinthar> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BA6D352-586B-42A6-8D35-D433DFB57BA6@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] NAT Control STUN Usage Date: Wed, 14 Mar 2007 17:37:43 -0400 To: David Barrett , Dan Wing , Lars Eggert , Magnus Westerlund 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.3 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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 Sorry to be coming into this conversation late. I am just catching up on various mailing lists after finishing my drafts. BEHAVE is chartered to work on STUN. STUN requires STUN servers to work, and defined how they behave. Why shouldn't we recommend placing some of the servers into NATs as this draft does? This draft is trying to address the problem of finding the allocated mappings for nested NAT cases. I think this problem is an important one to solve, because nested NATs are becoming more and more common. I think BEHAVE is a good place to work on a solution to this problem, and I think the proposed solution is reasonable. I think it would be silly to NOT solve this problem just because of charter issues. - Philip On 27-Feb-07, at 16:59 , David Barrett wrote: > I agree this would be great. I just think it's not what BEHAVE is > doing. > > BEHAVE is (largely) just specifying what the default configuration > should be > for NATs as they come "out of the box". This is much different than > mandating all NAT vendors build in support for a new control > interface. > > Despite my massive reservations with UPnP, that seems like a much more > appropriate place to add control functionality (because it already > has it), > rather than reinventing an incompatible subset of UPnP under a > different > name. > > -david > >> -----Original Message----- >> From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] >> Sent: Tuesday, February 27, 2007 12:04 PM >> To: Dan Wing; 'Lars Eggert' >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] NAT Control STUN Usage >> >> I think there's a lot of value in this draft simply because it allows >> discovery of multiple levels of NATs. >> >> I'm specifically interested in knowing the 'public' IP addresses >> and keep- >> alive times associated with each NAT. I think that could be >> accomplished >> without attempting to control the keep-alive times in the NATs. >> >> So, it might be possible to skirt charter issues by limiting this >> draft to >> 'discovery' functions and not including 'control' functions. >> >> Best Regards, >> >> Eric. >> >> ----- Original Message ----- >> From: "Dan Wing" >> To: "'Lars Eggert'" >> Cc: >> Sent: Wednesday, February 21, 2007 5:00 PM >> Subject: RE: [BEHAVE] NAT Control STUN Usage >> >> >>>> On 2007-1-12, at 20:09, ext Dan Wing wrote: >>>>> At the San Diego meeting there were positive comments around this >>>>> approach. >>>>> Is there interest in moving this work forward? >>>> >>>> this document takes STUN in a whole new direction (middlebox >>>> control) that would probably require a recharter. >>> >>> I asked Magnus that question offline, and he concurs it doesn't >>> fit within BEHAVE's existing charter. >>> >>>>> Also, the draft says: >>>>> Unlike some other >>>>> techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour >>>>> [Bonjour]), >>>>> STUN does not interact directly with the NAT. Because >>>>> STUN doesn't >>>>> interact directly with the NAT, STUN cannot request additional >>>>> services from the NAT such as longer lifetimes (which >>>>> would reduce keepalive messages). >>>>> >>>>> This paper describes a mechanism for the STUN client to >>>>> interact >>>>> directly with the NAT and request additional services, >>>>> by using the >>>>> STUN protocol itself. >>>> >>>> For a convincing rechartering argument, it'd be very useful to >>>> see a >>>> discussion on why adding this to STUN is significantly better than >>>> the myriad of exiting approaches to control middleboxes. In >>>> addition >>>> to the ones mentioned in the draft, at least NSIS and SIMCO >>>> also exist. >>> >>> -01 added a little more information showing advantages of the NAT >>> Control STUN Usage. We can add a point-by-point comparison of this >>> approach versus NSIS, SIMCO (an implementation of MIDCOM), UPnP, >>> and Bonjour, and ask the community again if there seems to be >>> sufficient merit to this approach versus the other protocols for >>> NAT traversal and NAT control. >>> >>> -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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 15 04:46: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 1HRlaG-00058a-9u; Thu, 15 Mar 2007 04:45:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRlaE-00058Q-O7 for behave@ietf.org; Thu, 15 Mar 2007 04:45:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRla5-0003FO-L2 for behave@ietf.org; Thu, 15 Mar 2007 04:45:14 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E009D214D5; Thu, 15 Mar 2007 09:44:56 +0100 (CET) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-88-45f90788f4f5 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C489721177; Thu, 15 Mar 2007 09:44:56 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:44:56 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:44:56 +0100 Message-ID: <45F90788.6010502@ericsson.com> Date: Thu, 15 Mar 2007 09:44:56 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] NAT Control STUN Usage References: <0e0801c75aba$9089b7f0$5600a8c0@Quinthar> <8BA6D352-586B-42A6-8D35-D433DFB57BA6@magma.ca> In-Reply-To: <8BA6D352-586B-42A6-8D35-D433DFB57BA6@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2007 08:44:56.0143 (UTC) FILETIME=[3501C5F0:01C766DE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: behave@ietf.org, 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 Philip Matthews skrev: > Sorry to be coming into this conversation late. > I am just catching up on various mailing lists after finishing my drafts. > > BEHAVE is chartered to work on STUN. > STUN requires STUN servers to work, and defined how they behave. > Why shouldn't we recommend placing some of the servers into NATs > as this draft does? > > This draft is trying to address the problem of finding the allocated > mappings > for nested NAT cases. I think this problem is an important one to solve, > because nested NATs are becoming more and more common. > > I think BEHAVE is a good place to work on a solution to this problem, > and I think the proposed solution is reasonable. > > I think it would be silly to NOT solve this problem just because of > charter issues. > The problem is that large parts of this problem already has been solved in the numerous NAT control protocols. Even in IETF we have two different WG currently chartered with solving NAT control issues, MIDCOM and NSIS. Going in this new direction for BEHAVE needs IETF wide consensus and also good arguments why previous efforts are not solving the problem. So if you are interested in this issue, please get together and start discussing having a BOF. 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 Fri Mar 16 17:10: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 1HSJgI-0003bW-Sp; Fri, 16 Mar 2007 17:09:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSJgH-0003bQ-Cb for behave@ietf.org; Fri, 16 Mar 2007 17:09:45 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSJgG-0007us-2t for behave@ietf.org; Fri, 16 Mar 2007 17:09:45 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2007 22:09:44 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2GL9h13001629 for ; Fri, 16 Mar 2007 22:09:43 +0100 Received: from [10.0.0.38] (ams3-vpn-dhcp4452.cisco.com [10.61.81.99]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2GL9elZ009716 for ; Fri, 16 Mar 2007 21:09:42 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Behave WG From: Cullen Jennings Date: Fri, 16 Mar 2007 22:08:17 +0100 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1766; t=1174079383; x=1174943383; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-ietf-behave-nat-icmp-03.txt |Sender:=20; bh=0fYPXBiNRdW9d9f88k+NKho6uGsIx6dfqUXVjyVQPxk=; b=DTCM2tbB7YdJzjYOp4VK88hflYAaKVQQUJv+XkX3y35xCvKkMkQEK7DdvLwFW0TIqg6I2Stz YztjOCqgRNmrTKFSGQTEqZKHLgoT2B5Jto+/QNb2/51j6HQe1H+5iwFV; Authentication-Results: ams-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org My recollection of the last meeting was that we were not going to require that NATs MUST forward ICMP packets at all since many firewalls don't do that. However, if they do it, we were describe the requirements on they needed to do. I disagree that a NAT must forward ICMP packets at all - we agree to try and not specify firewall behavior but also we agree not to specify things such that firewalls would automatically not be compliant with behave. RFC 1812 has a lot of stuff in it - NATs are not routers - I doubt that a NAT has to meet all the requirements of a router. For example,from 1812 - "A router MUST NOT reassemble any datagram before forwarding it." NATs are not hosts in all senses of 1122 - for example when they forward a packet from the outside to the inside they violate "When a host sends any datagram, the IP source address MUST be one of its own IP addresses (but not a broadcast or I don't understand how a NAT that does not implement some extension contemplated in ICMP-EXT will be able to correctly translate when forwarding these. I'm not sure there is a problem here - it may all be fine but I don't understand it. Req-6 - I agree with this but it is confusing on how it is written. I'm not sure implementers will be able to understand this. multicast address)." The way 3022 is reference in this draft, it would need to be a normative reference. The terminology is confusing and uses several things we agree not to use because it was confusing. For example, "Basic NAT",etc - I see no need to this document to introduce any new nat terminology There is still normative language in things that are not requirements. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Mar 16 17:33: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 1HSK2b-0000pT-E0; Fri, 16 Mar 2007 17:32:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSK2Z-0000pN-Pa for behave@ietf.org; Fri, 16 Mar 2007 17:32:47 -0400 Received: from mail-2.contactel.cz ([212.65.193.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSK2Y-0001rb-Qc for behave@ietf.org; Fri, 16 Mar 2007 17:32:47 -0400 Received: by mail-2.contactel.cz (Postfix, from userid 503) id ACB8E198A6; Fri, 16 Mar 2007 22:27:57 +0100 (CET) Received: from delta.rtfm.com (unknown [212.47.23.197]) by mail-2.contactel.cz (Postfix) with ESMTP id BA3FF19898 for ; Fri, 16 Mar 2007 22:27:53 +0100 (CET) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 982961CC24; Fri, 16 Mar 2007 00:10:29 -0700 (PDT) To: Pyda Srisuresh Subject: Re: [BEHAVE] Review of draft-ietf-behave-p2p-state-02 In-reply-to: Your message of "Mon, 12 Mar 2007 05:19:24 PDT." <91885.43519.qm@web33312.mail.mud.yahoo.com> X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Fri, 16 Mar 2007 00:10:29 -0700 From: EKR Message-Id: <20070316071029.982961CC24@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 Cc: Dan Kegel , behave@ietf.org, 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 Pyda Srisuresh wrote: > > $Id: draft-ietf-behave-p2p-state-02-rev.txt,v 1.1 2007/03/05 19:15:29 ekr Exp > > $ > > > > BACKGROUND > > This document is a survey of techniques used by various peer-to-peer > > applications to traverse NAT devices. > > > > GENERAL COMMENTS > > The use of the term "peer-to-peer" is not particularly helpful here. > > First, it has negative connotations due to its association with > > filesharing protocols. Second, these techniques are useful even > > in applications which are not classically P2P. > > > [suresh] There is precedence to using the term "peer-to-peer" in prior behave > documents including the most recently published RFC - RFC 4787. Yeah, there's a difference between using the term 6 times in a document and having it as the title of the document and using the term "P2P-friendly", etc. > > The discussion of the various abstract techniques seems to be weirdly in > > a vacuum, with the discussions of the concrete techniques (ICE, STUN) > > relegated mostly to a "Recent Work" section. Since a number of these > > protocols have been or are standardized in IETF, it would be far > > more appropriate/useful to discuss them directly. > > > > [suresh] The document discusses the techniques first. Yes, that's what I'm complaining about. They should be discussed in context. > > The diagrams are way too dense and quite hard to read. IMO the > > problem here is that the topologies and the messages are > > intermixed. I would use separate topologies and ladder diagrams. > > > > [suresh] I do not understand what you mean by "the topologies and the messages > are intermixed" and "use separate topologies and ladder diagrams". What did you > mean by "Topology", "message" and "ladder diagram" here? I mean that the diagrams contain pictures of the network topology as well as a bunch of things with arrows and address endpoints that I guess represent sessions. It would be better to have those removed from the diagram and have separate ladder diagrams (see, for instance, RFC 3261 fig 1) to indicate the dataflow. > > The concept of P2P-friendly strikes me as negatively useful. Either > > it's synonymous with Address-Independent Mapping or it doesn't > > appear to be operationally defined. In either case, I don't see > > the point of introducing the term. > > > > [suresh] "P2P-friendly NAT" is used to refer a "NAT employing Endpoint > Independent Mapping". I could get rid of the term "P2P-friendly NAT" entirely > and simply replace this with "NAT employing Endpoint-Independent Mapping", if > that works better for you. Yes, that would be an improvement. > > DETAILED COMMENTS > > S 2. > > Readers are urged to refer [NAT-TERM] for information on NAT > > taxonomy and terminology. Traditional NAT [NAT-TRAD] is the most > > common type of NAT device deployed. Traditional NAT has two main > > variations - Basic NAT and Network Address Port Translator (NAPT). > > Of these, NAPT is by far the most commonly deployed NAT device. NAPT > > allows multiple internal hosts to share a single public IP address > > simultaneously. When an internal host opens an outgoing TCP or UDP > > session through a NAPT, the NAPT assigns the session a public IP > > address and port number so that subsequent response packets from > > the external endpoint can be received by the NAPT, translated, and > > forwarded to the internal host. Unless specified otherwise, the > > term NAT in this document simply refers to Traditional NAT. > > > > This seems awkward. We're concerned almost exclusively with > > NAPT, so why the term Traditional NAT? > > [suresh] The techniques are not exclusive to NAPT. The techniques apply to both > "Basic NAT" and "NAPT". Hence the reference to traditional NAT. Yes, but most NATs now are NAPT, right? So, this distinction doesn't seem to be doing much work... > > Are there sections > > of the document where we're *not* using NAT to refer to Traditional > > NAT. > > > [suresh] The sentence "Unless specified otherwise, the term NAT in this > document simply refers to Traditional NAT" is a customary way to cover the case > where the text might evolve to refer other types of NAT. For example, I do > refer to "Twice NAT" in the text. It seems to me that twice NAT is orthogonal to "traditional NAT" versus NAPT. Have I missed something? > [suresh] OK, I will use "public endpoint" to refer NAT assigned public > endpoint. The above text will read now as follows. I will fix the text > accordignly wherever there is this potential confusion. > > When a host in a private realm initiates an outgoing session to a > host in the public realm through a NAT device, the NAT device > assigns a public endpoint to translate the private endpoint so And you'll call public endpoints on machines that are Internet accessible "external addresses"? Or... > > S 2.3. > > Isn't this section duplicative of definitions in RFC 4787? > > > [suresh] No. I restate the definition from RFC 4787 and illustrate with an > example. Yeah, I think this should be trimmed. > > The paragraph here would be better as a bulleted list. > > > [suresh] How do you mean? I mean that it's a mass of text that I think would read better as a broken out list of text. > > Given how close the IP addresses are here, maybe break up the port > > #s into two ranges to help readability. > > > [suresh] I am not sure I understand the comment. What do you mean by IP > addresses being close? These are RFC 3330 addresses (Please see my comment at > tahe start of section 2). I do not follow your comment about breaking port #s > into two ranges. I mean that since the IP addresses all come from the same /.24, it's a little confusing to have say (A.1234 be talking to S1.1235). I would make all the clients have (say) 1-1000 and all the servers have (say) 20000-21000. > > S 2.4. > > Isn't this also duplicative. > > > > This would be better as bullets. > > > [suresh] I reuse definitions from RFC 4787 to define this term and illustrate > with an example. Yeah, again I think this is redundant. > > S 2.7. > > A P2P application is an application that uses the same endpoint to > > initiate outgoing sessions to peering hosts as well as accept > > incoming sessions from peering hosts. > > > > Hmm... DNS often initiates zone transfers from port 53. > > > [suresh] SO, what is your comment here? Are you sayig that DNS-server shoudl be > termed a P2P application, even as it has outgoignand incoming sessiosn on the > same port? No, I'm saying that this definition is broken because it says that DNS is a "P2P application" even though that doesn't match standard terminology. > > S 2.8. > > I'm not sure "NAT-friendly" is that helpful a term: > > > > 1. In many cases people are trying to workaround the NAT. Holepunching > > isn't really "friendly" > > 2. I'm not sure the definition is actually correct: > > > > A NAT-friendly P2P application registers with a well-known > > rendezvous server, used for node registration and peer node > > discovery purposes. Pursuant to registering with rendezvous > > server, a P2P-friendly application uses its private endpoint, > > public endpoint, or a combination thereof to establish peering > > sessions. > > > > One could imagine doing a DHT-based P2P app which registered with > > dynamic rather than well-known rendezvous servers and it would still > > traverse NATs just fine. > > > > [suresh] Any rendezvous server in the public domain has to be known apriori to > the application. It doesnt matter whether it learns the address of rendezvous > server statically or dynamically. Are you objecting to the use of the wording > "well-known rendezvous server"? Would it work for you if I replaced the text > with "public domain rendezvous server" instead? "Publicly addressable" seems appropriate. > > If the NAT device employs Endpoint-Independent Mapping, the public > > Client can contact external server S to determine the specific > > public endpoint from which to expect Client-A originated > > connection. That would be P2P-friendly. However, if the NAT device > > > > What does "that" refer to? > > > [suresh] Ability of client B to know the public Endpoint of client A from which > a connection will be initiated. Yeah, I sort of got that. My point was that this should be in the text. > > S 3.3.1. > > The registry messages here don't seem to do anything very useful. > > > > [suresh] They register public endpoints for the clients in the server. I meant that they don't do anything useful in the explanation in the text so that I would remove them for pedagogical clarity > > S 3.3.2. > > It seems extremely strange not to discuss ICE--the protocol that > > the IETF is standardizing to do this job--in this section. > > > [suresh] The document discusses the general techniques involved first. In this > case, it is referign to hairpinnin and the need to register private endpoints. Yes, I think you should integrate the ICE discussion here. > When discussing ICE protocol, I will add text indicating its use of this > technique. Thanks. > > > > S 3.3.4. > > This section doesn't seem to me to add much. > > > [suresh] Just the caveat on where UDP hole punching fails. Maybe you can integrate it into some other section. > > S 3.4. > > You need to add some sort of bridge here to the fact that you're > > now talking about TCP. > > > [suresh] DO you have a suggestion? Thanks. Not sure what you mean. The point is that you just transition from UDP to TCP without warning. Add a paragraph that says that you're now going to talk about TCP. > > In particular, if the NAT device has just > > recently seen and transmitted an outgoing SYN packet with the same > > addresses and port numbers, then it will consider the session > > active and allow the incoming SYN through. If clients A and B can > > > > Well, maybe. Some firewalls certainly don't do all this and there's no > > requirement that NATs do so either... You could, for instance, look > > for the ACK bit.. > > > [suresh] The next paragraph discusses the caveats. To be more generic, I could > replace the following sentence > > Even as both > peering nodes simultaneously initiate continued SYN retransmission > attempts, some remote NAT devices might not let the incoming SYNs > through if the NAT session is in end-of-session timeout state. > > with: > > Even as both > peering nodes simultaneously initiate continued SYN retransmission > attempts, some remote NAT devices might not let the incoming SYNs > through. How about softening the offending sentence instead. > > S 3.5. > > It's probably worth explaining here why the sequence is predictable, > > namely that ports are assinged in sequence. It would probably also > > help to break the second para into a list. > > [suresh] How do you suggest I break the paragraph into a list. What you have in > mind? - NAT A has assigned its own UDP port 62000 to the communication session between A and S. - NAT B has assigned its port 31000 to the session between B and S. - By communicating with server S, A and B learn each other's public IP addresses and port numbers as observed by S. - Client A now starts sending UDP messages to port 31001 at address 192.0.2.254 (note the port number increment), and client B simultaneously starts sending messages to port 62001 at address 192.0.2.1. If NATs A and B assign port numbers to new sessions sequentially, and if not much time has passed since the A-S and B-S sessions were initiated, then a working bi-directional communication channel between A and B should result. A's messages to B cause NAT A to open up a new session, to which NAT A will (hopefully) assign public port number 62001, because 62001 is next in sequence after the port number 62000 it previously assigned to the session between A and S. Similarly, B's messages to A will cause NAT B to open a new session, to which it will (hopefully) assign port number 31001. If both clients have correctly guessed the port numbers each NAT assigns to the new sessions, then a bi-directional UDP communication channel will have been established as shown in figure 9. > > Since in practice a P2P application implementing this trick would > > still need to work even when one of the NATs employ > > Endpoint-Independent Mapping, the application would need to detect > > beforehand what kind of NAT is involved on either end and modify its > > behavior accordingly, increasing the complexity of the algorithm and > > the general brittleness of the network. > > > > How does this happen? > > > [suresh] What are you refering to? How does the application detect beforehand what kind of NAT is involved. > > Unfortunately, this trick may be even more fragile and timing- > > sensitive than the UDP port number prediction trick described > > earlier. First, even as both NAT devices implement > > Endpoint-Independent Mapping on the TCP traffic, all the same > > things can go wrong with each side's attempt to predict the public > > port numbers that the respective NATs will assign to the new > > sessions can happen with TCP port prediction as well. > > > > I don't understand this sentence. > > > [suresh] Essentially, the sentence says - the prediction of a public port > number your local NAT would assign could be wrong. Can you please rewrite to make that clear. > > S 4. > > The results indicate that UDP hole punching is widely > > supported on more than 80% of the NAT devices, whereas TCP hole > > punching is supported on just over 60% of the NAT devices tested. > > > > The word "supported" seems strange here. Rather, it works, but it's > > not clear that the support is explicit. > > [suresh] I could use the term "works", if that works for you. That's fine. > > The discussion of the various concrete techniques should be moved to the main > > text. > > > > > > S 5.2. > > NATs Employing Endpoint-Dependent Mapping gained popularity with > > client-server applications such as web browsers, which only need to > > initiate outgoing connections. However, in the recent times, P2P > > > > I'm not sure what this sentence is trying to say. Endpoint-Dependent > > mapping wasn't necessary for Web browsers, just that it wasn't a > > problem. > > > > [suresh] Would replacing "gained popularity" with "werent a problem" work for > you? Thanks. Sure. > > S 5.4. > > This sectin appears to be weirdly quasi-normative in terms of suggesting > > that NATs behave a certain way. Is that consistent with the purpose of > > this document? > > [suresh] Section 5 is merely a summary of observations. There is no > recommendation here. This is consistent with the purpose of this document. Well, except that you say "should not assume", etc... That's quasinormative. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Mar 20 11:50: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 1HTgaT-0007eO-2C; Tue, 20 Mar 2007 11:49:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgaR-0007eC-7Z for behave@ietf.org; Tue, 20 Mar 2007 11:49:23 -0400 Received: from web33314.mail.mud.yahoo.com ([68.142.206.129]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTgaP-0007vi-Ok for behave@ietf.org; Tue, 20 Mar 2007 11:49:23 -0400 Received: (qmail 18830 invoked by uid 60001); 20 Mar 2007 15:49:21 -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=yJ9ivT3PtRWxR65uGTXugDr6BslftZEBAQn1+K8K2qjqrK4h/lG/5Gsdn88eq9yr4Pmi7jled+LdSiHh4qWccbrQR3ugE6/3jPUJwZY4Q1L1Ru+W1+Osku4iRUNv490O2vftb439d5lnZ+0y/7jb0Jy4Ol/1MKoZj2WwQocaJY4=; X-YMail-OSG: nZ_H.c4VM1k9Prr6ve6Ezciyrj9.43OldqkPvVnNpJLnYxeIixOriBfFc9giUGi_ftp9e0EpWj0hQOuN.x8bBXg_ocboOvNvbKIzu4QAvCHkleFwH3sTLVB00mSIm7otcwHLvRQ4KmhWdj0- Received: from [69.236.76.33] by web33314.mail.mud.yahoo.com via HTTP; Tue, 20 Mar 2007 08:49:21 PDT Date: Tue, 20 Mar 2007 08:49:21 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: Cullen Jennings , Behave WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <267190.18703.qm@web33314.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Cullen, Thank you for your comments. Please see my respinses inline. regards, suresh --- Cullen Jennings wrote: > > My recollection of the last meeting was that we were not going to > require that NATs MUST forward ICMP packets at all since many > firewalls don't do that. However, if they do it, we were describe the > requirements on they needed to do. > > I disagree that a NAT must forward ICMP packets at all - we agree to > try and not specify firewall behavior but also we agree not to > specify things such that firewalls would automatically not be > compliant with behave. > [suresh] I reviewed minutes summary from Dan and feedback from Fernando from the last meeting. I did not see this comment in ether of them. Anyways, help me understand why you dont think NATs be required to forward ICMP packets, perhaps, with an example. Thanks. > RFC 1812 has a lot of stuff in it - NATs are not routers - I doubt > that a NAT has to meet all the requirements of a router. For > example,from 1812 - "A router MUST NOT reassemble any datagram > before forwarding it." > [suresh] Cullen - NAT is fundamentally a routing device in that it forwards packets from realm to another. RFC 2663 (section 3) refers this as transparent routing. > NATs are not hosts in all senses of 1122 - for example when they > forward a packet from the outside to the inside they violate > "When a host sends any datagram, the IP source address MUST > be one of its own IP addresses (but not a broadcast or > > I don't understand how a NAT that does not implement some extension > contemplated in ICMP-EXT will be able to correctly translate when > forwarding these. I'm not sure there is a problem here - it may all > be fine but I don't understand it. > [suresh] From checking with the authors of draft-bonica-icmp, it seems there are no known ICMP extensions that use addressing information. The draft-bonica authors basicaly suggested that a NAT be cognizant of standard ICMP extensions. This is so, in case there is a future ICMP-extension that might require NAT to translate. > Req-6 - I agree with this but it is confusing on how it is written. > I'm not sure implementers will be able to understand this. > > multicast address)." [suresh] Has soemthing petered off here? Anyways, if you have better wording for the requirement, do suggest. Thanks. > > The way 3022 is reference in this draft, it would need to be a > normative reference. > > The terminology is confusing and uses several things we agree not to > use because it was confusing. For example, "Basic NAT",etc - I see no > need to this document to introduce any new nat terminology > [suresh] Basic NAT is not new terminology. This is merely adapted from 2663, right. Is there some usage that is confusing? > There is still normative language in things that are not requirements. > [suresh] As for normative language and so forth - Magnus suggested moving 2663 and 3022 to informational, because of the new downref concerns. DO you suggest not doign so? Thanks. regards, suresh > _______________________________________________ > 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 Mar 20 13:23: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 1HTi3C-0005wE-F0; Tue, 20 Mar 2007 13:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi3B-0005w5-2m for behave@ietf.org; Tue, 20 Mar 2007 13:23: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 1HTi2v-00086L-6R for behave@ietf.org; Tue, 20 Mar 2007 13:23:08 -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 l2KGxotQ008743 for ; Tue, 20 Mar 2007 19:00:06 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 18:59:58 +0200 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); Tue, 20 Mar 2007 18:59:58 +0200 Received: from essapo-nirac253224.europe.nokia.com (essapo-nirac253224.europe.nokia.com [10.162.253.224]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2KGxuuS013731 for ; Tue, 20 Mar 2007 18:59:56 +0200 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: Tue, 20 Mar 2007 18:59:55 +0200 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: <200703201859.56096.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 Mar 2007 16:59:58.0172 (UTC) FILETIME=[30DC79C0:01C76B11] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070320190006-1BB8EBB0-73C68D87/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: behave@ietf.org X-Mailman-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 16 March 2007 23:08:17 ext Cullen Jennings wrote: > My recollection of the last meeting was that we were not going to > require that NATs MUST forward ICMP packets at all since many > firewalls don't do that. However, if they do it, we were describe the > requirements on they needed to do. Hmm, firewalls are about filtering, NATs are about sharing/hiding IP=20 addresses. Sure, you can (and often do) have both on the same box. That noted, unless you decide to filter ICMP traffic purposedly, i.e. to av= oid=20 breaking UDP hole punching and TCP-S-O in some cases, NATs certainly should= =20 forward ICMP. And that might be worth discussing. > I disagree that a NAT must forward ICMP packets at all - we agree to > try and not specify firewall behavior but also we agree not to > specify things such that firewalls would automatically not be > compliant with behave. I wouldn't take IETF-firewall-taboo as a reason for taking such a decision. > RFC 1812 has a lot of stuff in it - NATs are not routers - I doubt > that a NAT has to meet all the requirements of a router. For > example,from 1812 - "A router MUST NOT reassemble any datagram > before forwarding it." Yes, but that's not at all ICMP-specific. (...) > I don't understand how a NAT that does not implement some extension > contemplated in ICMP-EXT will be able to correctly translate when > forwarding these. I'm not sure there is a problem here - it may all > be fine but I don't understand it. Hmm, ICMP extension will always preserve the port numbers within the=20 encapsulated transport protocol header (which is to say the first 4 bytes=20 past the IP header), unless there is a big amount of IP options (something= =20 you definitely do not use if you want to be NAT friendly). I agree however that some corner ICMP cases are just impossible to handle f= or=20 NATs, such as: =2D too much IP options prevent seeing the port numbers, =2D no encapsulated error packets (NAT using inner port numbers for muxing)= ,=20 neither an Echo req/rep packet (NAT using ICMP ID for muxing). Maybe it should be a "best effort" type-of requirements then?? =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 Mar 20 15:03: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 1HTjc5-0007Lo-8g; Tue, 20 Mar 2007 15:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTjc4-0007IF-CF for behave@ietf.org; Tue, 20 Mar 2007 15:03:16 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTjbR-0000ST-Td for behave@ietf.org; Tue, 20 Mar 2007 15:02:58 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id EF953F0C56C; Tue, 20 Mar 2007 16:02:37 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2KJ29Li011671; Tue, 20 Mar 2007 16:02:25 -0300 Message-Id: <200703201902.l2KJ29Li011671@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Mar 2007 15:32:49 -0300 To: Cullen Jennings , Behave WG From: Fernando Gont Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Tue, 20 Mar 2007 16:02:37 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 At 06:08 p.m. 16/03/2007, Cullen Jennings wrote: >I disagree that a NAT must forward ICMP packets at all - we agree to >try and not specify firewall behavior but also we agree not to >specify things such that firewalls would automatically not be >compliant with behave. If you want to get rid of ICMP, you should raise it on the Int-Area list, I guess. Killing ICMP is not a decision that is within the scope of this WG. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 21 08: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 1HU02d-0006bH-F8; Wed, 21 Mar 2007 08:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU02c-0006ax-A5 for behave@ietf.org; Wed, 21 Mar 2007 08:35:46 -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 1HU02a-0000hk-UA for behave@ietf.org; Wed, 21 Mar 2007 08:35:46 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 08:35:44 -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, 21 Mar 2007 08:35:43 -0400 Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt From: Saikat Guha To: Fernando Gont In-Reply-To: <200703201902.l2KJ29Li011671@venus.xmundo.net> References: <200703201902.l2KJ29Li011671@venus.xmundo.net> Date: Wed, 21 Mar 2007 08:35:43 -0400 Message-Id: <1174480543.6838.11.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 (2.10.0-2.fc7) X-OriginalArrivalTime: 21 Mar 2007 12:35:43.0672 (UTC) FILETIME=[71418380:01C76BB5] X-Spam-Score: 0.0 (/) 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: , Content-Type: multipart/mixed; boundary="===============0283805222==" Errors-To: behave-bounces@ietf.org --===============0283805222== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ietaNOIfLhpB9Y05zYqG" --=-ietaNOIfLhpB9Y05zYqG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-03-20 at 15:32 -0300, Fernando Gont wrote: > At 06:08 p.m. 16/03/2007, Cullen Jennings wrote: >=20 > >I disagree that a NAT must forward ICMP packets at all [...] > If you want to get rid of ICMP, you should raise it on the Int-Area=20 > list, I guess. Killing ICMP is not a decision that is within the=20 > scope of this WG. Is it acceptable to build a NAT that does not support SCTP? or DCCP? Just because a NAT is not required to support a particular protocol does not mean that that protocol has no reason to exist on the Internet. Apparently, there are NATs that do not support UDP (see Joe Touche's comments from http://www3.ietf.org/proceedings/06jul/minutes/behave.html) I'd suggest clarifying the scope of the document to read: This document applies to NATs that translate or originate ICMP packets (i.e. almost every NAT). --=20 Saikat --=-ietaNOIfLhpB9Y05zYqG 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) iD8DBQBGASafnFltqi691/oRAg61AJ9ZpT9QPE9x3+ej3wpPrVfinhQmcwCeLRRj g5n0eOes6Bx7E5SxFSHwOY0= =cGDR -----END PGP SIGNATURE----- --=-ietaNOIfLhpB9Y05zYqG-- --===============0283805222== 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 --===============0283805222==-- From behave-bounces@ietf.org Wed Mar 21 08:57: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 1HU0Nw-0000Wg-3a; Wed, 21 Mar 2007 08:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0Nv-0000Wa-IK for behave@ietf.org; Wed, 21 Mar 2007 08:57:47 -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 1HU0Nu-000667-46 for behave@ietf.org; Wed, 21 Mar 2007 08:57:47 -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 l2LCutqH028885; Wed, 21 Mar 2007 14:57:22 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 14:57:18 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 14:57:18 +0200 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); Wed, 21 Mar 2007 14:57:18 +0200 Received: from essapo-nirac25336.europe.nokia.com (essapo-nirac25336.europe.nokia.com [10.162.253.36]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LCvGCD018047; Wed, 21 Mar 2007 14:57:16 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Wed, 21 Mar 2007 14:57:14 +0200 User-Agent: KMail/1.9.6 References: <200703201902.l2KJ29Li011671@venus.xmundo.net> <1174480543.6838.11.camel@sioux.systems.cs.cornell.edu> In-Reply-To: <1174480543.6838.11.camel@sioux.systems.cs.cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703211457.15485.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 21 Mar 2007 12:57:18.0365 (UTC) FILETIME=[74F3FCD0:01C76BB8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070321145722-6DD20BB0-05FD1628/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Agree overall. On Wednesday 21 March 2007 14:35:43 ext Saikat Guha wrote: > > If you want to get rid of ICMP, you should raise it on the Int-Area > > list, I guess. Killing ICMP is not a decision that is within the > > scope of this WG. > Is it acceptable to build a NAT that does not support SCTP? or DCCP? Or UDP-Lite. (...) > Apparently, there are NATs that do not support UDP (see Joe Touche's > comments from > http://www3.ietf.org/proceedings/06jul/minutes/behave.html) Hmm, I hope such NATs has its own DNS caching server, otherwise I would not= =20 want to be using such a thing. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 21 09:18: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 1HU0hd-0007Ij-3X; Wed, 21 Mar 2007 09:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0hb-0007I7-I9 for behave@ietf.org; Wed, 21 Mar 2007 09:18:07 -0400 Received: from web33314.mail.mud.yahoo.com ([68.142.206.129]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HU0hL-0001wd-LY for behave@ietf.org; Wed, 21 Mar 2007 09:18:07 -0400 Received: (qmail 75283 invoked by uid 60001); 21 Mar 2007 13:17:47 -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=MS9DLiRXfhYS3yT8PvnFEFLSf9ZdFwybonp1R7NBXCTNLNyd1nqkYlDUoa57WDgOyxj1EguWV+Uf3xArqJOSF22MR67MRoyUuInMGa0rkf62p95cSjqV3pwDo475WqlLCNMtTz326YTJvPXa0GnyluHorCSOeLYPZgIfBvf9UbM=; X-YMail-OSG: kmjt5c0VM1m4UkhutC.DTbpEPx6XPTDDd00MYXWA2v1a0CFzl0u56bQildqXhnITz.O21cUbnh7tuDtQ3dL5w3.aArNVzYNNWEJHwbMXQ9HiLWiMGZXFs2C_r6qxdGPt6NXBkQDcRSg- Received: from [69.236.76.33] by web33314.mail.mud.yahoo.com via HTTP; Wed, 21 Mar 2007 06:17:47 PDT Date: Wed, 21 Mar 2007 06:17:47 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: Saikat Guha , Fernando Gont In-Reply-To: <1174480543.6838.11.camel@sioux.systems.cs.cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <506480.75191.qm@web33314.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Saikat, Will a NAT be BEHAVE compliant, if the NAT complies with BEHAVE TCP, but does not comply with the BEHAVE UDP? I would think not. Will a NAT be BEHAVE compliant, if the NAT complies with BEHAVE TCP, and BEHAVE UDP, but does not comply with the BEHAVE ICMP? I would think not. NAT vendors support TCP and UDP, as these are the most popular transport protocols. While there are many transport protocols, there is just one signaling protocol for IP - That is ICMP. All NAT vendors support ICMP, AFAIK. regards, suresh --- Saikat Guha wrote: > On Tue, 2007-03-20 at 15:32 -0300, Fernando Gont wrote: > > At 06:08 p.m. 16/03/2007, Cullen Jennings wrote: > > > > >I disagree that a NAT must forward ICMP packets at all > [...] > > If you want to get rid of ICMP, you should raise it on the Int-Area > > list, I guess. Killing ICMP is not a decision that is within the > > scope of this WG. > > Is it acceptable to build a NAT that does not support SCTP? or DCCP? > Just because a NAT is not required to support a particular protocol does > not mean that that protocol has no reason to exist on the Internet. > > Apparently, there are NATs that do not support UDP (see Joe Touche's > comments from > http://www3.ietf.org/proceedings/06jul/minutes/behave.html) > > I'd suggest clarifying the scope of the document to read: > > This document applies to NATs that translate or originate ICMP > packets (i.e. almost every NAT). > > -- > 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 Wed Mar 21 09:37: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 1HU0zj-0003W9-Qm; Wed, 21 Mar 2007 09:36:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0zh-0003W1-Sd for behave@ietf.org; Wed, 21 Mar 2007 09:36:49 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HU0zK-0004lz-Ar for behave@ietf.org; Wed, 21 Mar 2007 09:36:49 -0400 Received: (qmail 1688 invoked by uid 60001); 21 Mar 2007 13:36:25 -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=KJXJO8ZpSxoSPPNYbvd3SBeERRy1GBUQZ/p6GkXxM+B2lM/JxClaAWulViQ/5pW/KxwPEPkAlIQI2+JSDHSt9/qwmPir9ZKZ2eahTNeN+6Cwik26GqRNxwDQ6VPFBQwFe2F2QItvowBCDw0B2N6Oo4a2FXwySitjMKQ2TSGkKwA=; X-YMail-OSG: 5E.GkMkVM1kxAZ4o_PfyqMYE_6XeuZEozwxWJPS_ODSD68Mjy0YCoW10vCu49AnSMEi78oGk2RBc5dgqNvMVKHP_qsEtc7ounVmvhuIzM9PntdrJ7Kkm1MeC59vHYBl_nR0MTqhd3LNfUkYB8_yf2g-- Received: from [69.236.76.33] by web33312.mail.mud.yahoo.com via HTTP; Wed, 21 Mar 2007 06:36:25 PDT Date: Wed, 21 Mar 2007 06:36:25 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: "Rémi" Denis-Courmont , behave@ietf.org In-Reply-To: <200703201859.56096.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <428320.612.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Friday 16 March 2007 23:08:17 ext Cullen Jennings wrote: > > My recollection of the last meeting was that we were not going to > > require that NATs MUST forward ICMP packets at all since many > > firewalls don't do that. However, if they do it, we were describe the > > requirements on they needed to do. > > Hmm, firewalls are about filtering, NATs are about sharing/hiding IP > addresses. Sure, you can (and often do) have both on the same box. > > That noted, unless you decide to filter ICMP traffic purposedly, i.e. to > avoid > breaking UDP hole punching and TCP-S-O in some cases, NATs certainly should > forward ICMP. And that might be worth discussing. > [suresh] I agree. > > I disagree that a NAT must forward ICMP packets at all - we agree to > > try and not specify firewall behavior but also we agree not to > > specify things such that firewalls would automatically not be > > compliant with behave. > > I wouldn't take IETF-firewall-taboo as a reason for taking such a decision. > > > RFC 1812 has a lot of stuff in it - NATs are not routers - I doubt > > that a NAT has to meet all the requirements of a router. For > > example,from 1812 - "A router MUST NOT reassemble any datagram > > before forwarding it." > > Yes, but that's not at all ICMP-specific. > > (...) > > I don't understand how a NAT that does not implement some extension > > contemplated in ICMP-EXT will be able to correctly translate when > > forwarding these. I'm not sure there is a problem here - it may all > > be fine but I don't understand it. > > Hmm, ICMP extension will always preserve the port numbers within the > encapsulated transport protocol header (which is to say the first 4 bytes > past the IP header), unless there is a big amount of IP options (something > you definitely do not use if you want to be NAT friendly). > [suresh] Remi - [ICMP] stipulates that an ICMP error message should embed IP header and a minimum of 64 bits of the IP payload. IP options are part of IP header. So, the protocol header would be part of ICMP embedded payload. I believe, Cullen is commenting about implementing extensions contemplated in [ICMP-EXT] (draft-bonica-internet-ICMP) on a BEHAVE compliant NAT device. > I agree however that some corner ICMP cases are just impossible to handle for > > NATs, such as: > - too much IP options prevent seeing the port numbers, [suresh] Please see my comment above. IP options should not be a problem. > - no encapsulated error packets (NAT using inner port numbers for muxing), > neither an Echo req/rep packet (NAT using ICMP ID for muxing). > [suresh] I dont understand your comment about "no encapsulated error packets". Why will an ICMP error packet not have embedded IP packet. That is simply a violation of RFC 792, right? regards, suresh > Maybe it should be a "best effort" type-of requirements then?? > > -- > 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 Wed Mar 21 09:45: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 1HU187-0001Qt-Qn; Wed, 21 Mar 2007 09:45:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU187-0001Qa-A2 for behave@ietf.org; Wed, 21 Mar 2007 09:45:31 -0400 Received: from web33311.mail.mud.yahoo.com ([68.142.206.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HU184-0006we-Ud for behave@ietf.org; Wed, 21 Mar 2007 09:45:31 -0400 Received: (qmail 29077 invoked by uid 60001); 21 Mar 2007 13:45: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=DQpSqJHkDiEVCMULFyUBsMGwrK2zXgWNXrANQifnhPafD183763u/mWtO/V6FXIBevCEOVXWy6N2RNWdPuTl5owXVmjIVJRU3lvatiB4QjhDGWpcG9v0mmLsYKErpkvNN+KkMMGI6DhqgdLQNV1RUn4WkpK4PI/0UOrLrABXbLg=; X-YMail-OSG: gOOJL8YVM1mrsa8BFmbDbL5FVAwvCuyCAsaKxdm5EGrLlRgTgRcLdH07POHuu83RYXl5jsmq48xi1JscIxCTRXwzgVQL0.oPVGHRFI9udzIpGluaT95CvlV9Or04wxO.lIpn49H83VEOx_AL05qVUA-- Received: from [69.236.76.33] by web33311.mail.mud.yahoo.com via HTTP; Wed, 21 Mar 2007 06:45:28 PDT Date: Wed, 21 Mar 2007 06:45:28 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt To: "Rémi" Denis-Courmont , behave@ietf.org In-Reply-To: <200703211457.15485.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <571991.28739.qm@web33311.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: > Agree overall. > > On Wednesday 21 March 2007 14:35:43 ext Saikat Guha wrote: > > > If you want to get rid of ICMP, you should raise it on the Int-Area > > > list, I guess. Killing ICMP is not a decision that is within the > > > scope of this WG. > > > Is it acceptable to build a NAT that does not support SCTP? or DCCP? > > Or UDP-Lite. > > (...) > > Apparently, there are NATs that do not support UDP (see Joe Touche's > > comments from > > http://www3.ietf.org/proceedings/06jul/minutes/behave.html) > > Hmm, I hope such NATs has its own DNS caching server, otherwise I would not > want to be using such a thing. > [suresh] Right. I also wouldnt call it BEHAVE compliant. 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 Wed Mar 21 09:59: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 1HU1LB-0005N6-Rl; Wed, 21 Mar 2007 09:59:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1LA-0005MI-Ki for behave@ietf.org; Wed, 21 Mar 2007 09:59:00 -0400 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1L7-0001VF-2z for behave@ietf.org; Wed, 21 Mar 2007 09:59:00 -0400 Received: from dhcp-107d.ietf68.org ([130.129.16.125]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1HU1L1-0001ZI-R3 for behave@ietf.org; Wed, 21 Mar 2007 13:58:51 +0000 Message-ID: <46013A17.5070309@db.org> Date: Wed, 21 Mar 2007 14:58:47 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [BEHAVE] duplicated STUN attributes X-BeenThere: behave@ietf.org X-Mailman-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 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 From behave-bounces@ietf.org Wed Mar 21 09:59: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 1HU1Ln-0005xC-Uz; Wed, 21 Mar 2007 09:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Lm-0005sX-TN for behave@ietf.org; Wed, 21 Mar 2007 09:59:38 -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 1HU1Ll-0001dz-KN for behave@ietf.org; Wed, 21 Mar 2007 09:59:38 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 09:59: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, 21 Mar 2007 09:59:36 -0400 Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt From: Saikat Guha To: Pyda Srisuresh In-Reply-To: <506480.75191.qm@web33314.mail.mud.yahoo.com> References: <506480.75191.qm@web33314.mail.mud.yahoo.com> Date: Wed, 21 Mar 2007 09:59:35 -0400 Message-Id: <1174485575.6838.26.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 (2.10.0-2.fc7) X-OriginalArrivalTime: 21 Mar 2007 13:59:36.0397 (UTC) FILETIME=[28FE67D0:01C76BC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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="===============0421296725==" Errors-To: behave-bounces@ietf.org --===============0421296725== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AdDZVXiPmfhHZIp/eqgu" --=-AdDZVXiPmfhHZIp/eqgu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-03-21 at 06:17 -0700, Pyda Srisuresh wrote: > Will a NAT be BEHAVE compliant, if the NAT complies with BEHAVE TCP, but = does > not comply with the BEHAVE UDP? I would think not. It is actually not possible to "comply" with BEHAVE TCP and not with UDP. See Section 8, behave-tcp: "A NAT that supports all of the mandatory requirements of this specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP], is "compliant with this specification"." > Will a NAT be BEHAVE compliant, if the NAT complies with BEHAVE TCP, and = BEHAVE > UDP, but does not comply with the BEHAVE ICMP? I would think not. That is the issue under debate. If a NAT/Firewall wanted to completely block TCP/UDP-related ICMP errors in all directions, should that be allowed. I don't see why not. If your counter-argument is that such a NAT/firewall would break TCP/UDP and prevent them from working correctly, then I'd say such a NAT/firewall would not be commercially viable and therefore does not matter. If you think such a NAT/firewall would break a particular TCP/UDP application, please say which. ICMP is "nice" to have for TCP/UDP but NOT a MUST. Requiring ICMP support for TCP/UDP IMHO is a non sequitur. --=20 Saikat --=-AdDZVXiPmfhHZIp/eqgu 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) iD8DBQBGATpHnFltqi691/oRAn/4AJwLuBoZdORL2ENLqRIuY7r1JKPpfgCfTskC A+c6UolMS48uhOXfEy1gNNw= =jAM4 -----END PGP SIGNATURE----- --=-AdDZVXiPmfhHZIp/eqgu-- --===============0421296725== 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 --===============0421296725==-- From behave-bounces@ietf.org Wed Mar 21 11:04: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 1HU2Mc-0003It-8C; Wed, 21 Mar 2007 11:04:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU2Ma-0003Ie-Qk for behave@ietf.org; Wed, 21 Mar 2007 11:04:32 -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 1HU2ML-0000YZ-Nf for behave@ietf.org; Wed, 21 Mar 2007 11:04:32 -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 l2LF3t3Z004390; Wed, 21 Mar 2007 17:04:15 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 17:04:11 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 17:04:11 +0200 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); Wed, 21 Mar 2007 17:04:10 +0200 Received: from essapo-nirac253120.europe.nokia.com (essapo-nirac253120.europe.nokia.com [10.162.253.120]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LF493Y024005; Wed, 21 Mar 2007 17:04:09 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Pyda Srisuresh" Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Wed, 21 Mar 2007 17:04:08 +0200 User-Agent: KMail/1.9.6 References: <428320.612.qm@web33312.mail.mud.yahoo.com> In-Reply-To: <428320.612.qm@web33312.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703211704.08538.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 21 Mar 2007 15:04:10.0907 (UTC) FILETIME=[2E61B6B0:01C76BCA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070321170415-08DE9BB0-59B2BD91/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Wednesday 21 March 2007 15:36:25 ext Pyda Srisuresh wrote: > [suresh] Remi - [ICMP] stipulates that an ICMP error message should embed > IP header and a minimum of 64 bits of the IP payload. IP options are part > of IP header. So, the protocol header would be part of ICMP embedded > payload. > > I believe, Cullen is commenting about implementing extensions contemplated > in [ICMP-EXT] (draft-bonica-internet-ICMP) on a BEHAVE compliant NAT > device. Yes, I understand that. ICMP-ext will provide at least 128 bytes of the=20 original IP packets. So unless you have 104 bytes worth of IP options, the= =20 port numbers are going to be there. So it should indeed not be a problem. > > - no encapsulated error packets (NAT using inner port numbers for > > muxing), neither an Echo req/rep packet (NAT using ICMP ID for muxing). > > [suresh] I dont understand your comment about "no encapsulated error > packets". Why will an ICMP error packet not have embedded IP packet. That > is simply a violation of RFC 792, right? I refer to non-error ICMP messages (ping). =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 Mar 21 14:26: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 1HU5VW-0001as-HY; Wed, 21 Mar 2007 14:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5VV-0001ae-Lw for behave@ietf.org; Wed, 21 Mar 2007 14:25:57 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5VU-0006nH-AF for behave@ietf.org; Wed, 21 Mar 2007 14:25:57 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DB54AF0C467; Wed, 21 Mar 2007 15:25:57 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2LIPpen016083; Wed, 21 Mar 2007 15:25:52 -0300 Message-Id: <200703211825.l2LIPpen016083@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 15:25:47 -0300 To: Saikat Guha , Fernando Gont From: Fernando Gont Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt In-Reply-To: <1174480543.6838.11.camel@sioux.systems.cs.cornell.edu> References: <200703201902.l2KJ29Li011671@venus.xmundo.net> <1174480543.6838.11.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 21 Mar 2007 15:25:55 -0300 (ART) X-Spam-Score: 0.1 (/) 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 At 09:35 a.m. 21/03/2007, Saikat Guha wrote: >Is it acceptable to build a NAT that does not support SCTP? or DCCP? >Just because a NAT is not required to support a particular protocol does >not mean that that protocol has no reason to exist on the Internet. ICMP is a core Internet protocol, and it is still required for proper TCP operation. While mechanism for PMTUD that does not depend on ICMP has been devised, it has not yet been widely deployed. And even then, ICMP can greatly help to shorten the convergence time of the new PMTUD mechanism. Some implementations (e.g., Linux) implement UDP PMTUD. Thus, killing ICMP would kill UDP's PMTUD, too. Look at the archives of the TCPM WG. For three years we have been discussing about ICMP. And you know simply want to kill it at a NAT. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 21 14:36: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 1HU5fW-00052m-Ue; Wed, 21 Mar 2007 14:36:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5fW-00052f-A3 for behave@ietf.org; Wed, 21 Mar 2007 14:36:18 -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 1HU5fU-0000y7-Sm for behave@ietf.org; Wed, 21 Mar 2007 14:36:18 -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 l2LIa5As021599; Wed, 21 Mar 2007 20:36:11 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 20:36:06 +0200 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); Wed, 21 Mar 2007 20:36:05 +0200 Received: from [130.129.23.111] (essapo-nirac253238.europe.nokia.com [10.162.253.238]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LIa3MK024490; Wed, 21 Mar 2007 20:36:03 +0200 In-Reply-To: <1174485575.6838.26.camel@sioux.systems.cs.cornell.edu> References: <506480.75191.qm@web33314.mail.mud.yahoo.com> <1174485575.6838.26.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0BE23FC4-43BC-45FD-8E3A-9B39F915A78E@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Wed, 21 Mar 2007 19:36:00 +0100 To: ext Saikat Guha X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Mar 2007 18:36:05.0352 (UTC) FILETIME=[C8C80E80:01C76BE7] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070321203611-54323BB0-26920A0F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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="===============0566141433==" Errors-To: behave-bounces@ietf.org --===============0566141433== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-95-773949108; protocol="application/pkcs7-signature" --Apple-Mail-95-773949108 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-3-21, at 14:59, ext Saikat Guha wrote: > That is the issue under debate. If a NAT/Firewall wanted to completely > block TCP/UDP-related ICMP errors in all directions, should that be > allowed. I don't see why not. I'm not quite sure what ICMP types you define to be included in "TCP/ UDP-related", but breaking PMTUD and causing blackholed connection attempts are issues. > If your counter-argument is that such a NAT/firewall would break > TCP/UDP > and prevent them from working correctly, then I'd say such a > NAT/firewall would not be commercially viable and therefore does not > matter. A technical recommendation to prevent breaking transport protocols is surely preferable? Lars --Apple-Mail-95-773949108 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjExODM2MDFaMCMGCSqGSIb3DQEJBDEWBBTH4PZUm2qDGzOt vffrAoXyrxyiSDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAiFomjLQFW4lUX2Ht55/OATFDjQD0bZKch0uY6aYouRIoGJ1DTyYG iY7pZT0Q+V5N5CVi3UU4uTgxb99Xcc6+epvsyx1VYySHAyQjTxinHSpU38wui3Oxy2hRQ1PvIQBq rjEj/D4wyAS1EEYHGwBU2DbBvkKixP+GpNwcWV1Cg2qldJFh0DdowWm96viUDNN7ABbbZpI8leSG urPekW2IGDPZnVH+Fcmw2T1A9vmCGsnOTxvqLyLEufvQJo6lHXeS7Ke/MazZiXxyd1DqQ4n9gwZo Q6JBLyQB23kh451W5f+G3wVHc2gPrJqSfjb45xT6SZBd1fULqRXzt2YTjGHADAAAAAAAAA== --Apple-Mail-95-773949108-- --===============0566141433== 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 --===============0566141433==-- From behave-bounces@ietf.org Wed Mar 21 14:38: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 1HU5hi-0000Ia-4Q; Wed, 21 Mar 2007 14:38:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5hh-0000E2-Gn for behave@ietf.org; Wed, 21 Mar 2007 14:38:33 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HU5hf-0001nT-3I for behave@ietf.org; Wed, 21 Mar 2007 14:38:33 -0400 Received: from Quinthar ([71.146.136.151]) by quinthar.com for ; Wed, 21 Mar 2007 11:38:19 -0700 From: "David Barrett" To: "'Fernando Gont'" , "'Saikat Guha'" Subject: RE: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Wed, 21 Mar 2007 11:38:16 -0700 Message-ID: <07fb01c76be8$184a84b0$e0981a44@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: <200703211825.l2LIPpen016083@venus.xmundo.net> thread-index: Acdr5qZMLoXvVTWlQEC0YV+bh3tjigAAIsHA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar] > > Look at the archives of the TCPM WG. For three years we have been > discussing about ICMP. And you know simply want to kill it at a NAT. 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. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 21 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 1HU5k2-0003xv-Qo; Wed, 21 Mar 2007 14:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5k1-0003xl-I8 for behave@ietf.org; Wed, 21 Mar 2007 14:40:57 -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 1HU5k0-0002WU-4U for behave@ietf.org; Wed, 21 Mar 2007 14:40:57 -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 l2LIeXBp009249; Wed, 21 Mar 2007 20:40:51 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 20:40:47 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 20:40:47 +0200 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); Wed, 21 Mar 2007 20:40:47 +0200 Received: from [130.129.23.111] (essapo-nirac253238.europe.nokia.com [10.162.253.238]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LIej6m027561; Wed, 21 Mar 2007 20:40:45 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <0BE23FC4-43BC-45FD-8E3A-9B39F915A78E@nokia.com> References: <506480.75191.qm@web33314.mail.mud.yahoo.com> <1174485575.6838.26.camel@sioux.systems.cs.cornell.edu> <0BE23FC4-43BC-45FD-8E3A-9B39F915A78E@nokia.com> Message-Id: <0C00252D-D795-49B3-9B41-D08328E08897@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Wed, 21 Mar 2007 19:40:42 +0100 To: ext Saikat Guha , Behave WG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Mar 2007 18:40:47.0216 (UTC) FILETIME=[70C91700:01C76BE8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070321204051-2152BBB0-28ED081F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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="===============0909203903==" Errors-To: behave-bounces@ietf.org --===============0909203903== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-96-774230866; protocol="application/pkcs7-signature" --Apple-Mail-96-774230866 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-3-21, at 19:36, ext Lars Eggert wrote: >> If your counter-argument is that such a NAT/firewall would break >> TCP/UDP >> and prevent them from working correctly, then I'd say such a >> NAT/firewall would not be commercially viable and therefore does not >> matter. > > A technical recommendation to prevent breaking transport protocols > is surely preferable? Let me put that more strongly: BEHAVE is tasked to describe how NATs SHOULD behave. If that recommendation breaks IETF transport protocols, I'm becoming very concerned. Lars --Apple-Mail-96-774230866 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjExODQwNDNaMCMGCSqGSIb3DQEJBDEWBBRIkm8TRzNm+tWx ebYqo/5GZCSZ7zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAUe//BQJ8bZ1h7cxQ0Jk23wb5JO4rcVLzZRzc/J/GETAUdExWSqTH TkR8xqzUaPgprmPDl2AG7KvBOHS9fyj/XyRjQHzqFYG96MVOVARgLCAyfvD0jbNBWG066AdV1CeS KwxOc2WvVivrY0TN+ZXPsaYDOTXCDD4WS41xZ2PjIpw5tqcVuioyUzViYmZcgX7cCdeyEYNK4HuT qb3+Ced2/huysV3IbIMtF1wZ9O7hZ3IX6dq1t5DBGG8B7mN6xP/UT3KIzJYSifMo5gGpBWfofplH 64DfdkXoX+Dxz1MsR4egcsbVVEgh+gbVoKlV1VtoQNKkqJWQqFcpAqxQENoKkgAAAAAAAA== --Apple-Mail-96-774230866-- --===============0909203903== 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 --===============0909203903==-- From behave-bounces@ietf.org Wed Mar 21 15:05: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 1HU673-0001mh-1O; Wed, 21 Mar 2007 15:04:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU66z-0001YL-QX for behave@ietf.org; Wed, 21 Mar 2007 15:04:41 -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 1HU66x-0000cV-IM for behave@ietf.org; Wed, 21 Mar 2007 15:04:41 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 15:04:38 -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, 21 Mar 2007 15:04:38 -0400 Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt From: Saikat Guha To: Fernando Gont In-Reply-To: <200703211825.l2LIPpen016083@venus.xmundo.net> References: <200703201902.l2KJ29Li011671@venus.xmundo.net> <1174480543.6838.11.camel@sioux.systems.cs.cornell.edu> <200703211825.l2LIPpen016083@venus.xmundo.net> Date: Wed, 21 Mar 2007 15:04:38 -0400 Message-Id: <1174503878.4192.11.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 (2.10.0-2.fc7) X-OriginalArrivalTime: 21 Mar 2007 19:04:38.0498 (UTC) FILETIME=[C5E56420:01C76BEB] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0753229085==" Errors-To: behave-bounces@ietf.org --===============0753229085== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OqPX6aJp0n/DDbXAe4zg" --=-OqPX6aJp0n/DDbXAe4zg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-03-21 at 15:25 -0300, Fernando Gont wrote: > ICMP is a core Internet protocol, and it is still required for proper=20 > TCP operation.=20 [saikat@sioux tmp]$ grep -ci icmp rfc793.txt=20 1 I count 1 instance of icmp in RFC 793 (which admittedly has been updated many many times but nevertheless AFAIK has not been obsoleted yet). That one mention is in a Figure that illustrates the protocol stack from Telnet down to IP. I do not claim ICMP is not a core protocol. Nor do I claim that present day TCP does not heavily depend on it. I am merely stating that is is POSSIBLE to have TCP without ICMP (with degraded performance as it may be). > Look at the archives of the TCPM WG As such, your statement is absolutely correct but entirely depends on your definition of "proper TCP operation". That definition may differ for TCPM and BEHAVE. --=20 Saikat --=-OqPX6aJp0n/DDbXAe4zg 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) iD8DBQBGAYHAnFltqi691/oRAjFfAJ40MmrdDX5EHiYQe7m3UTRTb5+YRQCdFmg+ dWzBNkR2/4Jk9UUnYZ82XwA= =ToWz -----END PGP SIGNATURE----- --=-OqPX6aJp0n/DDbXAe4zg-- --===============0753229085== 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 --===============0753229085==-- From behave-bounces@ietf.org Wed Mar 21 15:36: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 1HU6bV-00047l-AC; Wed, 21 Mar 2007 15:36:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU6bT-0003zQ-8q for behave@ietf.org; Wed, 21 Mar 2007 15:36:11 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU6bN-0000f8-CQ for behave@ietf.org; Wed, 21 Mar 2007 15:36:11 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id F02F2F0C5DA; Wed, 21 Mar 2007 16:28:02 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2LJRppM011217; Wed, 21 Mar 2007 16:27:59 -0300 Message-Id: <200703211927.l2LJRppM011217@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 16:22:49 -0300 To: Saikat Guha From: Fernando Gont Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt In-Reply-To: <1174503878.4192.11.camel@sioux.systems.cs.cornell.edu> References: <200703201902.l2KJ29Li011671@venus.xmundo.net> <1174480543.6838.11.camel@sioux.systems.cs.cornell.edu> <200703211825.l2LIPpen016083@venus.xmundo.net> <1174503878.4192.11.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 21 Mar 2007 16:28:02 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 04:04 p.m. 21/03/2007, Saikat Guha wrote: > > ICMP is a core Internet protocol, and it is still required for proper > > TCP operation. > >[saikat@sioux tmp]$ grep -ci icmp rfc793.txt >1 > >I count 1 instance of icmp in RFC 793 (which admittedly has been updated >many many times but nevertheless AFAIK has not been obsoleted yet). Oh, yeah... from that perspective you can also violate TCP congestion control, as it wasn't introduced in RFC793. C'mon... you know better than that. >I do not claim ICMP is not a core protocol. Nor do I claim that present >day TCP does not heavily depend on it. I am merely stating that is is >POSSIBLE to have TCP without ICMP (with degraded performance as it may >be). Please explain to me how RFC1191/1981 PMTUD is expected to work if you blackhole ICMP. There are even at least one RFC describing the problem of ICMP blackholes... and the IETF had to devise a PMTUD mechanism that could survive those blackholes (which has not yet been widely deployed). But you guys seem to want the IETF to standardize ICMP blackholes. I'm amazed.... Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 21 16:04: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 1HU72A-0008JH-2b; Wed, 21 Mar 2007 16:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU728-0008J3-Ev for behave@ietf.org; Wed, 21 Mar 2007 16:03:44 -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 1HU727-0000W1-6o for behave@ietf.org; Wed, 21 Mar 2007 16:03:44 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 16:03:39 -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, 21 Mar 2007 16:03:38 -0400 Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt From: Saikat Guha To: Lars Eggert In-Reply-To: <0C00252D-D795-49B3-9B41-D08328E08897@nokia.com> References: <506480.75191.qm@web33314.mail.mud.yahoo.com> <1174485575.6838.26.camel@sioux.systems.cs.cornell.edu> <0BE23FC4-43BC-45FD-8E3A-9B39F915A78E@nokia.com> <0C00252D-D795-49B3-9B41-D08328E08897@nokia.com> Date: Wed, 21 Mar 2007 16:03:38 -0400 Message-Id: <1174507418.4192.38.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 (2.10.0-2.fc7) X-OriginalArrivalTime: 21 Mar 2007 20:03:38.0802 (UTC) FILETIME=[0414E920:01C76BF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============0423552993==" Errors-To: behave-bounces@ietf.org --===============0423552993== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PEYOkQrOOlgcrvFigndy" --=-PEYOkQrOOlgcrvFigndy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-03-21 at 19:40 +0100, Lars Eggert wrote: > Let me put that more strongly: BEHAVE is tasked to describe how NATs =20 > SHOULD behave. If that recommendation breaks IETF transport =20 > protocols, I'm becoming very concerned. Agreed. BEHAVE must not make a recommendation that breaks transport (no one is recommending a NAT not support ICMP).=20 Perhaps the chairs can correct me, be from the charter I read: "generate requirements documents and best current practices to enable NATs to function in as deterministic a fashion as possible." Which I read as follows: 1) Identify cases where NATs are non-deterministic.=20 2) Make them deterministic.=20 Support for PMTUD (TCP or UDP) or the lack thereof, I assume, is a non-deterministic feature that needs to be addressed. The most precise statement that captures would be something along the lines of: "NATs that support TCP or UDP MUST support the translation of ICMP Can't Fragment Error (Type=3D3,Code=3D4)" or even "NATs that translate transport protocols such as TCP,UDP,SCTP etc. MUST support the translation of ICMP Can't Fragment Error (Type=3D3,Code=3D4)" followed by a justification for exactly why. An overarching statement of the form a NAT MUST support translating all ICMP messages in all situations IMHO is out-of-scope for BEHAVE, which I think may be what Cullen was pointing out. --=20 Saikat --=-PEYOkQrOOlgcrvFigndy 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) iD8DBQBGAY+SnFltqi691/oRAn/HAJ9X0e17UO+UXL0I0g3jCZF2oZkNSACffFoj Q2OREJ1rrOTHqoGOpi9kMZo= =d21c -----END PGP SIGNATURE----- --=-PEYOkQrOOlgcrvFigndy-- --===============0423552993== 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 --===============0423552993==-- From behave-bounces@ietf.org Wed Mar 21 17:51: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 1HU8hY-00052A-9u; Wed, 21 Mar 2007 17:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU8hX-000524-6L for behave@ietf.org; Wed, 21 Mar 2007 17:50: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 1HU8hT-00037A-2E for behave@ietf.org; Wed, 21 Mar 2007 17:50: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, 21 Mar 2007 17:50: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); Wed, 21 Mar 2007 17:50:29 -0400 From: Saikat Guha To: behave In-Reply-To: References: Date: Wed, 21 Mar 2007 17:50:29 -0400 Message-Id: <1174513829.4192.60.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 (2.10.0-2.fc7) X-OriginalArrivalTime: 21 Mar 2007 21:50:29.0796 (UTC) FILETIME=[F154F640:01C76C02] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "Pasi.Eronen" Subject: [BEHAVE] Re: SecDir review of draft-ietf-behave-tcp-05 X-BeenThere: behave@ietf.org X-Mailman-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="===============1968436925==" Errors-To: behave-bounces@ietf.org --===============1968436925== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ufwM1PuYT8/vvCnhta4z" --=-ufwM1PuYT8/vvCnhta4z Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thanks Pasi for the SecDir review of behave-tcp. Comments inline reflect authors consensus.=20 Bringing to the list for additional discussion. On Mon, 2007-03-05 at 14:25 +0200, Pasi.Eronen@nokia.com wrote: > 1) The document does not seem to mention rewriting of TCP sequence > numbers, which some NATs do. Among other things, this can break > SACK (unless the SACK is also rewritten). Perhaps this issue > should be mentioned, and possibly some recommendation given? This issue, while a valid concern, is out-of-scope of this document. The scope currently states "Middlebox behavior that is not necessary for network address translation of TCP is out-of-scope". NATs are not _required_ to rewrite TCP Seq# for TCP translation.=20 Of course NATs that do have this feature (presumably to hide hosts from stack fingerprinting etc.) must implement it correctly w/ or without SACK. AFAIK there is no non-determinism involved in a correct implementation of such a feature that needs to be resolved making this concern out-of-scope. > 2) When a NAT decides to abandon state for a TCP connection (due to > "established connection idle-timeout", or simply as alternative to > blocking new connection attempts), it can do so silently, or it can > try to notify the endpoints (by sending RSTs or something). Should > the document have some discussion about the desirability (or > undesirability) of these alternatives? Agreed. Notification of abandoned connections is left unspecified (as per discussion on this list sometime back) since applications cannot depend on them anyway (failstop NAT crash, packet loss etc). We propose adding the following text to the end of Section 5 to put that in writing. ----8<-------------- NAT behavior for notifying endpoints when abandoning live connections is left unspecified. When a NAT abandons a live connection, for example due to a timeout expiring, the NAT MAY either send TCP RST packets to the endpoints or silently abandon the connection. Sending a RST allows endpoint applications to recover more quickly than silently abandoning the connection because in the latter case the detection of the error is postponed to the next time the application attempts to communicate over the abandoned connection. However, as a NAT may lose session state due to software and hardware faults, applications cannot rely on such notifications. ----8<-------------- cheers, --=20 Saikat --=-ufwM1PuYT8/vvCnhta4z 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) iD8DBQBGAailnFltqi691/oRAlu6AJ94QxKLVlaFSLCk0gSqnRzbuaYNZgCfd83Q w3uxzJfY/JvuXLkttkCw/1k= =TXzg -----END PGP SIGNATURE----- --=-ufwM1PuYT8/vvCnhta4z-- --===============1968436925== 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 --===============1968436925==-- From behave-bounces@ietf.org Thu Mar 22 06:12: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 1HUKGt-0003Pl-8j; Thu, 22 Mar 2007 06:11:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKGs-0003Pc-9W for behave@ietf.org; Thu, 22 Mar 2007 06:11:50 -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 1HUKGp-0007pP-H2 for behave@ietf.org; Thu, 22 Mar 2007 06:11:50 -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 l2MABeZP016840; Thu, 22 Mar 2007 12:11:43 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 12:11:31 +0200 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); Thu, 22 Mar 2007 12:11:30 +0200 Received: from [130.129.23.111] (essapo-nirac252166.europe.nokia.com [10.162.252.166]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2MABQQ8018297; Thu, 22 Mar 2007 12:11:28 +0200 In-Reply-To: <1174507418.4192.38.camel@sioux.systems.cs.cornell.edu> References: <506480.75191.qm@web33314.mail.mud.yahoo.com> <1174485575.6838.26.camel@sioux.systems.cs.cornell.edu> <0BE23FC4-43BC-45FD-8E3A-9B39F915A78E@nokia.com> <0C00252D-D795-49B3-9B41-D08328E08897@nokia.com> <1174507418.4192.38.camel@sioux.systems.cs.cornell.edu> 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: Thu, 22 Mar 2007 11:11:23 +0100 To: ext Saikat Guha X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Mar 2007 10:11:31.0676 (UTC) FILETIME=[76AD71C0:01C76C6A] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070322121143-3B90CBB0-6EE72987/0-0/0-1 X-Nokia-AV: Clean 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: , Content-Type: multipart/mixed; boundary="===============0741051446==" Errors-To: behave-bounces@ietf.org --===============0741051446== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-106-830071731; protocol="application/pkcs7-signature" --Apple-Mail-106-830071731 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-3-21, at 21:03, ext Saikat Guha wrote: > On Wed, 2007-03-21 at 19:40 +0100, Lars Eggert wrote: >> Let me put that more strongly: BEHAVE is tasked to describe how NATs >> SHOULD behave. If that recommendation breaks IETF transport >> protocols, I'm becoming very concerned. > > Agreed. BEHAVE must not make a recommendation that breaks transport > (no > one is recommending a NAT not support ICMP). OK, now I am confused. Your earlier email said: On 2007-3-21, at 14:59, ext Saikat Guha wrote: > That is the issue under debate. If a NAT/Firewall wanted to completely > block TCP/UDP-related ICMP errors in all directions, should that be > allowed. I don't see why not. I took "that should be allowed" to mean "that NAT should still be labeled as behave-compliant." Which is problematic. Continuing with your later email that this reply is addressed to: > An overarching statement of the form a NAT MUST support translating > all > ICMP messages in all situations IMHO is out-of-scope for BEHAVE, > which I > think may be what Cullen was pointing out. That ("need not translate all ICMP messages in all situations") is a very different statement, and much more aligned with other current practice on filtering, e.g., v6ops. Lars --Apple-Mail-106-830071731 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjIxMDExMjRaMCMGCSqGSIb3DQEJBDEWBBQzagqEVkJhl2Fy j/j7zMrL8SOuOjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAwVw5lR4kOkvH+xTXb5wptUywCt5VqkTRjKW4zukDG4rjdcbL64tt 4sJ5e9cxkqHnVA537oaH5VmYo3JpetYFlCtQwcFHe3jSOmAkvsSMpBZiJWh7TkBTd9GuiaJ5JOIF SOMkm9astKxtPnV6MfZsQfDOL8Wm4jsEBY78UJI7y8uX22pbS2IlQlINr/skySSBVfoeVn87dcCh T5uYaR7oSkSqiH+9lp2E7RkcK48jorWl5PUCXUtDFy5UWAlKYMWcdnNTbNONZhxuZRgIiiuKWqiF yxnm8KCl7cxdjItFxqfSjzd0SZTyvLcifJf+L2uDMoOjFhHJ1AP3FDh8CkWjwwAAAAAAAA== --Apple-Mail-106-830071731-- --===============0741051446== 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 --===============0741051446==-- From behave-bounces@ietf.org Thu Mar 22 07:18: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 1HULIo-0000Sg-Gj; Thu, 22 Mar 2007 07:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULIn-0000SP-29 for behave@ietf.org; Thu, 22 Mar 2007 07:17:53 -0400 Received: from sd-green-bigip-81.dreamhost.com ([208.97.132.81] helo=randymail-a6.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULIh-00005X-5m for behave@ietf.org; Thu, 22 Mar 2007 07:17:53 -0400 Received: from delta.rtfm.com (dhcp-15cc.ietf68.org [130.129.21.204]) by randymail-a6.g.dreamhost.com (Postfix) with ESMTP id 12F0B175B6D for ; Thu, 22 Mar 2007 04:17:46 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 35F651CC22 for ; Thu, 22 Mar 2007 04:16:32 -0700 (PDT) To: behave@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Thu, 22 Mar 2007 04:16:32 -0700 From: EKR Message-Id: <20070322111632.35F651CC22@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [BEHAVE] Comments on draft-ietf-behave-nat-icmp-03 X-BeenThere: behave@ietf.org X-Mailman-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 S 2. The use of "Query Identifier" is confusing. Please just use the ICMP term "Identifier" S 3.1. A NAT device MUST permit ICMP query based applications to be initiated from private hosts to the external hosts. This makes practically all firewalls noncompliant. That's not OK. S 3.2. Below is justification for making the endpoint independent mapping for ICMP query IDs a SHOULD [RFC2119] requirement. ICMP Ping and ICMP traceroute ([RFC1470]) are two most commonly known legacy applications built on top of ICMP query messages. Neither of these applications require the ICMP Query Id to be retained across different sessions with external hosts. But, that may not be case with future applications. In the future, when an endhost application reuses the same Query identifier in sessions with different target hosts, the endhost application might require that the endpoint identity (i.e., the tuple of IP address and Query Identifier) appears the same across all its target hosts. It's not clear to me that it's a good idea placing additional requirements on NATs for future hypothetical protocols, given that there's not exactly a flood of new ICMP-based protocols. How many NATs are currently compliant with this? S 4.1. Appendix C of [ICMP-ATK] points out that newer revision end host TCP stacks do not accept ICMP error messages with a mismatched IP or TCP checksum in the embedded packet. NAT devices should ensure that ICMP Error payload is not corrupted. But this is very frequently not possible because of truncation. You cover this below, but this guidance here seems confusing. S 4.2.1. This diagram would be simpler if you omit Router-X, which doesn't seem to be needed until much later. Simple is good. S 6. Some NAT designers opt to never reject an outbound flow. When a NAT runs short of resources, they prefer to steal a resource from an existing NAT Session rather than reject the outbound flow. Such a design choice may appear conformant to REQ-8 below. However, the design choice is in violation of the spirit of both REQ-8 and REQ-2. Such a design choice is strongly discouraged. Sure, but why is this the best design choice? S 7.1.2 This is flip side of the argument for the above section. By virtue of the address translation NAT performs, NAT may end up being the recipient of "Packet too big" message. How is this "by virtue of the address translation" S 9. This document does not introduce any new security concerns related to ICMP error message handling in the NAT devices. However, the This isn't true because REQ1 reverses a security decision that firewall vendors have made. This needs analysis. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 22 08:19: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 1HUMGg-0008Cg-Lk; Thu, 22 Mar 2007 08:19:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMGf-0008Cb-Fp for behave@ietf.org; Thu, 22 Mar 2007 08:19:45 -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 1HUMGe-00079X-0v for behave@ietf.org; Thu, 22 Mar 2007 08:19:45 -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 l2MCJamN014618; Thu, 22 Mar 2007 14:19:42 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 14:19:11 +0200 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); Thu, 22 Mar 2007 14:19:11 +0200 Received: from essapo-nirac25334.europe.nokia.com (essapo-nirac25334.europe.nokia.com [10.162.253.34]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2MCJA47005077; Thu, 22 Mar 2007 14:19:10 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-nat-icmp-03 Date: Thu, 22 Mar 2007 14:19:09 +0200 User-Agent: KMail/1.9.6 References: <20070322111632.35F651CC22@delta.rtfm.com> In-Reply-To: <20070322111632.35F651CC22@delta.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200703221419.09782.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 22 Mar 2007 12:19:11.0662 (UTC) FILETIME=[4C628CE0:01C76C7C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070322141942-331FABB0-67E7C6CF/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Thursday 22 March 2007 13:16:32 ext EKR wrote: > S 3.1. > A NAT device MUST permit ICMP query based applications to be > initiated from private hosts to the external hosts. > This makes practically all firewalls noncompliant. That's not > OK. We are not specifying firewalls. We are specifying **NATs**. In fact, most firewalls drop UDP, at least to some extent, as well. > S 3.2. > Below is justification for making the endpoint independent mapping > for ICMP query IDs a SHOULD [RFC2119] requirement. ICMP Ping and > ICMP traceroute ([RFC1470]) are two most commonly known legacy > applications built on top of ICMP query messages. Neither of these > applications require the ICMP Query Id to be retained across > different sessions with external hosts. But, that may not be case > with future applications. In the future, when an endhost > application reuses the same Query identifier in sessions with > different target hosts, the endhost application might require that > the endpoint identity (i.e., the tuple of IP address and Query > Identifier) appears the same across all its target hosts. > It's not clear to me that it's a good idea placing additional > requirements on NATs for future hypothetical protocols, given > that there's not exactly a flood of new ICMP-based protocols. > How many NATs are currently compliant with this? Probably most of the NATs that handle unknown ICMP types in a sane manner,= =20 which is to say, as if it were an unknown (or non "multiplex-able") protoco= l=20 running on IP. I don't think this matters a lot though, since indeed, it's= =20 unlikely we will add new useful ICMP types at this point in time. > S 4.1. > Appendix C of [ICMP-ATK] points out that newer revision end host > TCP stacks do not accept ICMP error messages with a mismatched > IP or TCP checksum in the embedded packet. NAT devices should > ensure that ICMP Error payload is not corrupted. > But this is very frequently not possible because of truncation. > You cover this below, but this guidance here seems confusing. True. However, NATs should fix the "embedded" IP and layer-4 checksums, whi= ch=20 is do-able because of IP checksum kindof-linearity (Linux/NetFilter does th= at=20 by the way), i.e. compensate for the checksum difference caused by the=20 NAT-caused modifications. > S 9. > This document does not introduce any new security concerns related > to ICMP error message handling in the NAT devices. However, the > > This isn't true because REQ1 reverses a security decision that > firewall vendors have made. This needs analysis. This "decision" was never backed by IETF as far as I can tell. And from the= =20 discussion on this list, and earlier ICMP blackhole documentation, I would= =20 even argue that their decision was wrong. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 22 08:37: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 1HUMXE-0005SJ-5O; Thu, 22 Mar 2007 08:36:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMXC-0005SD-OR for behave@ietf.org; Thu, 22 Mar 2007 08:36:50 -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 1HUMXB-0002Z3-B8 for behave@ietf.org; Thu, 22 Mar 2007 08:36:50 -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 l2MCaXLv029478 for ; Thu, 22 Mar 2007 14:36:47 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 14:36:43 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 14:36:42 +0200 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); Thu, 22 Mar 2007 14:36:43 +0200 Received: from [130.129.23.111] (essapo-nirac25318.europe.nokia.com [10.162.253.18]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2MCafHJ019535; Thu, 22 Mar 2007 14:36:41 +0200 In-Reply-To: <200703221419.09782.remi.denis-courmont@nokia.com> References: <20070322111632.35F651CC22@delta.rtfm.com> <200703221419.09782.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <37D07D7C-3508-49A3-8223-95561B93436B@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] Comments on draft-ietf-behave-nat-icmp-03 Date: Thu, 22 Mar 2007 13:36:38 +0100 To: =?ISO-8859-1?Q?ext_R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Mar 2007 12:36:43.0078 (UTC) FILETIME=[BF13E660:01C76C7E] 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="===============0633507104==" Errors-To: behave-bounces@ietf.org --===============0633507104== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-110-838786996; protocol="application/pkcs7-signature" --Apple-Mail-110-838786996 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On 2007-3-22, at 13:19, ext R=E9mi Denis-Courmont wrote: > Probably most of the NATs that handle unknown ICMP types in a sane =20 > manner, > which is to say, as if it were an unknown (or non "multiplex-able") =20= > protocol > running on IP. I don't think this matters a lot though, since =20 > indeed, it's > unlikely we will add new useful ICMP types at this point in time. As a datapoint, there are new proposals for ICMP error types, such as =20= draft-zhang-btns-icmp-sec-extension, but it's not clear how much =20 traction there is. Lars --Apple-Mail-110-838786996 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjIxMjM2MzlaMCMGCSqGSIb3DQEJBDEWBBQCSIr7hV2cQWhT g6e8CLK8Hp8g/zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAoplDd1tMS6TZVbp51Jtiiyd3ueE71Eo4mT1ozBGJqQdsk+DMqwyc ESJj9qB55b8IjJap4hVvCDPgZPgxA7oT8HczGKNjS8jI0pITRAAeOf0zkl//+2139mlxWZd/SSED Xqx27Blsf57g3ctw1D4iAkSzlejrCh+QVu/U8nWD/9Et1QfsRGeivgb2aZJntwETFArt+8L18Prs Nq5QN6gqomed6B3FzyO6XyYO9IU92XMUoi4ZSXWyIgXqtd5wtzYcIi1j9/zc4YDkclpnngyfcYht eCSD7QAiftc+rVztzexxbGb86iTn48H4BoBZv5GHH9o9xItnTI/EFqJeRv5yDgAAAAAAAA== --Apple-Mail-110-838786996-- --===============0633507104== 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 --===============0633507104==-- From behave-bounces@ietf.org Thu Mar 22 09: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 1HUNnn-0002ag-Ko; Thu, 22 Mar 2007 09:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNnn-0002ab-8u for behave@ietf.org; Thu, 22 Mar 2007 09:58:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUNnl-00014q-VF for behave@ietf.org; Thu, 22 Mar 2007 09:58:03 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2007 14:58:01 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2MDw1RR019271; Thu, 22 Mar 2007 14:58:01 +0100 Received: from [130.129.20.115] (ams3-vpn-dhcp4465.cisco.com [10.61.81.112]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2MDw0lZ022754; Thu, 22 Mar 2007 13:58:00 GMT In-Reply-To: <200703201902.l2KJ29Li011671@venus.xmundo.net> References: <200703201902.l2KJ29Li011671@venus.xmundo.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77310124-63FA-4EA8-8413-F53B7B99A5EF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Thu, 22 Mar 2007 14:57:54 +0100 To: Fernando Gont X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1913; t=1174571881; x=1175435881; c=relaxed/simple; s=amsdkim2001; 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=bHSYoO2Z3p0fwg5qyc0Pizt3olkH5o/WQmlRA9yf+TM=; b=rH3cZTphFI3JL5R2QkxsC7JfuVoYb2s4EQzidqM4uqzrOZF33rb7+uhoBWveNW2xl3QLHgkI BpUZZd4am9rvzNhDOm1VXC7ZBkp6k8LAlCZCFcPKPhn+dvrLOdy79VKf; Authentication-Results: ams-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 In no way is the BEHAVE WG trying to kill ICMP - we encourage it's use. However, when we chartered this group, we agree to try and write our spec in such a way that Firewalls could be "behave compliant". Keep in mind that the goal of this work is to get people that build combination NATs/Firewalls to build things that are compliant with behave and allow developers to build applications that will reliability work with in that environment. We are not specifying firewall behavior, but we are trying to specify NAT behavior such that it is deployable and we find a balance between what would be good for applications and what would not break the goals of why the NAT was deployed. So say there is something that firewalls commonly do, such as block an inbound ping request. We don't recommend this is a good or bad idea in behave - that is out of behave scope - it's about firewalls. What some other behave docts have done to get past this is say "if the device forwards the inbound PING, then the address need to get properly translated." If it forwards or not, is a firewall topic but how the packet gets's translated is a behave topic. Cullen On Mar 20, 2007, at 7:32 PM, Fernando Gont wrote: > At 06:08 p.m. 16/03/2007, Cullen Jennings wrote: > >> I disagree that a NAT must forward ICMP packets at all - we agree to >> try and not specify firewall behavior but also we agree not to >> specify things such that firewalls would automatically not be >> compliant with behave. > > If you want to get rid of ICMP, you should raise it on the Int-Area > list, I guess. Killing ICMP is not a decision that is within the > scope of this WG. > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 22 13:32: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 1HUR8r-0003Qx-6m; Thu, 22 Mar 2007 13:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIYG-0004fx-FA for behave@ietf.org; Thu, 22 Mar 2007 04:21:40 -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 1HUIYD-0002uL-WF for behave@ietf.org; Thu, 22 Mar 2007 04:21:40 -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 l2M8L4Nt012111; Thu, 22 Mar 2007 10:21:32 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 10:21:30 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 10:21:29 +0200 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: Thu, 22 Mar 2007 10:21:28 +0200 Message-ID: In-Reply-To: <1174513829.4192.60.camel@sioux.systems.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SecDir review of draft-ietf-behave-tcp-05 Thread-Index: AcdsAvQNop0zd2DzQx+9Ow8WXkFOiQAVmKSg References: <1174513829.4192.60.camel@sioux.systems.cs.cornell.edu> From: To: , X-OriginalArrivalTime: 22 Mar 2007 08:21:29.0816 (UTC) FILETIME=[17A98D80:01C76C5B] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Thu, 22 Mar 2007 13:32:00 -0400 Cc: Subject: [BEHAVE] RE: SecDir review of draft-ietf-behave-tcp-05 X-BeenThere: behave@ietf.org X-Mailman-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 Guha wrote: > > 1) The document does not seem to mention rewriting of TCP sequence > > numbers, which some NATs do. Among other things, this can break > > SACK (unless the SACK is also rewritten). Perhaps this issue > > should be mentioned, and possibly some recommendation given? >=20 > This issue, while a valid concern, is out-of-scope of this > document. The scope currently states "Middlebox behavior that is=20 > not necessary for network address translation of TCP is > out-of-scope". NATs are not _required_ to rewrite TCP Seq# for TCP > translation. 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).=20 I think prohibiting behavior known to break TCP, which is known to be implemented by some NATs, should be in scope. NAT implementors may not realize that incorrectly implemented seq# rewriting actually breaks things... and even if SACK is handled correctly, it breaks the ability to add certain kinds of options to TCP later. So actually NOT rewriting TCP seq# is required for future-proof correct=20 translation of TCP. IMHO this document should alert NAT implementors that seq# rewriting is difficult to implement correctly today, and impossible to implement=20 correctly in a future-proof way. I'm not suggesting any extensive changes;=20 five lines or something should be quite enough. Best regards, Pasi _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Mar 24 12:40: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 1HV9HW-0001ft-L3; Sat, 24 Mar 2007 12:39:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV9HW-0001fo-6D for behave@ietf.org; Sat, 24 Mar 2007 12:39:54 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HV9HQ-0006hC-T3 for behave@ietf.org; Sat, 24 Mar 2007 12:39:54 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1069934nzd for ; Sat, 24 Mar 2007 09:39:46 -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=pF+XFFG6Tjvq/pNG5yaqboasMT+TpBgBpuKFVReT9cumbQDD0Vd/mN7LWtZLjtmySuCIK4U56Iza/KQbzMDKJi7vYsOVSVwpdMwpymoxL4HGr/B9WDe8ZCMYFQooYCFx2idpNo0n6zw5B6XliK8Ak+vPOi+Urv2ycbGzKi5E6hc= 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=YJSrmMTBdMRWJpNtv8W/NmeQJn6cQzheCx0GNGgB7vCVCjDx1TZ2zgOPRwmyp1E+eYoxbaKcp0HkNEDZ7GrNpo6OSbjvtx84iG3bMyrhs/ENx+1zxJYODmsQ933eXYkV/+C3ZxiGjKiG5m7wlzMwS7MaEKR0jSx4SfRcJy8ceY0= Received: by 10.64.181.12 with SMTP id d12mr9364032qbf.1174754386106; Sat, 24 Mar 2007 09:39:46 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTP id o53sm15077238nfa.2007.03.24.09.39.42; Sat, 24 Mar 2007 09:39:44 -0700 (PDT) Message-ID: <4605544E.4000300@gmail.com> Date: Sun, 25 Mar 2007 01:39:42 +0900 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: 6d62ab47271805379d7172ee693a45db Subject: [BEHAVE] message-integrity and the length 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 It is not clear enough how to compute the MESSAGE-INTEGRITY attribute: should the length field of the STUN message be calculated before adding the MESSAGE-INTEGRITY attribute or should it be initialy calculated discluding the size of the MESSAGE-INTEGRITY attribute and update it after the MESSAGE-INTEGRITY is calculated? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Mar 25 13:44: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 1HVWjd-00048e-8q; Sun, 25 Mar 2007 13:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVWjb-00048Z-56 for behave@ietf.org; Sun, 25 Mar 2007 13:42:27 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVWjY-00074l-Rv for behave@ietf.org; Sun, 25 Mar 2007 13:42:27 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1930498wxd for ; Sun, 25 Mar 2007 10:42:24 -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:mime-version:content-type; b=tB2qxPbFh9E+1Gzx50QFuHyR4RgbGs9t6B0PwYMvC0/VfF/TofSyxvkF251EIytECFiIo+hCZReR/rbvmE0ZJR8P5bizC/Ed5jjP193y8XUCDI4yu8NrjSaXASKlOvmy60XWS7K4CKja47OjrH9Uysk31vSqBkkzlcOfSJJfq70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Ul/qhl+crvGwBgu0FSUAyefsQsSvp4x5aRenAeV8Wk14EVhG3UilH44vOUTRUeCEiuoKSf+JZG++eBiNQsKgH8I5vzq9X1M2ohKmPO+TT4Wb8WE9/0RL5NyoAIL4rp2WDKgGQOqKEoXHfOoef65kGQ36ipkqSGxiRDoSSPa0MM4= Received: by 10.90.68.15 with SMTP id q15mr6177012aga.1174844544085; Sun, 25 Mar 2007 10:42:24 -0700 (PDT) Received: by 10.90.84.18 with HTTP; Sun, 25 Mar 2007 10:42:24 -0700 (PDT) Message-ID: Date: Sun, 25 Mar 2007 23:12:24 +0530 From: "Mayank Dev Sondhi" To: behave@ietf.org Subject: [BEHAVE] LENGTH field and possible Denial Of Service even with MESSAGE-INTEGRITY MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: behave@ietf.org X-Mailman-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="===============0708363025==" Errors-To: behave-bounces@ietf.org --===============0708363025== Content-Type: multipart/alternative; boundary="----=_Part_44275_32315602.1174844544049" ------=_Part_44275_32315602.1174844544049 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I was thinking about this for a little while, and this thought crossed my mind. In say a normal attack scenario, in some cases fiddling with the length value for a STUN message can very easily lead to a denial of Service to the client. This is especially true for a TCP/STREAM protocol oriented approach. For example, Let us say the server uses the Length field in a STUN packet to find out where the MESSAGE-INTEGRITY field is, in most cases there is no other way that the server can do this apart from using the LENGTH field. A malicious user can always extend the field length(the MI would be wrong of course) to an arbitrarily large value. What would happen is that if the server uses a buffer length of say X for receiving from its socket, on receipt of a length value >> X it will assume that more data needs to be buffered, it will thus wait for the client to send more, but from the client's perspective it is waiting for a server response(since it had sent a valid request). Ultimately the server or the client would abort the connection and most probably retry again. It would take some trials for a malicious/rogue attacker, to figure out a large enough len value but it is possible. So my question is this, would it be possible to "protect" against this situation? The framing approach describe in draft version 2 and 3 also would not help as it is trivial to increase the length in the frame AND the STUN message. One possible way of protection is having the MI BEFORE the Length attribute in the STUN packet. Does this analysis seem feasible? Am I potentially barking up a wrong tree?? :-) What other measures can be taken to protect against this? Are there some rough BEHAVE guidelines that can nullify this threat? Thanks Mayank ------=_Part_44275_32315602.1174844544049 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I was thinking about this for a little while, and this thought crossed my mind. In say a normal attack scenario, in some cases fiddling with the length value for a STUN message can very easily lead to a denial of Service to the client. This is especially true for a TCP/STREAM protocol oriented approach.
 
For example,
Let us say the server uses the Length field in a STUN packet to find out where the MESSAGE-INTEGRITY field is, in most cases there is no other way that the server can do this apart from using the LENGTH field.
 
A malicious user can always extend the field length(the MI would be wrong of course) to an arbitrarily large value. What would happen is that if the server uses a buffer length of say X for receiving from its socket, on receipt of a length value >> X it will assume that more data needs to be buffered, it will thus wait for the client to send more, but from the client's perspective it is waiting for a server response(since it had sent a valid request). Ultimately the server or the client would abort the connection and most probably retry again. It would take some trials for a malicious/rogue attacker, to figure out a large enough len value but it is possible.
 
So my question is this, would it be possible to "protect" against this situation? The framing approach describe in draft version 2 and 3 also would not help as it is trivial to increase the length in the frame AND the STUN message. One possible way of protection is having the MI BEFORE the Length attribute in the STUN packet.
 
Does this analysis seem feasible? Am I potentially barking up a wrong tree?? :-) What other measures can be taken to protect against this? Are there some rough BEHAVE guidelines that can nullify this threat?
 
Thanks
Mayank
------=_Part_44275_32315602.1174844544049-- --===============0708363025== 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 --===============0708363025==-- From behave-bounces@ietf.org Sun Mar 25 20: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 1HVdGD-00010q-IO; Sun, 25 Mar 2007 20:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVdGC-00010j-BP for behave@ietf.org; Sun, 25 Mar 2007 20:40:32 -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 1HVdGA-0002GH-2a for behave@ietf.org; Sun, 25 Mar 2007 20:40:32 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Mar 2007 20:40:27 -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, 25 Mar 2007 20:40:26 -0400 From: Saikat Guha To: Pasi.Eronen@nokia.com In-Reply-To: References: <1174513829.4192.60.camel@sioux.systems.cs.cornell.edu> Date: Sun, 25 Mar 2007 20:40:26 -0400 Message-Id: <1174869626.21195.43.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 (2.10.0-2.fc7) X-OriginalArrivalTime: 26 Mar 2007 00:40:26.0582 (UTC) FILETIME=[58BE0760:01C76F3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: behave@ietf.org Subject: [BEHAVE] RE: SecDir review of draft-ietf-behave-tcp-05 X-BeenThere: behave@ietf.org X-Mailman-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="===============1979533783==" Errors-To: behave-bounces@ietf.org --===============1979533783== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6o1Xy7RgQ6Ew/9g0cWfK" --=-6o1Xy7RgQ6Ew/9g0cWfK Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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).=20 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, --=20 Saikat --=-6o1Xy7RgQ6Ew/9g0cWfK 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) iD8DBQBGBxZ6nFltqi691/oRArDTAJwO8PQnef/BIpDbkhlHyJFwbTd83QCcCKiu KjJUuDvsxbW+Ek7WFdAdMiI= =gu5X -----END PGP SIGNATURE----- --=-6o1Xy7RgQ6Ew/9g0cWfK-- --===============1979533783== 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 --===============1979533783==-- From behave-bounces@ietf.org Mon Mar 26 00:32: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 1HVgrX-0001JK-ML; Mon, 26 Mar 2007 00:31:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVgrV-0001J8-Iy for behave@ietf.org; Mon, 26 Mar 2007 00:31:17 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVgrT-000078-6S for behave@ietf.org; Mon, 26 Mar 2007 00:31:17 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DE670F0C429; Mon, 26 Mar 2007 01:31:19 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2Q4V74Y008254; Mon, 26 Mar 2007 01:31:12 -0300 Message-Id: <200703260431.l2Q4V74Y008254@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Mar 2007 00:07:34 -0300 To: Cullen Jennings From: Fernando Gont Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt In-Reply-To: <77310124-63FA-4EA8-8413-F53B7B99A5EF@cisco.com> References: <200703201902.l2KJ29Li011671@venus.xmundo.net> <77310124-63FA-4EA8-8413-F53B7B99A5EF@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 26 Mar 2007 01:31:19 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 10:57 a.m. 22/03/2007, Cullen Jennings wrote: >So say there is something that firewalls commonly do, such as block >an inbound ping request. We don't recommend this is a good or bad >idea in behave - that is out of behave scope - it's about firewalls. >What some other behave docts have done to get past this is say "if >the device forwards the inbound PING, then the address need to get >properly translated." If it forwards or not, is a firewall topic but >how the packet gets's translated is a behave topic. The WG is issuing requirements for NATs, not for firewalls. (The fact that these two functions are usually implemented in the same fox is a separate issue). IMO, as a NAT, is just supposed to do address tranlation, *not* filtering. As a result, the core Internet protocols should be supported, and the requirements should be stated considering the core protocols are supported. IMHO, if some firewall-like functionality later decides to disable ICMP (or some other core protocolol, such as TCP), that is not something that this wg should be concerned about..... unless we include firewalls in the charter. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Mar 26 03:36: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 1HVjje-0003vF-2e; Mon, 26 Mar 2007 03:35:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVjjc-0003v4-Pm for behave@ietf.org; Mon, 26 Mar 2007 03:35:20 -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 1HVjjZ-0003Ne-HP for behave@ietf.org; Mon, 26 Mar 2007 03:35:20 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 03:35:16 -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, 26 Mar 2007 03:35:16 -0400 Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt From: Saikat Guha To: Fernando Gont In-Reply-To: <200703260431.l2Q4V74Y008254@venus.xmundo.net> References: <200703201902.l2KJ29Li011671@venus.xmundo.net> <77310124-63FA-4EA8-8413-F53B7B99A5EF@cisco.com> <200703260431.l2Q4V74Y008254@venus.xmundo.net> Date: Mon, 26 Mar 2007 03:35:16 -0400 Message-Id: <1174894516.5591.29.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 (2.10.0-2.fc7) X-OriginalArrivalTime: 26 Mar 2007 07:35:16.0316 (UTC) FILETIME=[4C2E09C0:01C76F79] 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="===============0037360523==" Errors-To: behave-bounces@ietf.org --===============0037360523== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ReqD/vvxFtfKLMn/GVP7" --=-ReqD/vvxFtfKLMn/GVP7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-03-26 at 00:07 -0300, Fernando Gont wrote: > The WG is issuing requirements for NATs, not for firewalls. Given a mutually exclusive choice between either being BEHAVE complaint or having firewall functionality, vendors will ignore BEHAVE requirements. Search the BEHAVE archives for Linksys's reaction to the endpoint filtering requirement posted by Cullen around summer'05. For BEHAVE to have any impact, requirements *MUST NOT* be mutually exclusive with reasonable firewall functionality. 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. --=20 Saikat --=-ReqD/vvxFtfKLMn/GVP7 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) iD8DBQBGB3eunFltqi691/oRAotCAJ97DFTSf+/hukpzf56oaJTzJFw1qwCfVH1+ jyc8e0lFjK9j0ekhY85vIuo= =7QDO -----END PGP SIGNATURE----- --=-ReqD/vvxFtfKLMn/GVP7-- --===============0037360523== 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 --===============0037360523==-- From behave-bounces@ietf.org Mon Mar 26 04:14: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 1HVkKr-0001ml-T2; Mon, 26 Mar 2007 04:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVkKq-0001mg-K5 for behave@ietf.org; Mon, 26 Mar 2007 04:13:48 -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 1HVkKn-0001D4-4B for behave@ietf.org; Mon, 26 Mar 2007 04:13:48 -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 l2Q8DCcv012634; Mon, 26 Mar 2007 11:13:24 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 11:13:24 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 11:13:23 +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, 26 Mar 2007 11:13:23 +0300 Received: from [172.21.35.191] (esdhcp035191.research.nokia.com [172.21.35.191]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2Q8DMFq010403; Mon, 26 Mar 2007 11:13:22 +0300 In-Reply-To: <1174894516.5591.29.camel@sioux.systems.cs.cornell.edu> 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> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <37F0BD4A-FE39-49E2-926A-42A973B4BE45@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Mon, 26 Mar 2007 10:13:22 +0200 To: ext Saikat Guha X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Mar 2007 08:13:24.0006 (UTC) FILETIME=[9FBFD460:01C76F7E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070326111324-297E3BB0-57788FEB/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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="===============1761824398==" Errors-To: behave-bounces@ietf.org --===============1761824398== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--978893260; protocol="application/pkcs7-signature" --Apple-Mail-8--978893260 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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.) One way to capture this would be to say "a NAT that translates transport protocol X SHOULD also translate ICMP messages Y and Z, because otherwise ". Lars --Apple-Mail-8--978893260 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjYwODEzMjJaMCMGCSqGSIb3DQEJBDEWBBS8eqUFflDgEDV1 h451hzkQaL7bAjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAlDgfyIkWuQSfAskrcihjk7zM/UN6xTrgXizAIpFNMUrFiAs0KiSL wM+GvEG2VWR8qKAmfuAPB91heO7Y1EY7ksz5zueiJAAPiLDnUEUZ9Ft5pnEcXxPtFVU8oFbeGju3 1Txm/poMAVDhXnnK+0pvIARMnFGOVjcyXnwLOgJI/gRK+u8ciZCRuuvLHd+GoQKpzYCJ2OmXxDCQ 8W1WoywKLiMQar6FsxKGPYrhCkX8olfOIryxa19nIVva2dGbdlDsLb0jgYrgXsy4WZhV1X55f36X u7gF1GqLsgIaebTl/G7Z79TPazf9PpNEhdy1LzNwKRn79xb/kbyepfCWuZNq9wAAAAAAAA== --Apple-Mail-8--978893260-- --===============1761824398== 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 --===============1761824398==-- From behave-bounces@ietf.org Mon Mar 26 10:32: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 1HVqEs-00031g-80; Mon, 26 Mar 2007 10:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqEr-00031Z-Hc for behave@ietf.org; Mon, 26 Mar 2007 10:32:01 -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 1HVqEp-00083I-9H for behave@ietf.org; Mon, 26 Mar 2007 10:32:01 -0400 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 10:31:58 -0400 Received: from [172.23.16.23] ([172.23.16.23]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 10:31:58 -0400 Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt From: Saikat Guha To: Lars Eggert 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> Organization: Cornell University Date: Mon, 26 Mar 2007 10:28:53 -0400 Message-Id: <1174919333.24573.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 26 Mar 2007 14:31:58.0125 (UTC) FILETIME=[826B55D0:01C76FB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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="===============2079885646==" Errors-To: behave-bounces@ietf.org --===============2079885646== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xZEtB/WcNee15rfV09v+" --=-xZEtB/WcNee15rfV09v+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-03-26 at 10:13 +0200, Lars Eggert wrote: > One way to capture this would be to say "a NAT that translates =20 > transport protocol X SHOULD also translate ICMP messages Y and Z, =20 > because otherwise ". Agreed. I actually meant ICMP support for query-response pairs (ping, timestamp request etc.) should be optional. Old text: REQ-1: A NAT device MUST permit ICMP query based applications to be initiated from private hosts to the external hosts.=20 a) NAT mapping of ICMP Query identifiers SHOULD be external host=20 independent. Suggested new text: REQ-1: If a NAT device permits ICMP query based applications to be initiated from private hosts to the external hosts, then the NAT=20 mapping of ICMP Query identifiers SHOULD be external host=20 independent. As for Section 4 (handling ICMP errors earned from the network), suggest adding: REQ-X: A NAT device that translates TCP packets MUST translate ICMP Can't Fragment (Type=3D3,Code=3D4) errors. --=20 Saikat --=-xZEtB/WcNee15rfV09v+ 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) iD8DBQBGB9ilnFltqi691/oRAsnEAJ9TvXiYFsDFi4r5FpUTXWPrXO8ZOwCdEmga hAb06KQC8xmr1c3AKzIYgCY= =wxZp -----END PGP SIGNATURE----- --=-xZEtB/WcNee15rfV09v+-- --===============2079885646== 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 --===============2079885646==-- From behave-bounces@ietf.org Mon Mar 26 10:43: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 1HVqPp-0002Wg-W6; Mon, 26 Mar 2007 10:43:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqPC-0001iG-EC for behave@ietf.org; Mon, 26 Mar 2007 10:42:42 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVqKQ-000173-6B for behave@ietf.org; Mon, 26 Mar 2007 10:37:58 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 26 Mar 2007 07:37:45 -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 l2QEbjaH002466; Mon, 26 Mar 2007 07:37:45 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2QEbMwx005840; Mon, 26 Mar 2007 14:37:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 10:37:10 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 10:37:10 -0400 Message-ID: <4607DA95.2030404@cisco.com> Date: Mon, 26 Mar 2007 10:37:09 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: behave@ietf.org, Rohan Mahy , Derek MacDonald , Bruce Lowekamp , Dan Wing , Gonzalo Camarillo , "Oscar Novo (JO/LMF)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2007 14:37:10.0285 (UTC) FILETIME=[3C7B2BD0:01C76FB4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=737; t=1174919865; x=1175783865; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20claiming=20stun=20attributes=200x8029=20and=200x802a=20for=20 ICE |Sender:=20; bh=Y3azqIqicSavEdYoalplWyiVmOjqfAF1ws9dYVsPAWI=; b=SZnAuWtf6TbjLQGn2Em3Z493aP8SByUS3DMa9b2RKB9DBwng3+W8ZPOBM2ei4UBxY0PDrWRX 3TxE37Uuaa66L936OF5zph4BDf6Wek4ADkmV4WnfeKrfdmg+4wrwxTZ1; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [BEHAVE] 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 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 Mon Mar 26 10: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 1HVqQo-0003jF-J8; Mon, 26 Mar 2007 10:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqQn-0003em-1E for behave@ietf.org; Mon, 26 Mar 2007 10:44:21 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVqQk-0002pE-N7 for behave@ietf.org; Mon, 26 Mar 2007 10:44:21 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Mar 2007 10:44:19 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2QEiI1D011120 for ; Mon, 26 Mar 2007 10:44:18 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2QEiFGl018036 for ; Mon, 26 Mar 2007 14:44:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 10:44:16 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 10:44:15 -0400 Message-ID: <4607DC3F.8090000@cisco.com> Date: Mon, 26 Mar 2007 10:44:15 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2007 14:44:15.0798 (UTC) FILETIME=[3A1B4D60:01C76FB5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=720; t=1174920258; x=1175784258; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20STUN=20error=20response=20registry |Sender:=20 |To:=20behave@ietf.org; bh=eSNTXwbI6B+Kj/PUImpj+udGnJZHCkkQKqNByqcf0wM=; b=M0qi6whtYWLQ4n/PwstOkiUW2ldlaWzymm5XEIYXyuA0DLfhqqrl1VxtuYTGTKkqRvhOA4Au kucEad2sx+yN/aDsfeT3YUD4oypSPTz7fwlWulVqG3mounmhbB8FKYvx; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [BEHAVE] STUN error response registry X-BeenThere: behave@ietf.org X-Mailman-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 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. I also suggest that having a working webpage like: http://www.employees.org/behave/stun-attributes.html but for responses would be mighty useful. 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 Mon Mar 26 10:49: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 1HVqUu-0007ab-ER; Mon, 26 Mar 2007 10:48:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqUt-0007aR-9Z for behave@ietf.org; Mon, 26 Mar 2007 10:48:35 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVqUs-0003T5-1l for behave@ietf.org; Mon, 26 Mar 2007 10:48:35 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Mar 2007 10:48:34 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2QEmXeI013384 for ; Mon, 26 Mar 2007 10:48:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2QEmFlm013859 for ; Mon, 26 Mar 2007 14:48:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 10:48:29 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 10:48:29 -0400 Message-ID: <4607DD3C.5080108@cisco.com> Date: Mon, 26 Mar 2007 10:48:28 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2007 14:48:29.0328 (UTC) FILETIME=[D138E900:01C76FB5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=385; t=1174920513; x=1175784513; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20claiming=20STUN=20error=20response=20487 |Sender:=20 |To:=20behave@ietf.org; bh=aitCRWDgP2R0uADjHoFDZFGRZGqsqiU5+siTKFKgagU=; b=TTIpq310xneT4hmZ9gS+7FikXG+I6ZoStD0ImWV8Q3lXSV5NudQKc3DoQk/Rdu89hRykcDIv Ifl2uoKi/Fn7UXIHOarvhExPeI3Os9rXQHFaQRiC+XdvRgIog5gUswrU; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [BEHAVE] claiming STUN error response 487 X-BeenThere: behave@ietf.org X-Mailman-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 ice-15. Please do not use in other drafts. -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 Mon Mar 26 22:15: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 1HW1CC-0008Qg-UQ; Mon, 26 Mar 2007 22:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW1CB-0008QV-LQ for behave@ietf.org; Mon, 26 Mar 2007 22:13:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW1CA-000509-CE for behave@ietf.org; Mon, 26 Mar 2007 22:13:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Mar 2007 22:13:59 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2R2DwHY009610; Mon, 26 Mar 2007 22:13:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2R2DvGd002819; Tue, 27 Mar 2007 02:13:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 22:13:57 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 22:13:57 -0400 Message-ID: <46087DE5.4080709@cisco.com> Date: Mon, 26 Mar 2007 22:13:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mayank Dev Sondhi Subject: Re: [BEHAVE] LENGTH field and possible Denial Of Service even with MESSAGE-INTEGRITY References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 02:13:57.0521 (UTC) FILETIME=[93892010:01C77015] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1966; t=1174961638; x=1175825638; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20LENGTH=20field=20and=20possible=20Denial=2 0Of=20Service=20even=20with=0A=20MESSAGE-INTEGRITY |Sender:=20 |To:=20Mayank=20Dev=20Sondhi=20; bh=i2LBEBtfLRhb+f5P9GT7Hk0sHScOGgvDYYoketoWIMQ=; b=Btol+TRxvcezPV6vzm+oYNOVsTCPaGruXDYA0uAOGgyMU/+3xCTfLO/WmraYRdPzETonozeQ fKKGvpGfZxBZYVmVD7Bg5Mg7QDiXiDgHNfR7Q7sgyGQ5fOCvTVaI7D2L; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Mayank Dev Sondhi wrote: > I was thinking about this for a little while, and this thought crossed > my mind. In say a normal attack scenario, in some cases fiddling with > the length value for a STUN message can very easily lead to a denial of > Service to the client. This is especially true for a > TCP/STREAM protocol oriented approach. I think your attack is specific to TCP. > > For example, > Let us say the server uses the Length field in a STUN packet to find out > where the MESSAGE-INTEGRITY field is, in most cases there is no other > way that the server can do this apart from using the LENGTH field. > > A malicious user can always extend the field length(the MI would be > wrong of course) to an arbitrarily large value. What would happen is > that if the server uses a buffer length of say X for receiving from its > socket, on receipt of a length value >> X it will assume that more data > needs to be buffered, it will thus wait for the client to send more, but > from the client's perspective it is waiting for a server response(since > it had sent a valid request). Ultimately the server or the client would > abort the connection and most probably retry again. It would take some > trials for a malicious/rogue attacker, to figure out a large enough len > value but it is possible. I'm missing something here. If the client is malicious, it will only end up messing up the framing between itself and the server, so what is the point of that. If you are talking a MITM, you would mitigate this with TLS and so the STUN would be protected by TLS. -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 Mon Mar 26 22:17: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 1HW1FW-00035R-EG; Mon, 26 Mar 2007 22:17:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW1FS-00035I-Rv for behave@ietf.org; Mon, 26 Mar 2007 22:17:22 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW1FQ-0005ka-GT for behave@ietf.org; Mon, 26 Mar 2007 22:17:22 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 26 Mar 2007 19:17:20 -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 l2R2HJXV012922; Mon, 26 Mar 2007 19:17:19 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2R2GaAU013322; Tue, 27 Mar 2007 02:17:19 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 22:16:49 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 22:16:48 -0400 Message-ID: <46087E90.9080606@cisco.com> Date: Mon, 26 Mar 2007 22:16:48 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Evgeniy Khramtsov Subject: Re: [BEHAVE] message-integrity and the length field References: <4605544E.4000300@gmail.com> In-Reply-To: <4605544E.4000300@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 02:16:48.0743 (UTC) FILETIME=[F9978770:01C77015] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=923; t=1174961840; x=1175825840; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20message-integrity=20and=20the=20length=20f ield |Sender:=20; bh=pON4k/zAHoOSbQ50KH7V+XqrxitD8dSfqZ1w1w2/jE4=; b=RmB3dHQzospZ8NQklnZnZzllkItn8iYJHKPPTqwbKqOwLTWg6qzCedLdEVfeLa/RnMiXARt6 Jrub57pampWIJ5jCzUyqSJFtMHO3MBOLNi6FmbU0XZ2ViCZyxYR2mZBt; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 M-I is of fixed length (20 bytes), so either way works. -Jonathan R. Evgeniy Khramtsov wrote: > It is not clear enough how to compute the MESSAGE-INTEGRITY attribute: > should the length field of the STUN message be calculated before adding > the MESSAGE-INTEGRITY attribute or should it be initialy calculated > discluding the size of the MESSAGE-INTEGRITY attribute and update it > after the MESSAGE-INTEGRITY is calculated? > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Mar 27 12:44: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 1HWEls-0005TW-AR; Tue, 27 Mar 2007 12:43:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWElr-0005TQ-1z for behave@ietf.org; Tue, 27 Mar 2007 12:43:43 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWElp-0006JQ-Ko for behave@ietf.org; Tue, 27 Mar 2007 12:43:43 -0400 Received: by wx-out-0506.google.com with SMTP id h31so2616335wxd for ; Tue, 27 Mar 2007 09:43:41 -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=FkVrJtH/5XSGREPbULhmxq9f31tvz9IRM5bHXmq17VoDTGb2wU3MuiR2s/T3RimN6bg1uPq4SKz0fLRISOQj4Rad0YDdh1r/KqRD/KuvbVwXMPJLfzigomLh2uosATbkY/Uc8+2uNCTketfr6XC+Vsvpd1i9+mLmfU6tDUmY63A= 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=BVfm3VZSnrEecIfcPAVNmrspP9PHwUhAmubcg4KjrTOxYSYrJLt8fPixVLmS42Gg5yqK2cxy0DvxbFtgd2XDiviCNnW1kdTeHJG8SUMCf9u+4MzfYuSZ3RkhTtdLWB+WiIOQWHqwfyvi/TxGOD2gCf4PHTTEvLI4VwpbT7Bp7lY= Received: by 10.90.93.6 with SMTP id q6mr2119886agb.1175013821258; Tue, 27 Mar 2007 09:43:41 -0700 (PDT) Received: by 10.90.84.18 with HTTP; Tue, 27 Mar 2007 09:43:41 -0700 (PDT) Message-ID: Date: Tue, 27 Mar 2007 22:13:41 +0530 From: "Mayank Dev Sondhi" To: "Jonathan Rosenberg" Subject: Re: [BEHAVE] LENGTH field and possible Denial Of Service even with MESSAGE-INTEGRITY In-Reply-To: <46087DE5.4080709@cisco.com> MIME-Version: 1.0 References: <46087DE5.4080709@cisco.com> X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============1782585407==" Errors-To: behave-bounces@ietf.org --===============1782585407== Content-Type: multipart/alternative; boundary="----=_Part_4818_29766149.1175013821026" ------=_Part_4818_29766149.1175013821026 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 3/27/07, Jonathan Rosenberg wrote: > > > > Mayank Dev Sondhi wrote: > > > I was thinking about this for a little while, and this thought crossed > > my mind. In say a normal attack scenario, in some cases fiddling with > > the length value for a STUN message can very easily lead to a denial of > > Service to the client. This is especially true for a > > TCP/STREAM protocol oriented approach. > > I think your attack is specific to TCP. Yes it is. > > > For example, > > Let us say the server uses the Length field in a STUN packet to find out > > where the MESSAGE-INTEGRITY field is, in most cases there is no other > > way that the server can do this apart from using the LENGTH field. > > > > A malicious user can always extend the field length(the MI would be > > wrong of course) to an arbitrarily large value. What would happen is > > that if the server uses a buffer length of say X for receiving from its > > socket, on receipt of a length value >> X it will assume that more data > > needs to be buffered, it will thus wait for the client to send more, but > > from the client's perspective it is waiting for a server response(since > > it had sent a valid request). Ultimately the server or the client would > > abort the connection and most probably retry again. It would take some > > trials for a malicious/rogue attacker, to figure out a large enough len > > value but it is possible. > > I'm missing something here. If the client is malicious, it will only end > up messing up the framing between itself and the server, so what is > the point of that. If you are talking a MITM, you would mitigate this > with TLS and so the STUN would be protected by TLS. Yes this is relative to MITM, TLS for ALLOCATEs is too heavy I presume? Or would TLS be used for ALLOCATIONs also? What about SEND requests? Wouldn't SENDs and data streaming be overtly burdensome for a server over TLS? -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 Thanks Mayank ------=_Part_4818_29766149.1175013821026 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 3/27/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:


Mayank Dev Sondhi wrote:

> I was thinking about this for a little while, and this thought crossed
> my mind. In say a normal attack scenario, in some cases fiddling with
> the length value for a STUN message can very easily lead to a denial of
> Service to the client. This is especially true for a
> TCP/STREAM protocol oriented approach.

I think your attack is specific to TCP.
 
Yes it is.

>
> For example,
> Let us say the server uses the Length field in a STUN packet to find out
> where the MESSAGE-INTEGRITY field is, in most cases there is no other
> way that the server can do this apart from using the LENGTH field.
>
> A malicious user can always extend the field length(the MI would be
> wrong of course) to an arbitrarily large value. What would happen is
> that if the server uses a buffer length of say X for receiving from its
> socket, on receipt of a length value >> X it will assume that more data
> needs to be buffered, it will thus wait for the client to send more, but
> from the client's perspective it is waiting for a server response(since
> it had sent a valid request). Ultimately the server or the client would
> abort the connection and most probably retry again. It would take some
> trials for a malicious/rogue attacker, to figure out a large enough len
> value but it is possible.

I'm missing something here. If the client is malicious, it will only end
up messing up the framing between itself and the server, so what is
the point of that. If you are talking a MITM, you would mitigate this
with TLS and so the STUN would be protected by TLS.
 
Yes this is relative to MITM, TLS for ALLOCATEs is too heavy I presume? Or would TLS be used for ALLOCATIONs also? What about SEND requests? Wouldn't SENDs and data streaming be overtly burdensome for a server over TLS?

-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
 
Thanks
Mayank

 
------=_Part_4818_29766149.1175013821026-- --===============1782585407== 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 --===============1782585407==-- From behave-bounces@ietf.org Wed Mar 28 12:25: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 1HWaxV-00063E-MT; Wed, 28 Mar 2007 12:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWaxT-0005uh-IX for behave@ietf.org; Wed, 28 Mar 2007 12:25:11 -0400 Received: from mx5-4.spamtrap.magma.ca ([209.217.78.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWaxR-0002mB-9I for behave@ietf.org; Wed, 28 Mar 2007 12:25:11 -0400 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx5-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l2SGOnTl004285; Wed, 28 Mar 2007 12:24:49 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l2SGOluu026541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Mar 2007 12:24:49 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20D09E88-7BA9-49BD-93C9-2969B3C31F41@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt Date: Wed, 28 Mar 2007 12:25:04 -0400 To: David Barrett 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: bb8f917bb6b8da28fc948aeffb74aa17 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 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. 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 From behave-bounces@ietf.org Wed Mar 28 12:38: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 1HWb9j-0005sE-Oy; Wed, 28 Mar 2007 12:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWb9i-0005rv-3U for behave@ietf.org; Wed, 28 Mar 2007 12:37:50 -0400 Received: from mx1-3.spamtrap.magma.ca ([209.217.78.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWb9e-0005oH-P7 for behave@ietf.org; Wed, 28 Mar 2007 12:37:50 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx1-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l2SGbhQh017430; Wed, 28 Mar 2007 12:37:43 -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 l2SGbghE016743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Mar 2007 12:37:43 -0400 In-Reply-To: <46087E90.9080606@cisco.com> References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com> 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 Subject: Re: [BEHAVE] message-integrity and the length field Date: Wed, 28 Mar 2007 12:37:58 -0400 To: Jonathan Rosenberg 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: 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: , Errors-To: behave-bounces@ietf.org Is this really true?? My answer would have been that neither way works. As I understand it, the question is: What should be the value of the length field in the STUN header when the message integrity calculation is done? Evgeniy's first option is to set it to the length of the STUN message minus 20 (= the size of the STUN header) minus the size of the Message-Integrity attribute itself. Evgeniy's second option seems to be similar, but I don't really understand what he suggest here. However, I think the correct answer is to set it to the actual length of the STUN message minus 20. This can be done because the size of the MESSAGE-INTEGRITY and FINGERPRINT attributes can be known in advance, even if their values are not known.. - Philip On 26-Mar-07, at 22:16 , Jonathan Rosenberg wrote: > The M-I is of fixed length (20 bytes), so either way works. > > -Jonathan R. > > Evgeniy Khramtsov wrote: > >> It is not clear enough how to compute the MESSAGE-INTEGRITY >> attribute: should the length field of the STUN message be >> calculated before adding the MESSAGE-INTEGRITY attribute or should >> it be initialy calculated discluding the size of the MESSAGE- >> INTEGRITY attribute and update it after the MESSAGE-INTEGRITY is >> calculated? >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 28 13:10: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 1HWbeL-0007Hb-Bm; Wed, 28 Mar 2007 13:09:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWbeJ-0007HT-EM for behave@ietf.org; Wed, 28 Mar 2007 13:09:27 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWbeD-0004ZG-6e for behave@ietf.org; Wed, 28 Mar 2007 13:09:27 -0400 Received: by nz-out-0506.google.com with SMTP id z6so2127329nzd for ; Wed, 28 Mar 2007 10:09:20 -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=h7nEK4al/GvIPJrnvusHHpbBfjjER9dsZCY7OW4xrNq3NseIlqHDyPcPTOS+gSPT/R7K8a3gaYHXs82vqsPhWzn9oFEEXWqMsr/04me+D10i6Iu+b6VLCPN+age4EWuPyB5x//I6W0z3mcXK8T7oSxoALAIl0MfFS7vJVp2G6sQ= 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=LmPUO/r63GGwDhyMlFu5+CYMPvDZ1nYOf/FNNDNi20Hq/cQKzVExz62PvGdLbHX8o1LyXpBU9WNlkAE2KbwexUtfzVOJOq4DfgBj8areW4tL+g+bOVwJrMQSDjVzSlyhV3FVIDP+Sxv0Fm2nbJjD/py2b4y2QonLLOJISqr1z2E= Received: by 10.35.125.16 with SMTP id c16mr16614959pyn.1175101760147; Wed, 28 Mar 2007 10:09:20 -0700 (PDT) Received: by 10.35.107.10 with HTTP; Wed, 28 Mar 2007 10:09:20 -0700 (PDT) Message-ID: <20d2bdfb0703281009vd4ac9b6vdaf6398ad9447f28@mail.gmail.com> Date: Wed, 28 Mar 2007 13:09:20 -0400 From: "Bruce Lowekamp" To: "Philip Matthews" Subject: Re: [BEHAVE] message-integrity and the length field In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com> X-Google-Sender-Auth: b20819181fc8120f X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Agree that the draft isn't clear, but this is what I think it should say, as well. Bruce On 3/28/07, Philip Matthews wrote: > However, I think the correct answer is to set it to the actual length > of the STUN message minus 20. This can be done because the size of > the MESSAGE-INTEGRITY and FINGERPRINT attributes can be known in > advance, even if their values are not known.. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 28 17:04: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 1HWfJ4-0005mO-96; Wed, 28 Mar 2007 17:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWfJ0-0005km-Ci for behave@ietf.org; Wed, 28 Mar 2007 17:03:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWfIz-0000X1-2W for behave@ietf.org; Wed, 28 Mar 2007 17:03:42 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Mar 2007 17:03:41 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2SL3eXM031057; Wed, 28 Mar 2007 17:03:40 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2SL3RGr005643; Wed, 28 Mar 2007 21:03:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 17:03:38 -0400 Received: from [192.168.1.104] ([10.86.242.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 17:03:37 -0400 Message-ID: <460AD829.9060308@cisco.com> Date: Wed, 28 Mar 2007 17:03:37 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] message-integrity and the length field References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2007 21:03:37.0825 (UTC) FILETIME=[8E287D10:01C7717C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=708; t=1175115820; x=1175979820; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20message-integrity=20and=20the=20length=20f ield |Sender:=20 |To:=20Philip=20Matthews=20; bh=c5QuY8glZp3l2yCHQO8dbp88uZbfnB117JBarg/kmxQ=; b=WaWPl2H86ZPsN9WRHVG08e03XplSmANEnW8na1e8plR/ZBzqsF36KvLbsCtx20yWXeKoC15d AW7tiw5WoiFwGj05OEr+975P28In45V4OOVEtn5Jowq73kn2LzBG8mVo; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Philip Matthews wrote: > Is this really true?? My answer would have been that neither way works. Why? Though the CONTENT of the message-integrity is not known, its length is. So you basically add M-I to the message with all-zero content (so now the length is correct), compute the check, and fill in the result into the attribute. What am I missing? -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 Wed Mar 28 18:10: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 1HWgLB-00030E-Nx; Wed, 28 Mar 2007 18:10:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgLA-0002zw-Tq for behave@ietf.org; Wed, 28 Mar 2007 18:10:00 -0400 Received: from mx5-4.spamtrap.magma.ca ([209.217.78.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWgL5-0001Tn-95 for behave@ietf.org; Wed, 28 Mar 2007 18:10:00 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx5-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l2SM9pio008764; Wed, 28 Mar 2007 18:09:51 -0400 Received: from [10.0.1.2] ([24.139.16.154]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l2SM9m60028509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Mar 2007 18:09:51 -0400 In-Reply-To: <460AD829.9060308@cisco.com> References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com> <460AD829.9060308@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] message-integrity and the length field Date: Wed, 28 Mar 2007 18:10:06 -0400 To: Jonathan Rosenberg 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: 0a7aa2e6e558383d84476dc338324fab 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 Jonathan: I agree with what you said below. However, from my reading of Evgeniy Khramtsov's message, this is not what he though should happen. Let me give an example. Say the STUN message has 4 attributes. Three of the attributes have a combined length of 40 bytes, and the last attribute is the MESSAGE-INTEGRITY attribute with a length of 20 bytes. Evgeniy Khramtsov's option 1: Set the length field in the STUN header to 40, compute the check, then append the M-I attribute (but do not update the length field) and send the message. Evgeniy Khramtsov's option 2: Set the length field in the STUN header to 40, compute the check, then append the M-I attribute, add 20 to the length field in the header, and send the message. What I think is the correct answer: Set the length field in the STUN header to 60, compute the check, then append the M-I attribute (leaving the value of the length field at 60) and send the message. Does this make things clear? - Philip On 28-Mar-07, at 17:03 , Jonathan Rosenberg wrote: > > > Philip Matthews wrote: > >> Is this really true?? My answer would have been that neither >> way works. > > Why? Though the CONTENT of the message-integrity is not known, its > length is. So you basically add M-I to the message with all-zero > content (so now the length is correct), compute the check, and fill > in the result into the attribute. What am I missing? > > -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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 28 18:53: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 1HWh11-0008EF-KR; Wed, 28 Mar 2007 18:53:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWh10-0008EA-Pb for behave@ietf.org; Wed, 28 Mar 2007 18:53:14 -0400 Received: from mx5-4.spamtrap.magma.ca ([209.217.78.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWh0y-0001JN-4B for behave@ietf.org; Wed, 28 Mar 2007 18:53:14 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx5-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l2SMr3Ka020465; Wed, 28 Mar 2007 18:53:03 -0400 Received: from [10.0.1.2] ([24.139.16.154]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l2SMr21B025713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Mar 2007 18:53:04 -0400 In-Reply-To: References: <46087DE5.4080709@cisco.com> 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 Subject: Re: [BEHAVE] LENGTH field and possible Denial Of Service even with MESSAGE-INTEGRITY Date: Wed, 28 Mar 2007 18:53:19 -0400 To: Jonathan Rosenberg 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: 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 I see two possible attacks here. In the first attack, a client executes the following code against a given STUN server loop Allocate a local port Open a TCP connection to the server Send a Binding Request end loop If a number of clients execute this attack simultaneously, this will quickly consume TCP Control Blocks and perhaps other resources on a STUN server. The WRONG way to protect against this attack is for the server to close the connection after sending the Binding Response. This is wrong because a normal client doing ICE, for example, will need to hold the connection open as a way of preserving the NAT binding while it does an ICE exchange with some other node. One way to protect against this attack might be to limit the number of TCP connections that a server will accept from the same address. It is not clear to me right now what that limit should be, however. The second attack is a variation on the first. Each client executes the following code: loop Allocate a local port Open a TCP connection to the server Send most (but not all) of a large Binding Request message end loop There are a number of ways a large Binding Request message could be constructed: using very long user-names; including unknown attributes, etc. This attack will often chew up even more resources on a server, because it must hold data about the partly received Binding Request before it can send the response. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Mar 28 21:10: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 1HWj90-0001Zg-38; Wed, 28 Mar 2007 21:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWj8y-0001ZX-3X for behave@ietf.org; Wed, 28 Mar 2007 21:09:37 -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 1HWj8t-0005jc-P7 for behave@ietf.org; Wed, 28 Mar 2007 21:09:36 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 28 Mar 2007 18:09:30 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Wed, 28 Mar 2007 18:09:29 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 28 Mar 2007 18:09:29 -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] message-integrity and the length field Date: Wed, 28 Mar 2007 18:08:34 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064040E24FA@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] message-integrity and the length field Thread-Index: AcdxiZbHU1ij4PmATxGNZ3vz9FXmPgAEt7gA References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com><460AD829.9060308@cisco.com> <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> From: Christian Huitema To: Philip Matthews , Jonathan Rosenberg X-OriginalArrivalTime: 29 Mar 2007 01:09:29.0325 (UTC) FILETIME=[E6BCC1D0:01C7719E] 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 > What I think is the correct answer: > Set the length field in the STUN header to 60, compute the check, > then append the M-I attribute (leaving the value of the length field > at 60) and send the message. The standard practice, in many other protocols, is to encode the complete message with a dummy attribute value (in this case 20 null bytes), compute the checksum, replace the dummy value by the check result, and send the message. The advantage of that method is to not make any assumption about the position of the checksum attribute in the message. For example, RFC 793 includes this text for the computation of the TCP checksum: Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 29 10:53: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 1HWvzC-0002sT-Eg; Thu, 29 Mar 2007 10:52:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvzA-0002sO-VK for behave@ietf.org; Thu, 29 Mar 2007 10:52:20 -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 1HWvz9-0000iA-HI for behave@ietf.org; Thu, 29 Mar 2007 10:52:20 -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 l2TEps1G026041 for ; Thu, 29 Mar 2007 17:52:17 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 17:52:15 +0300 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 17:52:15 +0300 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] message-integrity and the length field Date: Thu, 29 Mar 2007 17:52:15 +0300 Message-ID: <719D5CCC2F6E3644B0A9F5C9B1D0008802BF9C08@esebe104.NOE.Nokia.com> In-Reply-To: <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] message-integrity and the length field Thread-Index: Acdxhf5HDORoeKFUScm1t5Fw31nspwAiBNAg References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com><460AD829.9060308@cisco.com> <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> From: To: X-OriginalArrivalTime: 29 Mar 2007 14:52:15.0673 (UTC) FILETIME=[D75FAA90:01C77211] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070329175217-6467EBB0-7DBF1D99/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, On 29 March 2007, Philip Matthews wrote: >What I think is the correct answer: >Set the length field in the STUN header to 60, compute the=20 >check, then append the M-I attribute (leaving the value of the=20 >length field at 60) and send the message. yes, I've talked with a number of implementors about this (who all have asked the same question btw ;)) and the above option is=20 the one that seems like the right interpretation (considering what the=20 code looks like on the receiving side), it's how most (?) current=20 implementations do it, and was ack'ed at least once on this list (in=20 January this year, subject "STUN FINGERPRINT"). --=20 first.surname@nokia.com (Kai Vehmanen) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 29 14:03: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 1HWyyJ-0001pl-62; Thu, 29 Mar 2007 14:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWyyH-0001pV-AY for behave@ietf.org; Thu, 29 Mar 2007 14:03:37 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWyxx-0006nM-BV for behave@ietf.org; Thu, 29 Mar 2007 14:03:37 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 73DD15193C for ; Thu, 29 Mar 2007 14:03:14 -0400 (EDT) Message-ID: <460BFEE3.9060706@pjsip.org> Date: Thu, 29 Mar 2007 19:01:07 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) 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: 7655788c23eb79e336f5f8ba8bce7906 Subject: [BEHAVE] TURN indication numbers X-BeenThere: behave@ietf.org X-Mailman-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 noticed that in turn-03 the indication numbers (btw what should we call this, STUN opcode?) have been changed to: 0x001 : Send 0x002 : Data 0x003 : Connect Status Although the indication numbers themselves will be unique, the opcodes conflict with STUN Binding, Shared-Secret, and TURN Allocate requests. I used to have a function which will print the opcode names, but of course the opcode conflict would break this, since now we have to look at the message class (request or indication) before deciding the name. Considering that we should have plenty of opcode numbers left (12-bits, if my head is right), should we just avoid this conflict? cheers, -benny _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 29 14:15: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 1HWz9f-0002Em-94; Thu, 29 Mar 2007 14:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWz9d-0002Da-Rc for behave@ietf.org; Thu, 29 Mar 2007 14:15:21 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWz95-00021f-CO for behave@ietf.org; Thu, 29 Mar 2007 14:14:49 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id BC15A5197B for ; Thu, 29 Mar 2007 14:14:46 -0400 (EDT) Message-ID: <460C0193.7070903@pjsip.org> Date: Thu, 29 Mar 2007 19:12:35 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: behave@ietf.org Subject: Re: [BEHAVE] message-integrity and the length field References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com><460AD829.9060308@cisco.com> <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> <719D5CCC2F6E3644B0A9F5C9B1D0008802BF9C08@esebe104.NOE.Nokia.com> In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D0008802BF9C08@esebe104.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: behave@ietf.org X-Mailman-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 Kai.Vehmanen@nokia.com wrote: > On 29 March 2007, Philip Matthews wrote: >> What I think is the correct answer: >> Set the length field in the STUN header to 60, compute the >> check, then append the M-I attribute (leaving the value of the >> length field at 60) and send the message. > > yes, I've talked with a number of implementors about this (who all have > asked the same question btw ;)) and the above option is > the one that seems like the right interpretation (considering what the > code looks like on the receiving side), it's how most (?) current > implementations do it, and was ack'ed at least once on this list (in > January this year, subject "STUN FINGERPRINT"). Agreed (except that the message length should be 64, since M-I is 24 bytes long ;-) ). -benny _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Mar 29 20: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 1HX5Ra-000693-MY; Thu, 29 Mar 2007 20:58:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX5RZ-00068n-I1 for behave@ietf.org; Thu, 29 Mar 2007 20:58:17 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX5RV-0004Yt-GB for behave@ietf.org; Thu, 29 Mar 2007 20:58:17 -0400 Received: by py-out-1112.google.com with SMTP id f47so150000pye for ; Thu, 29 Mar 2007 17:58:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kixKokskl2ih+yDrd/bnx6UyNDba4vKap4CYO/faQgsCzEiHOQOIgManXX9iIuoXUg49QEvGO8+SjiRjPYG4wfVoa0ChXzctrp4BgQXqKj741Poekof7vV+AnAhQCrJLzCH0ue3d5a4mMce9j2Kk8vh8a4YA8fkpcMAUmbHOFas= 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=BXMowW06l0YhhTn0/Y/Z5P4R1BCB8CgbE4yTp4/lrirgy07SEOGNKKNkvwUnzf7+jC+eFVM3qwFmrnf+pu3Vt8Dg2OqQa+CKCdtLGhoi0TY89lkeIZ7+N2eIE2CO+KH6/U+UcCG+av/TEDcd3KTy2Cgv/sUhBjkkh1QoSwkxSww= Received: by 10.35.43.10 with SMTP id v10mr2129056pyj.1175216293172; Thu, 29 Mar 2007 17:58:13 -0700 (PDT) Received: by 10.35.102.7 with HTTP; Thu, 29 Mar 2007 17:58:13 -0700 (PDT) Message-ID: <20d2bdfb0703291758w3241c16blf266994ae59cf4b5@mail.gmail.com> Date: Thu, 29 Mar 2007 20:58:13 -0400 From: "Bruce Lowekamp" To: "Christian Huitema" Subject: Re: [BEHAVE] message-integrity and the length field In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064040E24FA@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com> <460AD829.9060308@cisco.com> <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> <70C6EFCDFC8AAD418EF7063CD132D064040E24FA@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-Google-Sender-Auth: 8e8fad86114ceba7 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 The TCP checksum is a special case because if you calculate it with the field set to zero, then add it to the message and send it, the calculation on the receiving side must produce zero. CRC is similar (it's a remainder). That doesn't help with filling in a length field. I think it's only a question of whether it should include the checksum or not (my vote is it does). Bruce On 3/28/07, Christian Huitema wrote: > The standard practice, in many other protocols, is to encode the > complete message with a dummy attribute value (in this case 20 null > bytes), compute the checksum, replace the dummy value by the check > result, and send the message. The advantage of that method is to not > make any assumption about the position of the checksum attribute in the > message. > > For example, RFC 793 includes this text for the computation of the TCP > checksum: > > Checksum: 16 bits > > The checksum field is the 16 bit one's complement of the one's > complement sum of all 16 bit words in the header and text. If a > segment contains an odd number of header and text octets to be > checksummed, the last octet is padded on the right with zeros to > form a 16 bit word for checksum purposes. The pad is not > transmitted as part of the segment. While computing the checksum, > the checksum field itself is replaced with zeros. > > -- 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 Fri Mar 30 09:04:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGlR-0004T4-E4; Fri, 30 Mar 2007 09:03:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGlP-0004Sq-VI for behave@ietf.org; Fri, 30 Mar 2007 09:03:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXGlO-0008B3-Lm for behave@ietf.org; Fri, 30 Mar 2007 09:03:31 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2007 09:03:31 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2UD3U98013395; Fri, 30 Mar 2007 09:03:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2UD3UGd004723; Fri, 30 Mar 2007 13:03:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:03:22 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:03:22 -0400 Message-ID: <460D0A99.7010403@cisco.com> Date: Fri, 30 Mar 2007 09:03:21 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [BEHAVE] TURN indication numbers References: <460BFEE3.9060706@pjsip.org> In-Reply-To: <460BFEE3.9060706@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 13:03:22.0113 (UTC) FILETIME=[CB7B4710:01C772CB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1374; t=1175259810; x=1176123810; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20indication=20numbers |Sender:=20 |To:=20Benny=20Prijono=20; bh=RRjWON7EDOfDFfKjI842H90I5KBwZuOOPec3dQSOY/w=; b=MU8CT0xVqsudVjBZBzPnmqCFoQu7CWg1iPbM0DKE2TDHCSq7o35CvQ9newxMcwd8jlgBPKQ0 15NFvz++ZqgTkYzswwzqdGGzlwBVE0i452dvHKrsgnKUixC3kPpg3YSN; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 is a known conflict, Rohan discussed it during IETF. It will be fixed in the next turn revision. -Jonathan R. Benny Prijono wrote: > > I noticed that in turn-03 the indication numbers (btw what should we > call this, STUN opcode?) have been changed to: > > 0x001 : Send > 0x002 : Data > 0x003 : Connect Status > > Although the indication numbers themselves will be unique, the opcodes > conflict with STUN Binding, Shared-Secret, and TURN Allocate requests. > > I used to have a function which will print the opcode names, but of > course the opcode conflict would break this, since now we have to look > at the message class (request or indication) before deciding the name. > > Considering that we should have plenty of opcode numbers left (12-bits, > if my head is right), should we just avoid this conflict? > > cheers, > -benny > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Mar 30 09:05: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 1HXGmt-00050D-1z; Fri, 30 Mar 2007 09:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGmr-000503-FS for behave@ietf.org; Fri, 30 Mar 2007 09:05:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXGmp-000084-2I for behave@ietf.org; Fri, 30 Mar 2007 09:05:01 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2007 09:04:59 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2UD4wGJ014037; Fri, 30 Mar 2007 09:04:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2UD4slO002786; Fri, 30 Mar 2007 13:04:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:04:57 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:04:57 -0400 Message-ID: <460D0AF9.1060107@cisco.com> Date: Fri, 30 Mar 2007 09:04:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [BEHAVE] message-integrity and the length field References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com><460AD829.9060308@cisco.com> <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> <719D5CCC2F6E3644B0A9F5C9B1D0008802BF9C08@esebe104.NOE.Nokia.com> <460C0193.7070903@pjsip.org> In-Reply-To: <460C0193.7070903@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 13:04:57.0535 (UTC) FILETIME=[045B84F0:01C772CC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1494; t=1175259898; x=1176123898; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20message-integrity=20and=20the=20length=20f ield |Sender:=20 |To:=20Benny=20Prijono=20; bh=yjzCt8KplL/6MnPhNLkB3LdtvsxI7g+hQfmpAr1D6/U=; b=Ryp0Ycx++B7hyHPuAB7ExYTE9h0rAauWSiSNGplw9dqsqcw5rKBNGCcrmwNLo1XdmRlZ0PKk iWG7GWROpJBic2VoxGEPE1XFNauPHEO724pueYBxhDijf4apVNufIWUL; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I concur that this is the correct algorithm. Sounds like we are all agreed. I will clarify this in the next stun revision. -Jonathan R. Benny Prijono wrote: > Kai.Vehmanen@nokia.com wrote: > >> On 29 March 2007, Philip Matthews wrote: >> >>> What I think is the correct answer: >>> Set the length field in the STUN header to 60, compute the check, >>> then append the M-I attribute (leaving the value of the length field >>> at 60) and send the message. >> >> >> yes, I've talked with a number of implementors about this (who all have >> asked the same question btw ;)) and the above option is the one that >> seems like the right interpretation (considering what the code looks >> like on the receiving side), it's how most (?) current implementations >> do it, and was ack'ed at least once on this list (in January this >> year, subject "STUN FINGERPRINT"). > > > Agreed (except that the message length should be 64, since M-I is 24 > bytes long ;-) ). > > > -benny > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Mar 30 10:41: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 1HXIHq-0001IO-EE; Fri, 30 Mar 2007 10:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXIHp-0001IG-NT for behave@ietf.org; Fri, 30 Mar 2007 10:41:05 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXIHo-0006dL-Fn for behave@ietf.org; Fri, 30 Mar 2007 10:41:05 -0400 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l2UEea4K029337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Mar 2007 10:40:51 -0400 (EDT) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l2UEeaXl044032; Fri, 30 Mar 2007 10:40:36 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l2UEeaA4044029; Fri, 30 Mar 2007 10:40:36 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17933.8548.190568.850021@cnr.cs.columbia.edu> Date: Fri, 30 Mar 2007 10:40:36 -0400 To: Jonathan Rosenberg Subject: Re: [BEHAVE] message-integrity and the length field In-Reply-To: <460D0AF9.1060107@cisco.com> References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com> <460AD829.9060308@cisco.com> <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> <719D5CCC2F6E3644B0A9F5C9B1D0008802BF9C08@esebe104.NOE.Nokia.com> <460C0193.7070903@pjsip.org> <460D0AF9.1060107@cisco.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Would it be correct to extend this as follows? If a message has both the MESSAGE-INTEGRITY and FINGERPRINT attributes, the value of the length field for the input to MESSAGE-INTEGRITY includes the length of both attributes, i.e. 32 bytes more than the length of the STUN message before MESSAGE-INTEGRITY is appended. (Thus, you have to decide whether to include FINGERPRINT before computing MESSAGE-INTEGRITY.) Similarly, the length field over which FINGERPRINT is computed includes its own contents, i.e. 8 bytes more than the message length before FINGERPRINT is appended. On Friday, March 30 2007, "Jonathan Rosenberg" wrote to "Benny Prijono, behave@ietf.org" saying: > I concur that this is the correct algorithm. Sounds like we are all > agreed. I will clarify this in the next stun revision. > > -Jonathan R. > > Benny Prijono wrote: > > > Kai.Vehmanen@nokia.com wrote: > > > >> On 29 March 2007, Philip Matthews wrote: > >> > >>> What I think is the correct answer: > >>> Set the length field in the STUN header to 60, compute the check, > >>> then append the M-I attribute (leaving the value of the length field > >>> at 60) and send the message. > >> > >> > >> yes, I've talked with a number of implementors about this (who all have > >> asked the same question btw ;)) and the above option is the one that > >> seems like the right interpretation (considering what the code looks > >> like on the receiving side), it's how most (?) current implementations > >> do it, and was ack'ed at least once on this list (in January this > >> year, subject "STUN FINGERPRINT"). > > > > > > Agreed (except that the message length should be 64, since M-I is 24 > > bytes long ;-) ). -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Mar 30 13:01: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 1HXKSo-00026e-71; Fri, 30 Mar 2007 13:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKSn-00026Z-P5 for behave@ietf.org; Fri, 30 Mar 2007 13:00:33 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKSi-0006zi-CH for behave@ietf.org; Fri, 30 Mar 2007 13:00:33 -0400 Received: from [192.168.0.65] (unknown [81.178.58.134]) by smtp.mxes.net (Postfix) with ESMTP id 8BC1751939; Fri, 30 Mar 2007 13:00:25 -0400 (EDT) Message-ID: <460D4226.7070808@pjsip.org> Date: Fri, 30 Mar 2007 18:00:22 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Lennox Subject: Re: [BEHAVE] message-integrity and the length field References: <4605544E.4000300@gmail.com> <46087E90.9080606@cisco.com> <460AD829.9060308@cisco.com> <5FEFCE5D-A060-4340-8CDC-99161939A8E8@magma.ca> <719D5CCC2F6E3644B0A9F5C9B1D0008802BF9C08@esebe104.NOE.Nokia.com> <460C0193.7070903@pjsip.org> <460D0AF9.1060107@cisco.com> <17933.8548.190568.850021@cnr.cs.columbia.edu> In-Reply-To: <17933.8548.190568.850021@cnr.cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Jonathan Lennox wrote: > Would it be correct to extend this as follows? > > If a message has both the MESSAGE-INTEGRITY and FINGERPRINT attributes, the > value of the length field for the input to MESSAGE-INTEGRITY includes the > length of both attributes, i.e. 32 bytes more than the length of the STUN > message before MESSAGE-INTEGRITY is appended. To be precise, the last sentence should be: .. before M-I *and* FINGERPRINT is appended. Other than that, I agree. > (Thus, you have to decide whether to include FINGERPRINT before computing > MESSAGE-INTEGRITY.) Yes. > Similarly, the length field over which FINGERPRINT is computed includes its > own contents, i.e. 8 bytes more than the message length before FINGERPRINT > is appended. I also agree with this too. -benny _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave