From behave-bounces@ietf.org Tue Jul 03 14:16: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 1I5mvE-0000cT-JP; Tue, 03 Jul 2007 14:16:20 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I5mui-00079R-Im for behave-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 14:15:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5muh-000785-I8; Tue, 03 Jul 2007 14:15:47 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5muh-0007Fz-Aa; Tue, 03 Jul 2007 14:15:47 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 2CE2A2AC8B; Tue, 3 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5mtx-0002Gh-Su; Tue, 03 Jul 2007 14:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 03 Jul 2007 14:15:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-nat-icmp-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --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-04.txt Pages : 24 Date : 2007-7-3 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-04.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-04.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-04.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-7-3132912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-nat-icmp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-nat-icmp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3132912.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 Tue Jul 03 15:15:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5nqE-0001rk-Vl; Tue, 03 Jul 2007 15:15:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I5nqD-0001oK-Cb for behave-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 15:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5nqD-0001m6-1F; Tue, 03 Jul 2007 15:15:13 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5nq1-0001yr-JH; Tue, 03 Jul 2007 15:15:13 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7C1F326EAA; Tue, 3 Jul 2007 19:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5nq1-0003wD-DR; Tue, 03 Jul 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 03 Jul 2007 15:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-p2p-state-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --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 : State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-p2p-state-03.txt Pages : 31 Date : 2007-7-3 This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-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-p2p-state-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-p2p-state-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-7-3140948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-p2p-state-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-p2p-state-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3140948.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 Jul 04 05:01: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 1I60kH-000202-6C; Wed, 04 Jul 2007 05:01:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I60kF-0001qp-2k for behave-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 05:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I60kE-0001pE-LQ for behave@ietf.org; Wed, 04 Jul 2007 05:01:54 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I60k9-0001qz-IR for behave@ietf.org; Wed, 04 Jul 2007 05:01:54 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D05AE206E6; Wed, 4 Jul 2007 11:01:44 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-f2-468b61f8fd7e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B742720B23; Wed, 4 Jul 2007 11:01:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 11:01:44 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 11:01:43 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B35DF2328; Wed, 4 Jul 2007 12:01:43 +0300 (EEST) Message-ID: <468B61F7.5080807@ericsson.com> Date: Wed, 04 Jul 2007 12:01:43 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Philip Matthews Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705300907.06853.remi.denis-courmont@nokia.com> <465D1541.6070309@ericsson.com> <200705300919.59054.remi.denis-courmont@nokia.com> <465D1875.3070004@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 04 Jul 2007 09:01:43.0823 (UTC) FILETIME=[F17BC9F0:01C7BE19] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Behave WG , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, yes, it seems that a simple solution would be best. I suggest we do as=20 follows. We do not allow multiple addresses per allocation. Instead, if=20 a client wants to allocate an IPv4 and an IPv6 address at a relay, it=20 performs two different allocations. This way, we do not add any extra=20 complexity to the protocol. Regarding address types, I suggest that we keep things as they are. That=20 is, we define the IPv4 and IPv6 address families, which are the ones=20 that people will definitively use. Cheers, Gonzalo Philip Matthews wrote: > My concern about the SourceAddress and DestinationAddress attributes is= =20 > partly overhead and partly additional complexity in TURN. >=20 > The first could be addressed by enhancing the SetActiveDestination=20 > indication to specify the default sending/receiving address so that=20 > these attributes can be eliminated once the ICE connectivity checks are= =20 > finished. >=20 > The second is just because I see STUN and TURN as getting more and more= =20 > complex to handle marginal cases. > Personally, I don't see a reasonable use-case for a TURN relay with mor= e=20 > than one IPv4 address and one IPv6 address. Unless, some can present=20 > one, I suggest we design for that case and not insert things that are=20 > only really useful in future cases that currently seem unlikely. > As suggested below, it might be possible to infer the address of the=20 > TURN-relay-to-destination portion of the path from the address or heade= r=20 > used on the TURN relay-to-client portion of the path. I am not=20 > convinced this is really foolproof, but if it is, then I think this is=20 > might be a simpler solution than defining the new attributes. >=20 > - Philip >=20 >=20 > On 30-May-07, at 02:23 , Gonzalo Camarillo wrote: >=20 >> Hi, >> >> we agreed on defining the address family as Global IPv6 Unicast=20 >> Address. If, in the future, we decide to define new families (as you=20 >> pointed out), we will need the source-in-send and destination-in-data.= =20 >> Therefore, I suggest we are explicit from the beginning and add them=20 >> from day one. >> >> This was my understanding of our discussions, actually. >> >> Cheers, >> >> Gonzalo >> >> R=E9mi Denis-Courmont wrote: >>> On Wednesday 30 May 2007 09:10:09 ext Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>>> I do not have any very strong opinion. One option would be to=20 >>>>> enforce a >>>>> single >>>>> server address per family and per allocation; >>>> I believe we have rough consensus on using a single address per fami= ly, >>>> and on having the possibility of having multiple addresses per=20 >>>> allocation. >>> Fine, then source-in-Send and destination-in-Data are not really need= ed. >> >> >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 04 22:30:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6H6i-0005y6-G2; Wed, 04 Jul 2007 22:30:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6H6h-0005r8-6R for behave-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 22:30:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6H6g-0005pp-Qa for behave@ietf.org; Wed, 04 Jul 2007 22:30:10 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6H6c-0004xU-Hr for behave@ietf.org; Wed, 04 Jul 2007 22:30:10 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l652U61p005467 for ; Wed, 4 Jul 2007 22:30:06 -0400 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: Wed, 4 Jul 2007 22:30:06 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718801D@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Redirect for STUN Relay Thread-Index: Ace+rF+LJ6T70jLrQRqB9QzOhxLzHQ== From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [BEHAVE] Redirect for STUN Relay X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 was wondering whether it would make sense to have redirect type of functionality for STUN Relay, e.g. referring another server in a negative answer to an initial allocate request. The use case I am thinking of is load balancing. Discovery of STUN servers relies on DNS but a predefined weight allocation based on capacity may not provide always satisfactory results. The load on a server would be a parameter of capacity, bandwidth for a session and the duration of the sessions it is relaying. One could argue that on average sessions with different durations would be more or less evenly distributed among different STUN relay servers but I think it wouldn't be wrong to say that this parameter is more volatile than others.=20 During times of heavy resource allocation in servers, search based on weights associated with servers may require multiple request/responses till an actual allocation is performed. With the ability to refer another server, information STUN servers in a farm have about other server's resource usage or a front end may be utilized. This may not be a good fit for certain architectures/configurations but for such cases one may simply choose not to refer another server. Thanks, Tolga _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 05 02:11: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 1I6KYv-00044M-VV; Thu, 05 Jul 2007 02:11:33 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6KYv-00044E-54 for behave-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 02:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6KYu-00042S-Ob for behave@ietf.org; Thu, 05 Jul 2007 02:11:32 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6KYi-0007uu-Km for behave@ietf.org; Thu, 05 Jul 2007 02:11:32 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l656B76I029652; Thu, 5 Jul 2007 09:11:18 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 09:10:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 09:10:57 +0300 Received: from hed050124.research.nokia.com ([172.21.50.124]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 09:10:57 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, "ext Asveren, Tolga" Subject: Re: [BEHAVE] Redirect for STUN Relay Date: Thu, 5 Jul 2007 09:09:05 +0300 User-Agent: KMail/1.9.6 References: <033458F56EC2A64E8D2D7B759FA3E7E718801D@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718801D@sonusmail04.sonusnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707050909.05231.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 05 Jul 2007 06:10:57.0305 (UTC) FILETIME=[407EF890:01C7BECB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 05 July 2007 05:30:06 ext Asveren, Tolga wrote: > I was wondering whether it would make sense to have redirect type of > functionality for STUN Relay, e.g. referring another server in a > negative answer to an initial allocate request. This is *already* in the specification, and has been there for several year= s. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 05 08:20: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 1I6QKH-00086j-Ru; Thu, 05 Jul 2007 08:20:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6QKG-00086Z-C8 for behave-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 08:20:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6QKG-00086R-0R for behave@ietf.org; Thu, 05 Jul 2007 08:20:48 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6QKB-0008SD-P5 for behave@ietf.org; Thu, 05 Jul 2007 08:20:47 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l65CKhGT021367; Thu, 5 Jul 2007 08:20:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Redirect for STUN Relay Date: Thu, 5 Jul 2007 08:20:43 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718801F@sonusmail04.sonusnet.com> In-Reply-To: <200707050909.05231.remi.denis-courmont@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Redirect for STUN Relay Thread-Index: Ace+y1bhraRRN0F1QYO9oP+XRbq7vgAM4SVg References: <033458F56EC2A64E8D2D7B759FA3E7E718801D@sonusmail04.sonusnet.com> <200707050909.05231.remi.denis-courmont@nokia.com> From: "Asveren, Tolga" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , X-Spam-Score: 0.0 (/) 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 O.K., sorry my bad. Thanks, Tolga > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] > Sent: Thursday, July 05, 2007 2:09 AM > To: behave@ietf.org; Asveren, Tolga > Subject: Re: [BEHAVE] Redirect for STUN Relay >=20 > On Thursday 05 July 2007 05:30:06 ext Asveren, Tolga wrote: > > I was wondering whether it would make sense to have redirect type of > > functionality for STUN Relay, e.g. referring another server in a > > negative answer to an initial allocate request. >=20 > This is *already* in the specification, and has been there for several > years. >=20 > -- > R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 05 10:58: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 1I6Smp-0007KP-Dp; Thu, 05 Jul 2007 10:58:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6Smn-0007Iw-1o for behave-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 10:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Smm-0007H7-FI for behave@ietf.org; Thu, 05 Jul 2007 10:58:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Smf-0003nR-Dn for behave@ietf.org; Thu, 05 Jul 2007 10:58:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Jul 2007 07:58:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJqjjEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,503,1175497200"; d="scan'208"; a="177072055:sNHT107861778" 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 l65EwGBk011028; Thu, 5 Jul 2007 07:58:16 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65Ew8XT019525; Thu, 5 Jul 2007 14:58:15 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); Thu, 5 Jul 2007 10:58:10 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 10:58:10 -0400 Message-ID: <468D0705.70609@cisco.com> Date: Thu, 05 Jul 2007 10:58:13 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [BEHAVE] Redirect for STUN Relay References: <033458F56EC2A64E8D2D7B759FA3E7E718801D@sonusmail04.sonusnet.com> <200707050909.05231.remi.denis-courmont@nokia.com> <033458F56EC2A64E8D2D7B759FA3E7E718801F@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718801F@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Jul 2007 14:58:10.0547 (UTC) FILETIME=[E760A430:01C7BF14] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1877; t=1183647496; x=1184511496; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Redirect=20for=20STUN=20Relay |Sender:=20; bh=nq8fdNJbsc6ElgajOQnifzWYxx3tjRnURIRpG2b3iLM=; b=ZZCnPOlchbcR1rQ4Swu8+757zI74L5eKS7lMUp8p3hH6De2w6tcbkt2q61e7UX/1X94RUwtX XF5mXtqNcKPRy1WVUO8OTeD9K5DzBDx/FSMRIavIp9GdV+TOI7FxkC1W; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Actually, this is something which we were planning on removing in the revision coming up. There were comments during last call about the utility of the mechanism, security concerns, and so on. Also there didn't seem to be anyone who wanted it. There are much better ways of doing load balacning, for example utilizing a front-end load balancing element that actually tracks capacity of back end relays, and then directs the request to the least loaded server. THis is standard practice for load balancing for many other protocols. That kind of mechanism is also faster and more stable. Redirect mechanisms can result in ping-ponging especially near capacity limits. -Jonathan R. Asveren, Tolga wrote: > O.K., sorry my bad. > > Thanks, > Tolga > >> -----Original Message----- >> From: Rémi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] >> Sent: Thursday, July 05, 2007 2:09 AM >> To: behave@ietf.org; Asveren, Tolga >> Subject: Re: [BEHAVE] Redirect for STUN Relay >> >> On Thursday 05 July 2007 05:30:06 ext Asveren, Tolga wrote: >>> I was wondering whether it would make sense to have redirect type of >>> functionality for STUN Relay, e.g. referring another server in a >>> negative answer to an initial allocate request. >> This is *already* in the specification, and has been there for several >> years. >> >> -- >> Rémi Denis-Courmont > > > _______________________________________________ > 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 Thu Jul 05 11:15:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6T3h-0004PU-EB; Thu, 05 Jul 2007 11:15:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6T3g-0004M3-7r for behave-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 11:15:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6T3f-0004LD-Tg for behave@ietf.org; Thu, 05 Jul 2007 11:15:51 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6T3P-0006bg-U2 for behave@ietf.org; Thu, 05 Jul 2007 11:15:51 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 266E53A02022; Thu, 5 Jul 2007 08:15:35 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 87FE73A02020; Thu, 5 Jul 2007 08:15:32 -0700 (PDT) Message-ID: <468D0B13.6080007@acm.org> Date: Thu, 05 Jul 2007 08:15:31 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] Redirect for STUN Relay References: <033458F56EC2A64E8D2D7B759FA3E7E718801D@sonusmail04.sonusnet.com> <200707050909.05231.remi.denis-courmont@nokia.com> <033458F56EC2A64E8D2D7B759FA3E7E718801F@sonusmail04.sonusnet.com> <468D0705.70609@cisco.com> In-Reply-To: <468D0705.70609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Rosenberg wrote: > Actually, this is something which we were planning on removing in the > revision coming up. There were comments during last call about the > utility of the mechanism, security concerns, and so on. Also there > didn't seem to be anyone who wanted it.=20 OK, I missed the discussion, because I use the 300 response, and plan to continue to use it. I also proposed a long time ago to replace the IP address in the 300 response by a name so the SRV RR processing can be reapplied, but without success. There are much better ways of > doing load balacning, for example utilizing a front-end load balancing > element that actually tracks capacity of back end relays, and then > directs the request to the least loaded server. THis is standard > practice for load balancing for many other protocols.=20 This also force to buy expensive stuff that is not needed with the end to end mechanisms. It's OK if people want to use B2BUA, SBC, load balancers, NAT - their money, not mine - but Internet standards should not force people to do this. So I am strongly opposed to remove the 300 response from STUN. > That kind of > mechanism is also faster and more stable. Redirect mechanisms can resul= t > in ping-ponging especially near capacity limits. >=20 > -Jonathan R. >=20 > Asveren, Tolga wrote: >> O.K., sorry my bad. >> >> Thanks, >> Tolga >> >>> -----Original Message----- >>> From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] >>> Sent: Thursday, July 05, 2007 2:09 AM >>> To: behave@ietf.org; Asveren, Tolga >>> Subject: Re: [BEHAVE] Redirect for STUN Relay >>> >>> On Thursday 05 July 2007 05:30:06 ext Asveren, Tolga wrote: >>>> I was wondering whether it would make sense to have redirect type of >>>> functionality for STUN Relay, e.g. referring another server in a >>>> negative answer to an initial allocate request. >>> This is *already* in the specification, and has been there for severa= l >>> years. >>> >>> --=20 >>> R=E9mi Denis-Courmont --=20 Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 05 21:00:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cB8-0007oY-Fs; Thu, 05 Jul 2007 21:00:10 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6cB7-0007oQ-6E for behave-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 21:00:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cB6-0007oI-Mk for behave@ietf.org; Thu, 05 Jul 2007 21:00:08 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6cB6-0004EO-Eb for behave@ietf.org; Thu, 05 Jul 2007 21:00:08 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l660xi4g030693 for ; Thu, 5 Jul 2007 20:59:44 -0400 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, 5 Jul 2007 20:59:44 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188028@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STUN relay with push mode QoS reservation Thread-Index: Ace/aPEiMhG88JRuTjmE/lE5TFbgOQ== From: "Asveren, Tolga" To: X-Spam-Score: 2.0 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [BEHAVE] STUN relay with push mode QoS reservation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 was trying to figure out how to merge STUN relay with push mode QoS reservation. In this model, QoS reservation is triggered from network rather than the UA. Consider the following scenario: +----+ +-----+ +------+ | | | | | | | UA1+------+ NAT +---------------------+ AF -------+ | |xxxxxx| | | | | +----+ +-----+ +---"--+ | x(IP1) " | x +--------+ " +--+-+ x | STUN | " | | x | Relay |xxxxxxxxxxxxxxxxx| UA2| x | |(IP3) " (IP4)| | x +--------+ " +----+ x x(IP2) " +-----+ x +---"--+ | |xxxxxxxx | | | PEF | | PDF | | """"""""""""""""""""""" | +-----+ +------+ --- Call Signaling (SIP/SDP) """ QoS Signaling (Diameter QoS application) xxx Media AF Application Function (Proxy, Application Server, P-CSCF etc...) PDF Policy Decision Function PEF Policy Enforcement Function (Router, CMTS etc..) UA1 uses IP3 in the SDP, and UA2 will use IP4. These addresses are visible to AF (because it is on the SIP signaling path), and it will use that information while reserving QoS for that particular session. The problem is PEF needs to know IP1 and IP2 but will get IP3 and IP4. STUN relay knows the binding between IP1/IP2 and IP3/IP4. This makes me think whether it would make sense to have a STUN mechanism so that trusted external entities can query STUN relay about the bindings.=20 Thanks, Tolga _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 06 02: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 1I6hlT-0005iF-L3; Fri, 06 Jul 2007 02:58:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6hlR-0005d4-Tw for behave-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 02:58:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hlO-0005Xa-JR for behave@ietf.org; Fri, 06 Jul 2007 02:57:58 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6hlO-0001ue-3H for behave@ietf.org; Fri, 06 Jul 2007 02:57:58 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7AA8620BF9; Fri, 6 Jul 2007 08:57:41 +0200 (CEST) X-AuditID: c1b4fb3c-b0e80bb0000007e1-a7-468de7e5837b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5CD7F20BEB; Fri, 6 Jul 2007 08:57:41 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 08:57:40 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 08:57:40 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 703E32466; Fri, 6 Jul 2007 09:57:40 +0300 (EEST) Message-ID: <468DE7E4.4090500@ericsson.com> Date: Fri, 06 Jul 2007 09:57:40 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Behave WG Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705300907.06853.remi.denis-courmont@nokia.com> <465D1541.6070309@ericsson.com> <200705300919.59054.remi.denis-courmont@nokia.com> <465D1875.3070004@ericsson.com> <468B61F7.5080807@ericsson.com> In-Reply-To: <468B61F7.5080807@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 06 Jul 2007 06:57:40.0585 (UTC) FILETIME=[F1CB4D90:01C7BF9A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Oscar Novo , Philip Matthews , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I have put together a new revision of this draft. Until it appears in the archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-ietf-behave-turn-ipv6-03.txt Besides addressing a few issues that were identified a while ago, I have added the following paragraph to this revision: For simplicity reasons, STUN relay servers are designed to allocate a single address per allocation request. Therefore, Allocate Requests cannot carry more than one REQUESTED-ADDRESS-TYPE attribute. Consequently, a client that wishes to allocate more than one address at a STUN relay server (e.g., an IPv4 and an IPv6 address) needs to perform several allocation requests (one allocation request per address). I believe it captures the result of our mailing list discussions. Even though this was the approach the draft took from the beginning, it has been good to have explicit discussions on the list about potential optimizations such as the allocation of multiple addresses per allocation, which we have agreed not to implement. Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi, >=20 > yes, it seems that a simple solution would be best. I suggest we do > as follows. We do not allow multiple addresses per allocation. > Instead, if a client wants to allocate an IPv4 and an IPv6 address at > a relay, it performs two different allocations. This way, we do not > add any extra complexity to the protocol. >=20 > Regarding address types, I suggest that we keep things as they are. > That is, we define the IPv4 and IPv6 address families, which are the > ones that people will definitively use. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 >=20 > Philip Matthews wrote: >> My concern about the SourceAddress and DestinationAddress >> attributes is partly overhead and partly additional complexity in >> TURN. >>=20 >> The first could be addressed by enhancing the SetActiveDestination >> indication to specify the default sending/receiving address so >> that these attributes can be eliminated once the ICE connectivity >> checks are finished. >>=20 >> The second is just because I see STUN and TURN as getting more and >> more complex to handle marginal cases. Personally, I don't see a >> reasonable use-case for a TURN relay with more than one IPv4 >> address and one IPv6 address. Unless, some can present one, I >> suggest we design for that case and not insert things that are only >> really useful in future cases that currently seem unlikely. As >> suggested below, it might be possible to infer the address of the=20 >> TURN-relay-to-destination portion of the path from the address or=20 >> header used on the TURN relay-to-client portion of the path. I am >> not convinced this is really foolproof, but if it is, then I think >> this is might be a simpler solution than defining the new >> attributes. >>=20 >> - Philip >>=20 >>=20 >> On 30-May-07, at 02:23 , Gonzalo Camarillo wrote: >>=20 >>> Hi, >>>=20 >>> we agreed on defining the address family as Global IPv6 Unicast=20 >>> Address. If, in the future, we decide to define new families (as >>> you pointed out), we will need the source-in-send and=20 >>> destination-in-data. Therefore, I suggest we are explicit from >>> the beginning and add them from day one. >>>=20 >>> This was my understanding of our discussions, actually. >>>=20 >>> Cheers, >>>=20 >>> Gonzalo >>>=20 >>> R=E9mi Denis-Courmont wrote: >>>> On Wednesday 30 May 2007 09:10:09 ext Gonzalo Camarillo wrote: >>>>> Hi, >>>>>=20 >>>>>> I do not have any very strong opinion. One option would be >>>>>> to enforce a single server address per family and per >>>>>> allocation; >>>>> I believe we have rough consensus on using a single address >>>>> per family, and on having the possibility of having multiple >>>>> addresses per allocation. >>>> Fine, then source-in-Send and destination-in-Data are not >>>> really needed. >>>=20 >>>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ Behave mailing list=20 > Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 06 14:15: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 1I6sL0-000615-0c; Fri, 06 Jul 2007 14:15:26 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6sKf-00048o-K1 for behave-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 14:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sKe-00042E-EV; Fri, 06 Jul 2007 14:15:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6sKe-0001ZI-5W; Fri, 06 Jul 2007 14:15:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0E09326E90; Fri, 6 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6sKb-0002tz-T6; Fri, 06 Jul 2007 14:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Jul 2007 14:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-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 : Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for IPv4/IPv6 Transition Author(s) : G. Camarillo, O. Novo Filename : draft-ietf-behave-turn-ipv6-03.txt Pages : 8 Date : 2007-7-6 This document defines the REQUESTED-ADDRESS-TYPE attribute for the Simple Traversal Underneath NAT (STUN) Relay Usage, which allows a client to explicitly request the address type the STUN relay server will allocate (e.g., an IPv4-only node may request the STUN relay server to allocate an IPv6 address). Additionally, this document also defines a new error response code with the value 440 (Address Family not Supported). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-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-ipv6-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-ipv6-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-7-6134537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-ipv6-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-ipv6-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-6134537.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 Jul 06 16:00: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 1I6tyb-00055H-Ow; Fri, 06 Jul 2007 16:00:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6tyZ-0004vO-DN for behave-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 16:00:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tyZ-0004tU-2r for behave@ietf.org; Fri, 06 Jul 2007 16:00:23 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6tyW-0000kc-IQ for behave@ietf.org; Fri, 06 Jul 2007 16:00:23 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 06 Jul 2007 12:59:52 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKY7jkarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,509,1175497200"; d="scan'208"; a="500793799:sNHT1139591228" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l66Jxp4t007846; Fri, 6 Jul 2007 12:59:51 -0700 Received: from dwingwxp (dhcp-171-70-228-43.cisco.com [171.70.228.43]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l66Jxpmo022544; Fri, 6 Jul 2007 19:59:51 GMT From: "Dan Wing" To: "'Asveren, Tolga'" Subject: RE: [BEHAVE] STUN relay with push mode QoS reservation Date: Fri, 6 Jul 2007 12:59:52 -0700 Message-ID: <113801c7c008$3745ef70$e171150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace/aPEiMhG88JRuTjmE/lE5TFbgOQAl6o6w In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188028@sonusmail04.sonusnet.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4400; t=1183751991; x=1184615991; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20STUN=20relay=20with=20push=20mode=20QoS=20 reservation |Sender:=20; bh=fle8xMM2NsYjhHsBYALfHmYrkPp22s8OS2k3CXGVNRU=; b=n7ypWnX1wNef6CIeljdQGUjmp+cakqcWF+2W7Ge09I37MflPTWt08yfcm6rzUj5NxFG+c1pi On6t/+z9LD/MNaA6juml7tgSbkBtxhH2xhH4ghuL8FmfVyag070RIrY6l5XNo8BTyswmvWxN+Q eY46YIoxXyTy10am4KDfXB8Uc=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 2.0 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi. The rel-addr and rel-port attributes are intended to solve that very problem, and is described in appendix B.3 of draft-ietf-mmusic-ice-16. Please let Jonathan know if that mechanism is insufficient, as I believe he is working to get -17 submitted. Here is the text of that appendix for your reference: B.3. Purpose of the and Attributes The candidate attribute contains two values that are not used at all by ICE itself - and . Why is it present? There are two motivations for its inclusion. The first is diagnostic. It is very useful to know the relationship between the different types of candidates. By including it, an agent can know which relayed candidate is associated with which reflexive candidate, which in turn is associated with a specific host candidate. When checks for one candidate succeed and not the others, this provides useful diagnostics on what is going on in the network. The second reason has to do with off-path Quality of Service (QoS) mechanisms. When ICE is used in environments such as PacketCable 2.0, proxies will, in addition to performing normal SIP operations, inspect the SDP in SIP messages, and extract the IP address and port for media traffic. They can then interact, through policy servers, with access routers in the network, to establish guaranteed QoS for the media flows. This QoS is provided by classifying the RTP traffic based on 5-tuple, and then providing it a guaranteed rate, or marking its Diffserv codepoints appropriately. When a residential NAT is present, and a relayed candidate gets selected for media, this relayed candidate will be a transport address on an actual STUN relay. That address says nothing about the actual transport address in the access router that would be used to classify packets for QoS treatment. Rather, the server reflexive candidate towards that relay is needed. By carrying the translation in the SDP, the proxy can use that transport address to request QoS from the access router. -d > I was trying to figure out how to merge STUN relay with push mode QoS > reservation. In this model, QoS reservation is triggered from network > rather than the UA. > > Consider the following scenario: > > +----+ +-----+ +------+ > | | | | | | > | UA1+------+ NAT +---------------------+ AF -------+ > | |xxxxxx| | | | | > +----+ +-----+ +---"--+ | > x(IP1) " | > x +--------+ " +--+-+ > x | STUN | " | | > x | Relay |xxxxxxxxxxxxxxxxx| UA2| > x | |(IP3) " (IP4)| | > x +--------+ " +----+ > x x(IP2) " > +-----+ x +---"--+ > | |xxxxxxxx | | > | PEF | | PDF | > | """"""""""""""""""""""" | > +-----+ +------+ > > > --- Call Signaling (SIP/SDP) > > """ QoS Signaling (Diameter QoS application) > > xxx Media > > AF Application Function (Proxy, Application Server, > P-CSCF etc...) > > PDF Policy Decision Function > > PEF Policy Enforcement Function (Router, CMTS etc..) > > UA1 uses IP3 in the SDP, and UA2 will use IP4. These addresses are > visible to AF (because it is on the SIP signaling path), and > it will use > that information while reserving QoS for that particular session. > > The problem is PEF needs to know IP1 and IP2 but will get IP3 and IP4. > STUN relay knows the binding between IP1/IP2 and IP3/IP4. > This makes me > think whether it would make sense to have a STUN mechanism so that > trusted external entities can query STUN relay about the bindings. > > Thanks, > Tolga > > > _______________________________________________ > 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 Jul 06 16:20: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 1I6uIF-0008Ev-Oi; Fri, 06 Jul 2007 16:20:43 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6uIC-00087T-8L for behave-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 16:20:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uIB-000874-Tz for behave@ietf.org; Fri, 06 Jul 2007 16:20:39 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6uI7-0003Pt-GP for behave@ietf.org; Fri, 06 Jul 2007 16:20:39 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 06 Jul 2007 13:20:35 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFZAjkarR7PDh2dsb2JhbACPNgEBCQ4s X-IronPort-AV: i="4.16,509,1175497200"; d="scan'208"; a="384103483:sNHT26665448" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l66KKYCL032534 for ; Fri, 6 Jul 2007 13:20:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l66KKSXn019646 for ; Fri, 6 Jul 2007 20:20:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 13:20:21 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 13:20:21 -0700 Message-ID: <468EA409.3020008@cisco.com> Date: Fri, 06 Jul 2007 16:20:25 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 20:20:21.0941 (UTC) FILETIME=[14330650:01C7C00B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1629; t=1183753234; x=1184617234; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE=20tutorial=20in=20Chicago=20[DO=20NOT=20REPLY] |Sender:=20; bh=/a2gGbj9z3uAeaOyVraQo7NcVcWVa35n/rdAvyWYEgQ=; b=T3r25vRSMQqshJxKdx6gUJKBLUa0SLFniaH8l5y6pSReq8prwKfIUfMd4z6lX4pKJ1oWdgP1 wqFp6PPvw5kRvzCC/EuBTmZZdSvpxrY+n0Tt6dN/DQcjsBrqnfO2dV8D; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [BEHAVE] ICE tutorial in Chicago [DO NOT REPLY] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- 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 Jul 06 16:54: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 1I6up5-0003Ac-Vz; Fri, 06 Jul 2007 16:54:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6up4-0003A8-O5 for behave-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 16:54:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6up4-00039q-1s for behave@ietf.org; Fri, 06 Jul 2007 16:54:38 -0400 Received: from web33315.mail.mud.yahoo.com ([68.142.206.130]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6uoz-0003RR-Ke for behave@ietf.org; Fri, 06 Jul 2007 16:54:38 -0400 Received: (qmail 89374 invoked by uid 60001); 6 Jul 2007 20:54:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=0dwC93m++GEif3s1JgVt74ih8HqCdBxml1gWmhpLOmW6J2f7TdJAuptUVY7d9W2IVajI/kM1sdEDNL7w4zIiVK+0gtWK+0dm3O/pAbueFMmPJ0sg9aN4OnlT8C1vsLXozOmyfgvxVX9RKVUrCvso9OF2Y+/zv902sj309K/OFt4=; X-YMail-OSG: quv5j1wVM1lN9.hUzenzPIKYDe3UEms5kqkonZORHj01iw8WrU53eL7mR3nsEIZKpLtC5dRupHxtTjCDLCuyJDhuyeVAuMTPMjjB0EEKNK.22ut3vZw- Received: from [209.172.74.45] by web33315.mail.mud.yahoo.com via HTTP; Fri, 06 Jul 2007 13:54:32 PDT Date: Fri, 6 Jul 2007 13:54:32 -0700 (PDT) From: Pyda Srisuresh Subject: Fwd: [BEHAVE] I-D ACTION:draft-ietf-behave-nat-icmp-04.txt To: behave@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-174748620-1183755272=:88821" Content-Transfer-Encoding: 8bit Message-ID: <162290.88821.qm@web33315.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --0-174748620-1183755272=:88821 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline Dear all, Rev 4 of the ICMP draft is now available. This rev folds in all comments received from the last IETF meeting, WG discussions and individual feedbacks. I believe, the document is ready for WGLC. Below are the major changes, AFAIK. Please review. Thanks. 1. Precede some of the requriements (1,4 and 5) with the clause of "local policies permitting". This is per WG feedback. 2. Keep the clause relating to ICMP extentions in REQ-3, but remove from REQ-4 and REQ-5. This was also feedback from the IETF meeting. Added non-normative text on IMCP extensions in the sectiond discussion REQ-4 and REQ-5 with a goal to raise awareness of the extensions, while not requiring enforcement. 3. Added a new term, "Post-1122 ICMP Messages", per feedback from Carlos. Thanks, Carlos. 4. Kept the use of ICMP type 3, code 13. This was WG consensus. 5. Miscellaneous changes to text throughout. Also added a few more references. Thats all for now. Thanks. regards, suresh --- Internet-Drafts@ietf.org wrote: > To: i-d-announce@ietf.org > From: Internet-Drafts@ietf.org > Date: Tue, 03 Jul 2007 14:15:01 -0400 > CC: behave@ietf.org > Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-nat-icmp-04.txt > > 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-04.txt > Pages : 24 > Date : 2007-7-3 > > 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-04.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-04.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-04.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 > --0-174748620-1183755272=:88821 Content-Type: text/plain; charset=us-ascii Content-Description: pat784671251 Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --0-174748620-1183755272=:88821 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 --0-174748620-1183755272=:88821-- From behave-bounces@ietf.org Fri Jul 06 17:06: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 1I6v0D-0004Sa-DT; Fri, 06 Jul 2007 17:06:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6v0C-0004SV-RL for behave-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 17:06:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6v0C-0004SN-Hn for behave@ietf.org; Fri, 06 Jul 2007 17:06:08 -0400 Received: from web33301.mail.mud.yahoo.com ([68.142.206.116]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6v08-0006az-2h for behave@ietf.org; Fri, 06 Jul 2007 17:06:08 -0400 Received: (qmail 45221 invoked by uid 60001); 6 Jul 2007 21:06:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=vGWgK9ASLMOmpw1fDd8AHKaE+uoNae6XYTGFIQrhrD9VxuzgIeGyBFwYFeb0Kruq64aVP5R+hgjhD3XivAAmK99MDtrZ5dSQh5kE99e9f8KeWp2k4ZNRAp771g8+gWGIl/TOb5zJF5aNuYFra8BJpntNqHEKZEEFVJr52n4F2Q8=; X-YMail-OSG: DCUtiRIVM1knq2bMTr91H9EIz9Qd1koQJg9CfSMAd1Ag57_xsIyeF3ErQmqh.r08LQ-- Received: from [209.172.74.45] by web33301.mail.mud.yahoo.com via HTTP; Fri, 06 Jul 2007 14:06:03 PDT Date: Fri, 6 Jul 2007 14:06:03 -0700 (PDT) From: Pyda Srisuresh Subject: Fwd: [BEHAVE] I-D ACTION:draft-ietf-behave-p2p-state-03.txt To: behave@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1954039105-1183755963=:40697" Content-Transfer-Encoding: 8bit Message-ID: <547104.40697.qm@web33301.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --0-1954039105-1183755963=:40697 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline Dear all, Rev3 of the p2p-state draft is now available. This folds in comments and feedback received from the last WGLC. In this rev of the draft, I minimize the use of the term p2p. However, I did not break up my paragraphs into bullets or split figures into topology and ladder figures. Please review. Thanks. regards, suresh --- Internet-Drafts@ietf.org wrote: > To: i-d-announce@ietf.org > From: Internet-Drafts@ietf.org > Date: Tue, 03 Jul 2007 15:15:01 -0400 > CC: behave@ietf.org > Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-p2p-state-03.txt > > 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 : State of Peer-to-Peer(P2P) Communication Across Network Address > Translators(NATs) > Author(s) : P. Srisuresh, et al. > Filename : draft-ietf-behave-p2p-state-03.txt > Pages : 31 > Date : 2007-7-3 > > This memo documents the various methods known to be in use by > applications to establish direct communication in the presence > of Network Address Translators (NATs) at the current time. This > memo covers NAT traversal approaches used by both TCP and UDP > based applications. This memo is not an endorsement of the methods > described, but merely an attempt to capture them in a document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-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-p2p-state-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-p2p-state-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 > --0-1954039105-1183755963=:40697 Content-Type: text/plain; charset=us-ascii Content-Description: pat330613636 Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --0-1954039105-1183755963=:40697 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 --0-1954039105-1183755963=:40697-- From behave-bounces@ietf.org Fri Jul 06 20:42:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yNs-0006Qu-9l; Fri, 06 Jul 2007 20:42:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I6yNr-0006QB-6l for behave-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 20:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yNq-0006Pr-T5 for behave@ietf.org; Fri, 06 Jul 2007 20:42:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yNm-0001uz-Hr for behave@ietf.org; Fri, 06 Jul 2007 20:42:46 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 06 Jul 2007 17:42:41 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADZ+jkarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,510,1175497200"; d="scan'208"; a="500855518:sNHT25176560" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l670gfiw015272 for ; Fri, 6 Jul 2007 17:42:41 -0700 Received: from dwingwxp (dhcp-128-107-163-99.cisco.com [128.107.163.99]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l670gfka011026 for ; Sat, 7 Jul 2007 00:42:41 GMT From: "Dan Wing" To: Date: Fri, 6 Jul 2007 17:42:41 -0700 Message-ID: <158401c7c02f$b9cbde10$e171150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: AcfAL7mlmPteljiZT86u7aYygan6Zw== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1125; t=1183768961; x=1184632961; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20draft=20BEHAVE=20agenda |Sender:=20; bh=TwWrdXsL2/PEwPx1bPQ3ax1S4JuDMUKLvKzmt1yknc0=; b=iDv7a6bC76Y6gFhQ544hx8e5wmv1h2wAMWON7RM6lzwRz03se0VS/+Aakjj6XRMBxSQy8oBy N5dbhT+4R9zCuf1AxST/x0DS3hkODB2AFIdkE7iaZloET/KFqlE9G2xv; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [BEHAVE] draft BEHAVE agenda X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 is now available at: http://www3.ietf.org/proceedings/07jul/agenda/behave.html If you would like a slot, please email me. -d ----- ** DRAFT AGENDA ** BEHAVE Agenda -- IETF 69, Chicago FRIDAY, July 27, 09:00-11:30 Chair: Dan Wing, dwing@cisco.com 09:00 Agenda, milestones, and document status (Chair, 10) WGLC: draft-ietf-behave-p2p-state-03 WGLC: draft-ietf-behave-nat-icmp-04 WGLC: draft-ietf-behave-multicast-08 (not yet published) 09:10 RFC3489bis (Rosenberg, 20) draft-ietf-behave-rfc3489bis-07 (not yet published) Status: ready for WGLC 09:30 NAT Behavior Discovery (Lowekamp/MacDonald, 15) draft-ietf-behave-nat-behavior-discovery-01 (not yet published) Status: 09:45 Multicast (Wing, 15) draft-ietf-behave-multicast-08 (not yet published) 10:00 end (agenda version: 0.1) ** DRAFT AGENDA ** _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jul 07 19:00:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JGf-0001L3-Bi; Sat, 07 Jul 2007 19:00:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7JGd-0001Kw-Eb for behave-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 19:00:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JGc-0001Kg-Sj for behave@ietf.org; Sat, 07 Jul 2007 19:00:43 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I7JGc-0005uZ-Dp for behave@ietf.org; Sat, 07 Jul 2007 19:00:42 -0400 Received: from lappy ([75.7.13.129]) by quinthar.com for ; Sat, 7 Jul 2007 15:59:45 -0700 From: "David Barrett" To: Date: Sat, 7 Jul 2007 15:59:44 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfA6oCDGKiptI1xT2CeabTDSauJWg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Message-Id: Subject: [BEHAVE] Relationship between TCP and UDP X-BeenThere: behave@ietf.org X-Mailman-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="===============0713736240==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0713736240== Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C6_01C7C0AF.D6C78C00" This is a multi-part message in MIME format. ------=_NextPart_000_07C6_01C7C0AF.D6C78C00 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I apologize if this is specified in one of the drafts, but I looked around a bit and couldn't find it: When a client opens both a UDP and TCP port on the same endpoint (ie, same IP:port), can the TCP port receive incoming connections via a NAT mapping established using UDP? So let's say I use STUN and UDP to open an external port on a NAT. And let's also say that I've bound a listening TCP socket to the same IP:port as the UDP socket: 1) Should I be able to receive incoming TCP connections on that external NAT host? 2) In practice, does anybody have real-world data showing how often this works? You could argue that a NAT SHOULD NOT allow incoming TCP connections via the mapping established via UDP due to a potential violation of the NAT's filtering properties. Or you could argue that it SHOULD in order to effectively use UDP as a way to setting up a TCP port forward. Both arguments have merit (though, being an application developer, I favor the latter). But separate from what should or should not be the case, I'm wondering to what degree NATs actually do in practice. Anybody know? Thanks! -david ------=_NextPart_000_07C6_01C7C0AF.D6C78C00 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I apologize if this is specified in one of the = drafts, but I looked around a bit and couldn’t find = it:

 

When a client opens both a UDP and TCP port on the = same endpoint (ie, same IP:port), can the TCP port receive incoming = connections via a NAT mapping established using UDP?

 

So let’s say I use STUN and UDP to open an = external port on a NAT.  And let’s also say that I’ve bound a = listening TCP socket to the same IP:port as the UDP = socket:

 

1)       = Should I be able to receive incoming TCP connections on that external NAT host?

2)       = In practice, does anybody have real-world data showing how often this = works?

 

You could argue that a NAT SHOULD NOT allow incoming = TCP connections via the mapping established via UDP due to a potential = violation of the NAT’s filtering properties.  Or you could argue that it = SHOULD in order to effectively use UDP as a way to setting up a TCP port = forward.  Both arguments have merit (though, being an application developer, I = favor the latter).

 

But separate from what should or should not be the = case, I’m wondering to what degree NATs actually do in practice.  Anybody = know?

 

Thanks!

 

-david

------=_NextPart_000_07C6_01C7C0AF.D6C78C00-- --===============0713736240== 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 --===============0713736240==-- From behave-bounces@ietf.org Sat Jul 07 20:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Kgw-0003hc-2g; Sat, 07 Jul 2007 20:31:58 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7Kgu-0003hN-8L for behave-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 20:31:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Kgt-0003hF-Tf for behave@ietf.org; Sat, 07 Jul 2007 20:31:55 -0400 Received: from web33315.mail.mud.yahoo.com ([68.142.206.130]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I7Kge-0008L4-H6 for behave@ietf.org; Sat, 07 Jul 2007 20:31:55 -0400 Received: (qmail 27504 invoked by uid 60001); 8 Jul 2007 00:29: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=Yu/qNfQwBFXSvcy5IjSSK6j5mVN7a/pFlmrJWzVbWenHWKuVKf8pfErgSm9+/HWLGgzjFqeFrCrAwioGDl4Gn5bf0L1uGVbJS5Cgukeo+5n6Nn2EvdlVxH4a958StP6PD/OpUUoy3enjxBpbNmoz1Y3sRcJ44hEaIZWCBOQyc2I=; X-YMail-OSG: gxIgmk4VM1nI.uU32OV26d_Z2W7iVu_VBkW2wHWxD8uvvCV1v48i.haFcdhoRxkUoYyE2g-- Received: from [209.172.74.45] by web33315.mail.mud.yahoo.com via HTTP; Sat, 07 Jul 2007 17:29:39 PDT Date: Sat, 7 Jul 2007 17:29:39 -0700 (PDT) From: Pyda Srisuresh To: Dan Wing , behave@ietf.org In-Reply-To: <037c01c77c9b$690b93d0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <708133.27063.qm@web33315.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: draft-ford-behave-app@tools.ietf.org Subject: [BEHAVE] Re: removing application milestone X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dear all, I believe, it is WRONG to drop this milestone from the WG. There is no technical justification that I can see. Application behave milestone, along with NAT behave milestones(TCP, UDP etc) forms key foundation to the formation of this WG. Doing NAT milestones and not the application milestone makes the WG work incomplete, IMHO. If you care about applications traversing NATs, here is my appeal to you - Please voice your opinion on this list if you think it WRONG to drop application behave milestone from the WG charter. I reviewed the audio from the last WG meeting and read the minutes - I believe, the discussion was off-track from the get-go and did not have a counter balance to the "Why do we want to say how to design ICE when ICE already exists" line of argument. The milestone or the draft(ford-behave-app) is not about how to design ICE; The milestone and the draft is about how to design applications (in general) to work with nodes behind NATs; ICE is one example of a protocol that successfully adapted the recommendationds for a class of applications. ICE does not obviate the milestone or the draft; but rather reinforces them, IMHO. The behave milestone has been around for more than 2 years; so has the ford-behave-appl draft been. The milestone and the draft have been created independently of ICE. Embracing of ICE should be a testament to the goodness of the recommendations in the draft, not grounds for removing the draft or the milestone. Now, I do recognize, one BIG problem has been that none of the authors of ford-behave-app draft had been available to present the draft in any of the IETF meetings. This certainly had hurt the draft in the last IETF meeting. Both Dan and I made attempts in the past to bring in a new co-author. But, no avail. I am open to anyone who would be interested in co-authoring and presenting the draft in IETF meetings. Lastly, I want to enphasise, this is about dropping the milestone first; Dropping the ford-behave-app draft is only next. I was told ford-behave-app draft can indepednently move forward as an individual submission. When the draft is deemed useful to move forward, I dont understand why the milestone had to be removed. Well, I said my 2c. Thank you for your time. regards, suresh --- Dan Wing wrote: > At the BEHAVE meeting in Prague there was strong consensus to remove the > milestone: > "Submit informational that discusses current NAT > traversal techniques used by applications" > from our charter, and to not adopt draft-ford-behave-app to meet that > milestone. > > If the mailing list doesn't have a substantial disagreement with the > consensus from the Prague meeting, I will remove that milestone from our > charter. > > > > Also during the meeting there were some ideas around adding a new milestone > for a document which might discuss when an application might choose UNSAF > (STUN), Bonjour/UPnP, or other NAT traversal techniques. If a candidate > document emerges we can consider creating such a milestone. > > -d > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jul 08 18:16: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 1I7f2s-0001lS-Fg; Sun, 08 Jul 2007 18:15:58 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7f2r-0001db-Ba for behave-confirm+ok@megatron.ietf.org; Sun, 08 Jul 2007 18:15:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7f2q-0001bv-W1; Sun, 08 Jul 2007 18:15:57 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7f2S-0001g0-53; Sun, 08 Jul 2007 18:15:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 21433328DD; Sun, 8 Jul 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7f1y-00026p-0o; Sun, 08 Jul 2007 18:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 08 Jul 2007 18:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-multicast-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP Multicast Requirements for a Network Address (and port) Translator (NAT) Author(s) : T. Eckert, D. Wing Filename : draft-ietf-behave-multicast-08.txt Pages : 15 Date : 2007-7-8 This document specifies requirements for a Network Address (and port) Translator (NAT) that supports any source IP multicast or source specific IP multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-multicast-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-multicast-08.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-7-8170023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-multicast-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-multicast-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-8170023.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Sun Jul 08 18:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7fJ4-0003u4-UP; Sun, 08 Jul 2007 18:32:42 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7fJ3-0003tw-5Y for behave-confirm+ok@megatron.ietf.org; Sun, 08 Jul 2007 18:32:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7fJ2-0003to-RE for behave@ietf.org; Sun, 08 Jul 2007 18:32:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7fJ2-0004qF-Ih for behave@ietf.org; Sun, 08 Jul 2007 18:32:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 Jul 2007 15:32:40 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADcDkUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,514,1175497200"; d="scan'208"; a="178550271:sNHT25940196" 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 l68MWdJo019364; Sun, 8 Jul 2007 15:32:39 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l68MWcXH005488; Sun, 8 Jul 2007 22:32:39 GMT From: "Dan Wing" To: Date: Sun, 8 Jul 2007 15:32:38 -0700 Message-ID: <020a01c7c1af$e3f80bb0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfBrXbN3UNuG0qZRnCbXMUXVg7IpwAAXc1Q DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=470; t=1183933959; x=1184797959; 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:=20multicast-08 |Sender:=20; bh=oSoia44ki0iXRG70XeL8n6OMnmOHv9foRj73ZWzIPfY=; b=Vtr493OauW/jtgQezO3zEltBh8JX6LLAOMHQL4clrYWld95vRIUKWrRG/9hEdh4MnCYiB0i4 c9h+yGL79l70sj4cC7C/KCNOJE33n+1zPzTCM9Fh/hVMpFTtFhnQ8XOd; 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: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [BEHAVE] multicast-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org draft-ietf-behave-multicast-08.txt was just posted at http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-08.txt This version is a significant re-organization from previous versions and includes several additions that were necessary to incorporate feedback from -06. If you are at all interested in NATting of multicast traffic, please review this document. I expect to issue a WGLC on it shortly. Please send comments to behave@ietf.org. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 09 00:00: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 1I7kPv-0002Ez-BL; Mon, 09 Jul 2007 00:00:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7kPr-0002Cs-M7 for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 00:00:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7kPr-0002Ci-2I; Mon, 09 Jul 2007 00:00:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7kPq-000306-Ot; Mon, 09 Jul 2007 00:00:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A417C2AC75; Mon, 9 Jul 2007 04:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7kPq-0002AF-3H; Mon, 09 Jul 2007 00:00:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jul 2007 00:00:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Session Traversal Utilities for (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-07.txt Pages : 46 Date : 2007-07-08 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-07-08235854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-08235854.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 Mon Jul 09 10:52: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 1I7ub8-0005sg-4X; Mon, 09 Jul 2007 10:52:22 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7ub6-0005sC-JO for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 10:52:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7ub5-0005rw-Fw for behave@ietf.org; Mon, 09 Jul 2007 10:52:20 -0400 Received: from mail-hub-1.cs.cornell.edu ([128.84.103.138] helo=exch-hub1.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7ub1-0001Tc-5W for behave@ietf.org; Mon, 09 Jul 2007 10:52:19 -0400 Received: from exchfe2.cs.cornell.edu (128.84.97.34) by mail-hub.cs.cornell.edu (128.84.103.140) with Microsoft SMTP Server id 8.0.700.0; Mon, 9 Jul 2007 10:51:46 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 10:42:40 -0400 Received: from [127.0.0.1] ([128.84.96.18]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 10:42:39 -0400 Subject: Re: [BEHAVE] Relationship between TCP and UDP From: Saikat Guha To: David Barrett In-Reply-To: References: Date: Mon, 9 Jul 2007 03:15:39 -0700 Message-ID: <1183976139.3233.68.camel@seshat.guha.cc> MIME-Version: 1.0 X-Mailer: Evolution 2.10.2 (2.10.2-2.fc7) X-OriginalArrivalTime: 09 Jul 2007 14:42:40.0186 (UTC) FILETIME=[667DD1A0:01C7C237] Received-SPF: None (mail-hub.cs.cornell.edu: saikat@cs.cornell.edu does not designate permitted sender hosts) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============1865053028==" Errors-To: behave-bounces@ietf.org --===============1865053028== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1dR/JNuORF7zkDcscoTu" --=-1dR/JNuORF7zkDcscoTu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 2007-07-07 at 15:59 -0700, David Barrett wrote: > When a client opens both a UDP and TCP port on the same endpoint (ie, > same IP:port), can the TCP port receive incoming connections via a NAT > mapping established using UDP? UDP ports and TCP ports are separate namespaces; endpoints are identified by the 3-tuple (proto, ip, port) so it's not the "same endpoint" per se. By my understanding of the documents, a UDP hole CANNOT be used by TCP and vice versa, but I don't think it is explicitly mentioned anywhere. ICE does mention that each TCP or UDP candidate (regardless of same or different port) must perform a separate STUN binding discovery. > But separate from what should or should not be the case, I=E2=80=99m wond= ering > to what degree NATs actually do in practice. Anybody know? I have never tested whether opening a UDP (or TCP) hole implicitly opens up a TCP (or UDP) hole for that port, so I do not know the answer, but it would indeed be interesting to find out. --=20 Saikat --=-1dR/JNuORF7zkDcscoTu 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) iD8DBQBGkgrLnFltqi691/oRAkf9AJ4mg2U3KmpgLavY2a2+r8NW2WCL0ACfarM2 6LnSSxhfA+KoBRf9VRr/dt0= =xUuW -----END PGP SIGNATURE----- --=-1dR/JNuORF7zkDcscoTu-- --===============1865053028== 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 --===============1865053028==-- From behave-bounces@ietf.org Mon Jul 09 11:41: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 1I7vMG-00017H-Pm; Mon, 09 Jul 2007 11:41:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7vMF-00013K-HH for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 11:41:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vMF-00011V-4Q for behave@ietf.org; Mon, 09 Jul 2007 11:41:03 -0400 Received: from kecgate03.infosys.com ([220.227.179.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7vME-0002Wl-CH for behave@ietf.org; Mon, 09 Jul 2007 11:41:03 -0400 Received: from indhubbhs04.ad.infosys.com ([192.168.200.84]) by Kecgate03.infosys.com with InterScan Message Security Suite; Mon, 09 Jul 2007 21:11:36 +0530 Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by indhubbhs04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 21:10:24 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Mon, 9 Jul 2007 21:10:23 +0530 From: Bharat Joshi To: Dan Wing Date: Mon, 9 Jul 2007 21:08:08 +0530 Thread-Topic: multicast-08 Thread-Index: AcfBr/eGV7amjQ/pQ1O1JYZZkmCTcgAjy7IA Message-ID: <31D55C4D55BEED48A4459EB64567589A092A84EAD6@BLRKECMBX02.ad.infosys.com> References: <020b01c7c1b0$08cb1400$c3f0200a@amer.cisco.com> In-Reply-To: <020b01c7c1b0$08cb1400$c3f0200a@amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2007 15:40:24.0017 (UTC) FILETIME=[77187C10:01C7C23F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "behave@ietf.org" Subject: [BEHAVE] RE: multicast-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Dan, I still have some questions and suggestions: * In introduction, I think you can add a paragraph for the hosts "inside"= the NAT can source multicast traffic. * Can you please simplify the following statement under section #3: In general, receipt of IGMP messages by the device updated IGMP state= maintained by the device and either those changes or timers trigger the= sending of IGMP messages. * The section header "NATting IP Multicast Packets" is misnomer. IGMP= messages are also IP Multicast packets as their destination IP is a= multicast address. I guess you would want to differentiate the handling of= IGMP messages with IP Multicast data traffic. * I think I mentioned this last time also. I did not understand the= differentiation you have mentioned for IGMPv1,v2 and IGMPv3 Thanks, Bharat ________________________________________ From: Dan Wing [dwing@cisco.com] Sent: Monday, July 09, 2007 4:03 AM To: 'Manfredi, Albert E'; Bharat Joshi; prashantj@huawei.com; 'Brian= Haberman'; Alvaro@soportemv.com; 'Jean-Jacques Pansiot'; 'Marshall= Eubanks'; 'Leymann, Nicolai' Cc: Toerless Eckert Subject: multicast-08 FYI. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Sunday, July 08, 2007 3:33 PM > To: 'behave@ietf.org' > Cc: Toerless Eckert > Subject: multicast-08 > > draft-ietf-behave-multicast-08.txt was just posted at > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-08.txt > > This version is a significant re-organization from previous > versions and includes several additions that were necessary > to incorporate feedback from -06. If you are at all > interested in NATting of multicast traffic, please review > this document. I expect to issue a WGLC on it shortly. > > Please send comments to behave@ietf.org. > > -d > **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 09 14:43: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 1I7yCI-00072k-Np; Mon, 09 Jul 2007 14:42:58 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7yCH-00072a-J0 for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 14:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yCH-00072N-3s for behave@ietf.org; Mon, 09 Jul 2007 14:42:57 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7yCD-00019p-Nw for behave@ietf.org; Mon, 09 Jul 2007 14:42:57 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l69IgqLo011327; Mon, 9 Jul 2007 14:42:52 -0400 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] STUN relay with push mode QoS reservation Date: Mon, 9 Jul 2007 14:42:52 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718803D@sonusmail04.sonusnet.com> In-Reply-To: <113801c7c008$3745ef70$e171150a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN relay with push mode QoS reservation Thread-Index: Ace/aPEiMhG88JRuTjmE/lE5TFbgOQAl6o6wAJVGJ/A= References: <033458F56EC2A64E8D2D7B759FA3E7E7188028@sonusmail04.sonusnet.com> <113801c7c008$3745ef70$e171150a@amer.cisco.com> From: "Asveren, Tolga" To: "Dan Wing" , X-Spam-Score: 2.0 (++) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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 Thanks a lot for the information. I still have a couple of questions and am probably missing some important points regarding this issue: a) How does a proxy learn about the result of the ICE selection? b) AFAIU, rel-addr/rel-port will give information about server reflexive candidate. How can proxy learn about the inside address of the STUN relay (IP2 in the below figure)? c) What if STUN relay is used but no ICE? Thanks, Tolga > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, July 06, 2007 4:00 PM > To: Asveren, Tolga > Cc: behave@ietf.org > Subject: RE: [BEHAVE] STUN relay with push mode QoS reservation >=20 > Hi. >=20 > The rel-addr and rel-port attributes are intended to solve > that very problem, and is described in appendix B.3 of > draft-ietf-mmusic-ice-16. Please let Jonathan know if that > mechanism is insufficient, as I believe he is working to > get -17 submitted. Here is the text of that appendix for > your reference: >=20 > B.3. Purpose of the and Attributes >=20 > The candidate attribute contains two values that are not used at all > by ICE itself - and . Why is it present? >=20 > There are two motivations for its inclusion. The first is > diagnostic. It is very useful to know the relationship between the > different types of candidates. By including it, an agent can know > which relayed candidate is associated with which reflexive candidate, > which in turn is associated with a specific host candidate. When > checks for one candidate succeed and not the others, this provides > useful diagnostics on what is going on in the network. >=20 > The second reason has to do with off-path Quality of Service (QoS) > mechanisms. When ICE is used in environments such as PacketCable > 2.0, proxies will, in addition to performing normal SIP operations, > inspect the SDP in SIP messages, and extract the IP address and port > for media traffic. They can then interact, through policy servers, > with access routers in the network, to establish guaranteed QoS for > the media flows. This QoS is provided by classifying the RTP traffic > based on 5-tuple, and then providing it a guaranteed rate, or marking > its Diffserv codepoints appropriately. When a residential NAT is > present, and a relayed candidate gets selected for media, this > relayed candidate will be a transport address on an actual STUN > relay. That address says nothing about the actual transport address > in the access router that would be used to classify packets for QoS > treatment. Rather, the server reflexive candidate towards that relay > is needed. By carrying the translation in the SDP, the proxy can use > that transport address to request QoS from the access router. >=20 > -d >=20 >=20 > > I was trying to figure out how to merge STUN relay with push mode QoS > > reservation. In this model, QoS reservation is triggered from network > > rather than the UA. > > > > Consider the following scenario: > > > > +----+ +-----+ +------+ > > | | | | | | > > | UA1+------+ NAT +---------------------+ AF -------+ > > | |xxxxxx| | | | | > > +----+ +-----+ +---"--+ | > > x(IP1) " | > > x +--------+ " +--+-+ > > x | STUN | " | | > > x | Relay |xxxxxxxxxxxxxxxxx| UA2| > > x | |(IP3) " (IP4)| | > > x +--------+ " +----+ > > x x(IP2) " > > +-----+ x +---"--+ > > | |xxxxxxxx | | > > | PEF | | PDF | > > | """"""""""""""""""""""" | > > +-----+ +------+ > > > > > > --- Call Signaling (SIP/SDP) > > > > """ QoS Signaling (Diameter QoS application) > > > > xxx Media > > > > AF Application Function (Proxy, Application Server, > > P-CSCF etc...) > > > > PDF Policy Decision Function > > > > PEF Policy Enforcement Function (Router, CMTS etc..) > > > > UA1 uses IP3 in the SDP, and UA2 will use IP4. These addresses are > > visible to AF (because it is on the SIP signaling path), and > > it will use > > that information while reserving QoS for that particular session. > > > > The problem is PEF needs to know IP1 and IP2 but will get IP3 and IP4. > > STUN relay knows the binding between IP1/IP2 and IP3/IP4. > > This makes me > > think whether it would make sense to have a STUN mechanism so that > > trusted external entities can query STUN relay about the bindings. > > > > Thanks, > > Tolga > > > > > > _______________________________________________ > > 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 Jul 09 15:02: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 1I7yV0-0002WA-LQ; Mon, 09 Jul 2007 15:02:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7yUz-0002Vw-64 for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 15:02:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yUy-0002Vo-QP for behave@ietf.org; Mon, 09 Jul 2007 15:02:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7yUx-0002pZ-46 for behave@ietf.org; Mon, 09 Jul 2007 15:02:16 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2007 12:02:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFsikkarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208"; a="384421567:sNHT86290036" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l69J2EGR022428; Mon, 9 Jul 2007 12:02:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l69J28l8020318; Mon, 9 Jul 2007 19:02:09 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 12:02:09 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 12:02:09 -0700 Message-ID: <46928635.5080209@cisco.com> Date: Mon, 09 Jul 2007 15:02:13 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [BEHAVE] STUN relay with push mode QoS reservation References: <033458F56EC2A64E8D2D7B759FA3E7E7188028@sonusmail04.sonusnet.com> <113801c7c008$3745ef70$e171150a@amer.cisco.com> <033458F56EC2A64E8D2D7B759FA3E7E718803D@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718803D@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 19:02:09.0427 (UTC) FILETIME=[A67B7630:01C7C25B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2050; t=1184007734; x=1184871734; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20relay=20with=20push=20mode=20QoS=20 reservation |Sender:=20; bh=19ry0gzzKFy5QLW0HbbpJSZd+krQHPgQy8ZIShTuYGk=; b=iTSn5OnxTi0B+r7DHC21OSlxGApn7Hqhh/puO++A3iTyJomx8JxBGIel/Ed/iuDYYIPZmIDw w/4Vkxqx56gJqnMSQuaUChX8ebf7W63MHqUcejLvqPvQ75r+TL6iwiv/hM524osviaU9szs72z u2YnvaSo5wGfL8yeUA0hp2bDw=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Asveren, Tolga wrote: > Thanks a lot for the information. > > I still have a couple of questions and am probably missing some > important points regarding this issue: > > a) How does a proxy learn about the result of the ICE selection? There is always a subsequent offer/answer exchange to 'fix-up' the SDP so that the m/c-lines match the candidates selected by ICE. > > b) AFAIU, rel-addr/rel-port will give information about server reflexive > candidate. How can proxy learn about the inside address of the STUN > relay (IP2 in the below figure)? No, the rel-addr applies to TURN also: > and : convey transport addresses related to the > candidate, useful for diagnostics and other purposes. > and MUST be present for server reflexive, peer > reflexive and relayed candidates. If a candidate is server or > peer reflexive, and is equal to the base for > that server or peer reflexive candidate. If the candidate is > relayed, and is equal to the mapped address > in the Allocate Response that provided the client with that > relayed candidate (see Appendix B.3 for a discussion of its > purpose). If the candidate is a host candidate and > MUST be omitted. This server reflexive related-address is exactly what you'd use in push mode QoS. > > c) What if STUN relay is used but no ICE? Well, then you get what you pay for. At this point we are not recommending that. ICE is the IETF solution for SIP nat traversal of media, period. Not stun by itself. Not turn by itself. -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 Jul 09 15:45: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 1I7zB5-0003yX-AR; Mon, 09 Jul 2007 15:45:47 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7zB3-0003xb-A0 for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 15:45:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yok-0004x7-2Z for behave@ietf.org; Mon, 09 Jul 2007 15:22:42 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7yoj-0005nw-D0 for behave@ietf.org; Mon, 09 Jul 2007 15:22:41 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l69JMJOG015640; Mon, 9 Jul 2007 15:22:19 -0400 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] STUN relay with push mode QoS reservation Date: Mon, 9 Jul 2007 15:22:19 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718803F@sonusmail04.sonusnet.com> In-Reply-To: <46928635.5080209@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN relay with push mode QoS reservation Thread-Index: AcfCW6pp+Lzig9+uR8qC0s6Gf1yOJwAAWSig References: <033458F56EC2A64E8D2D7B759FA3E7E7188028@sonusmail04.sonusnet.com> <113801c7c008$3745ef70$e171150a@amer.cisco.com> <033458F56EC2A64E8D2D7B759FA3E7E718803D@sonusmail04.sonusnet.com> <46928635.5080209@cisco.com> From: "Asveren, Tolga" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 One follow-up question below. Thanks, Tolga > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Monday, July 09, 2007 3:02 PM > To: Asveren, Tolga > Cc: Dan Wing; behave@ietf.org > Subject: Re: [BEHAVE] STUN relay with push mode QoS reservation >=20 >=20 >=20 > Asveren, Tolga wrote: > > Thanks a lot for the information. > > > > I still have a couple of questions and am probably missing some > > important points regarding this issue: > > > > a) How does a proxy learn about the result of the ICE selection? >=20 > There is always a subsequent offer/answer exchange to 'fix-up' the SDP > so that the m/c-lines match the candidates selected by ICE. >=20 > > > > b) AFAIU, rel-addr/rel-port will give information about server reflexive > > candidate. How can proxy learn about the inside address of the STUN > > relay (IP2 in the below figure)? >=20 > No, the rel-addr applies to TURN also: >=20 > > and : convey transport addresses related to the > > candidate, useful for diagnostics and other purposes. > > and MUST be present for server reflexive, peer > > reflexive and relayed candidates. If a candidate is server or > > peer reflexive, and is equal to the base for > > that server or peer reflexive candidate. If the candidate is > > relayed, and is equal to the mapped address > > in the Allocate Response that provided the client with that > > relayed candidate (see Appendix B.3 for a discussion of its > > purpose). If the candidate is a host candidate and > > MUST be omitted. >=20 >=20 > This server reflexive related-address is exactly what you'd use in push > mode QoS. [TOLGA]Yes, it is one of the addresses needed (the internal remote transport address). AFAICS, the other address needed is internal local transport address of STUN relay. What I was wondering was how internal local transport address is signaled to the proxy. >=20 > > > > c) What if STUN relay is used but no ICE? >=20 > Well, then you get what you pay for. At this point we are not > recommending that. ICE is the IETF solution for SIP nat traversal of > media, period. Not stun by itself. Not turn by itself. >=20 > -Jonathan R. >=20 >=20 > -- > 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 Jul 09 16:02:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zQk-0001OD-Ug; Mon, 09 Jul 2007 16:01:58 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7zQj-0001Nf-E1 for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:01:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zQj-0001N3-1G for behave@ietf.org; Mon, 09 Jul 2007 16:01:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7zQi-0007qD-N7 for behave@ietf.org; Mon, 09 Jul 2007 16:01:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2007 13:01:56 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFMxkkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208"; a="7404501:sNHT13609218" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l69K1u5x027969; Mon, 9 Jul 2007 13:01:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l69K1cwB023426; Mon, 9 Jul 2007 20:01:56 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:01:54 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:01:54 -0700 Message-ID: <46929436.4000107@cisco.com> Date: Mon, 09 Jul 2007 16:01:58 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [BEHAVE] STUN relay with push mode QoS reservation References: <033458F56EC2A64E8D2D7B759FA3E7E7188028@sonusmail04.sonusnet.com> <113801c7c008$3745ef70$e171150a@amer.cisco.com> <033458F56EC2A64E8D2D7B759FA3E7E718803D@sonusmail04.sonusnet.com> <46928635.5080209@cisco.com> <033458F56EC2A64E8D2D7B759FA3E7E718803F@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718803F@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:01:54.0424 (UTC) FILETIME=[FF4E9780:01C7C263] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1911; t=1184011316; x=1184875316; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20relay=20with=20push=20mode=20QoS=20 reservation |Sender:=20; bh=uAvXmi8EB4l3BUl1TcD+hlAv0i1JmaRfyH8mFf+Gifw=; b=pWZE+4kv2zsawB+dVDWTssUbkFoEzu9uD0g608OrB4GmVlQmLBGAcQie+jwvMVY9H8jKaK4o hRd19zNqs2cbKejpNkR6Zym1t3XNVKA1amuikNoCgTbCFTKlRalSR0OH; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 inline. Asveren, Tolga wrote: >>> and : convey transport addresses related to > the >>> candidate, useful for diagnostics and other purposes. > >>> and MUST be present for server reflexive, peer >>> reflexive and relayed candidates. If a candidate is server or >>> peer reflexive, and is equal to the base > for >>> that server or peer reflexive candidate. If the candidate is >>> relayed, and is equal to the mapped > address >>> in the Allocate Response that provided the client with that >>> relayed candidate (see Appendix B.3 for a discussion of its >>> purpose). If the candidate is a host candidate and >>> MUST be omitted. >> >> This server reflexive related-address is exactly what you'd use in > push >> mode QoS. > [TOLGA]Yes, it is one of the addresses needed (the internal remote > transport address). AFAICS, the other address needed is internal local > transport address of STUN relay. What I was wondering was how internal > local transport address is signaled to the proxy. I'm not sure which address you mean. For packets forwarded from the TURN server, towards the client, the destination address is the server-reflexive address towards the TURN server, laerned as above. THe source address is the IP/port of the TURN server itself. Is it that one you are talking about? That one is not signaled. I don't see why you need it though. -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 Jul 09 16:10:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zYn-0005Fr-7M; Mon, 09 Jul 2007 16:10:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I7zYm-0005Fg-C4 for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:10:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zYl-0005FO-TP for behave@ietf.org; Mon, 09 Jul 2007 16:10:16 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7zYl-0008AZ-KG for behave@ietf.org; Mon, 09 Jul 2007 16:10:15 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l69KA57S025978; Mon, 9 Jul 2007 16:10:05 -0400 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] STUN relay with push mode QoS reservation Date: Mon, 9 Jul 2007 16:10:05 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188042@sonusmail04.sonusnet.com> In-Reply-To: <46929436.4000107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN relay with push mode QoS reservation Thread-Index: AcfCZAO7A1/ZbloTTE2atfpP5sNV+wAALusA References: <033458F56EC2A64E8D2D7B759FA3E7E7188028@sonusmail04.sonusnet.com> <113801c7c008$3745ef70$e171150a@amer.cisco.com> <033458F56EC2A64E8D2D7B759FA3E7E718803D@sonusmail04.sonusnet.com> <46928635.5080209@cisco.com> <033458F56EC2A64E8D2D7B759FA3E7E718803F@sonusmail04.sonusnet.com> <46929436.4000107@cisco.com> From: "Asveren, Tolga" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 >=20 > >>> and : convey transport addresses related to > > the > >>> candidate, useful for diagnostics and other purposes. > > > >>> and MUST be present for server reflexive, peer > >>> reflexive and relayed candidates. If a candidate is server or > >>> peer reflexive, and is equal to the base > > for > >>> that server or peer reflexive candidate. If the candidate is > >>> relayed, and is equal to the mapped > > address > >>> in the Allocate Response that provided the client with that > >>> relayed candidate (see Appendix B.3 for a discussion of its > >>> purpose). If the candidate is a host candidate and > >>> MUST be omitted. > >> > >> This server reflexive related-address is exactly what you'd use in > > push > >> mode QoS. > > [TOLGA]Yes, it is one of the addresses needed (the internal remote > > transport address). AFAICS, the other address needed is internal local > > transport address of STUN relay. What I was wondering was how internal > > local transport address is signaled to the proxy. >=20 > I'm not sure which address you mean. For packets forwarded from the TURN > server, towards the client, the destination address is the > server-reflexive address towards the TURN server, laerned as above. THe > source address is the IP/port of the TURN server itself. Is it that one > you are talking about? That one is not signaled. I don't see why you > need it though. [TOLGA]Yes it was the address I was talking about but you are right that it is actually not needed. We are dealing with a NAT whose mapping depends on address/address port in this case. Just specifying the server reflexive address for the QoS filtering rule should be enough to define the flow unambiguously. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 09 16:45: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 1I807B-0003NL-12; Mon, 09 Jul 2007 16:45:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8079-0003Mx-8b for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:45:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8078-0003Mk-VD for behave@ietf.org; Mon, 09 Jul 2007 16:45:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I806y-0006Bc-Nb for behave@ietf.org; Mon, 09 Jul 2007 16:45:46 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2007 13:45:06 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKI7kkarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208"; a="501381191:sNHT146598544" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l69Kj6xM031268 for ; Mon, 9 Jul 2007 13:45:06 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l69KiuXh026409 for ; Mon, 9 Jul 2007 20:45:06 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:45:03 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:45:03 -0700 Message-ID: <46929E54.50301@cisco.com> Date: Mon, 09 Jul 2007 16:45:08 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:45:03.0888 (UTC) FILETIME=[06BF7100:01C7C26A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2823; t=1184013906; x=1184877906; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20RFC3489bis-07=20now=20available |Sender:=20; bh=Ftiprbvrg+CpLUjoa26K7QpFJeDtdFKjvbAvjco40qE=; b=dDDjgepFAcIdcJVUznBWOMy53LrdXTtSooz+9mlt5npVE2fMBF4LbNp4oGtl4+wIecLCgZeo vE8YW+I9DO58z8DpjtchZO5mrfDUGAVcfq2sMunOgRZZp+6zdDLrkT7M; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [BEHAVE] RFC3489bis-07 now available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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-07 is now available: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt Firstly, I'd like to thank Philip Matthews and Dan Wing for taking up much of the editing and administrative tasks required in incorporating the huge number of comments that were made during the previous WGLC. Philip has been added as a co-author for his work on this document. We *think* we captured all of the comments, both nits and more substantive issues, raised during WGLC. There are lots of changes in this draft, most of them around structure, organization and terminology. On-the-wire only a little has changed. A big part of the changes were an attempt to simplify a document which really seemed too long for a protocol that actually does very little. We eliminated 15 pages, going from 61 in bis-06 to 46 here. Changes to note are: * completely redefined what a usage is. THis was the source of a lot of fluff in the text. Now, a usage is just a protocol that makes use of STUN for nat traversal. ICE is a usage. So is sip-outbound. THere are no longer formal requirements for definition of a usage; the usage just says how to use STUN, which these drafts already do. STUN can have extensions - these are new attributes, methods, and error codes. ICE uses STUN and also defines a few extensions. * security considerations is pared down; really the job of defining security lies with the usage. STUN by itself has security problems, but when used with ICE they are mitigated. Since we are not ever recommending stun by itself, no need to treat security of a pure stun system * removed IAB consideartions - per above this is ICE's job now * removed shared secret request and response. This is just way too complex. It had already been relegated to a usage. Now its gone. THe main driving need has evaporated with ICE. * simplified the authentication sections, splitting them out into two separte subsections which clearly explain how short term works and how long term works. We no longer support dynamically switching from one to the other. Rather a usage states which one is used. * removal of several error codes that could only happen in implementation errors. * split IANA registry for attributes and methods into one that is done by IETF, and a vendor first-come first-served space * defined length limits on all free-form fields Dan or Philip - others you'd like to add? -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 Jul 09 16:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80Bu-00029v-FP; Mon, 09 Jul 2007 16:50:42 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I80Br-00029k-Cm for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80Br-00029c-2w for behave@ietf.org; Mon, 09 Jul 2007 16:50:39 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I80Bn-0006Mo-Pd for behave@ietf.org; Mon, 09 Jul 2007 16:50:39 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 2953C3A02022; Mon, 9 Jul 2007 13:50:35 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 168223A02020 for ; Mon, 9 Jul 2007 13:50:33 -0700 (PDT) Message-ID: <46929F98.5020706@acm.org> Date: Mon, 09 Jul 2007 13:50:32 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.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: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I read the new draft, and I am happy with the improvements. All nine comments in my review are fixed one way or another in this draft. Many thanks to do not remove the 300 error code. Some comments: 1. Section 13: The second paragraph lists ICE, Outbound and NAT Behavior discovery as STUN usages. Shouldn't STUN relay be added to this list? 2. Section 13: On the list of definitions that an usage should provide, it should be specified if a new method is idempotent (see section 7.3.1) 3. Section 16: "STUN can be used to perform this function using a BindingRequest/BindingResponse transaction..." should be "using a Binding request/response transaction...". Four nits: 1. Section 10.2.2: "It is RECOMENDED that the REALM value by the domain name.." should be "It is RECOMMENDED that the REALM value is the domain name..." 2. Section 7.2.2: "...must be run ontop of some kind.." Should be "on top" 3. Section 12: "...and transaction ids were 128 bits long;" should be "128 bits long." 4. Section 12: "...used the MAPPED-ADDRESS attribute instead" should be "attribute instead." 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-07.txt > Pages : 46 > Date : 2007-07-08 > -- 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 Mon Jul 09 16:59: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 1I80Jy-0001A2-EV; Mon, 09 Jul 2007 16:59:02 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I80Jv-00019i-Ru for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:58:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80Jv-000199-By for behave@ietf.org; Mon, 09 Jul 2007 16:58:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I80Jo-0001wb-8c for behave@ietf.org; Mon, 09 Jul 2007 16:58:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2007 13:58:51 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHs+kkarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208"; a="179110844:sNHT45057753" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l69Kwpjp020576; Mon, 9 Jul 2007 13:58:51 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l69KwoXH008842; Mon, 9 Jul 2007 20:58:50 GMT From: "Dan Wing" To: "'Bharat Joshi'" Date: Mon, 9 Jul 2007 13:58:50 -0700 Message-ID: <0fbb01c7c26b$f3d37800$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <31D55C4D55BEED48A4459EB64567589A092A84EAD6@BLRKECMBX02.ad.infosys.com> Thread-Index: AcfBr/eGV7amjQ/pQ1O1JYZZkmCTcgAjy7IAAArcy/A= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4560; t=1184014731; x=1184878731; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20multicast-08 |Sender:=20; bh=62+0OtCQqtsPfQhLclu5T7BjP+w9WevDKnye5UWFKOk=; b=jFrMJGixvRhCdCd5ouKxmXqgc/IvOxT2N3XWpHdAeIqlCMd0HzFrtQ7+Ci6FuMrotQWnDZL5 Aj1TdWpzJYGlbr1m4CWB6ZsT1r3khEj4F0eMjxU0rVYDjhFb4YgmwudA; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: behave@ietf.org Subject: [BEHAVE] RE: multicast-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: Bharat Joshi [mailto:bharat_joshi@infosys.com] > Sent: Monday, July 09, 2007 8:38 AM > To: Dan Wing > Cc: behave@ietf.org > Subject: RE: multicast-08 > > > Hi Dan, > > I still have some questions and suggestions: Thanks for your comments. > * In introduction, I think you can add a paragraph for the > hosts "inside" the NAT can source multicast traffic. I added: This allows a host 'inside' the NAT to both receive multicast traffic and to send multicast traffic. to the fourth paragraph. (Full context is at the URL below.) > * Can you please simplify the following statement under section #3: > > In general, receipt of IGMP messages by the device updated > IGMP state maintained by the device and either those changes > or timers trigger the sending of IGMP messages. Let me know if this revision is clearer: In general, receipt of IGMP messages by the device updates the device's IGMP state. The updated state changes the device's forwarding of multicast messages or triggers the sending of IGMP messages. This text is reflected in the updated document below. > * The section header "NATting IP Multicast Packets" is > misnomer. IGMP messages are also IP Multicast packets as > their destination IP is a multicast address. I guess you > would want to differentiate the handling of IGMP messages > with IP Multicast data traffic. I changed that section title to "NATing IP Multicast Data Packets", which is reflected in the updated document below. > * I think I mentioned this last time also. I did not > understand the differentiation you have mentioned for > IGMPv1,v2 and IGMPv3 Are you referring to these requirements? REQ-7: A NAT MAY support IGMPv1 (although IGMPv1 is considered obsolete). REQ-8: A NAT MUST support IGMPv2. REQ-9: A NAT SHOULD support IGMPv3. We're trying to require IGMPv2 and steer support towards v3. Should we add some text describing that motivation? Mostly it's that IGMPv3 and SSM go hand-in-hand, and we want to encourage IGMPv3 implementations. new version: http://svn.resiprocate.org/rep/ietf-drafts/behave/draft-ietf-behave-multicas t-09.txt diffs from -08: http://tools.ietf.org/rfcdiff?url2=http://svn.resiprocate.org/rep/ietf-draft s/behave/draft-ietf-behave-multicast-09.txt -d > Thanks, > Bharat > > ________________________________________ > From: Dan Wing [dwing@cisco.com] > Sent: Monday, July 09, 2007 4:03 AM > To: 'Manfredi, Albert E'; Bharat Joshi; prashantj@huawei.com; > 'Brian Haberman'; Alvaro@soportemv.com; 'Jean-Jacques > Pansiot'; 'Marshall Eubanks'; 'Leymann, Nicolai' > Cc: Toerless Eckert > Subject: multicast-08 > > FYI. > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Sunday, July 08, 2007 3:33 PM > > To: 'behave@ietf.org' > > Cc: Toerless Eckert > > Subject: multicast-08 > > > > draft-ietf-behave-multicast-08.txt was just posted at > > > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-08.txt > > > > This version is a significant re-organization from previous > > versions and includes several additions that were necessary > > to incorporate feedback from -06. If you are at all > > interested in NATting of multicast traffic, please review > > this document. I expect to issue a WGLC on it shortly. > > > > Please send comments to behave@ietf.org. > > > > -d > > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION > intended solely for the use of the addressee(s). If you are > not the intended recipient, please notify the sender by > e-mail and delete the original message. Further, you are not > to copy, disclose, or distribute this e-mail or its contents > to any other person and any such actions are unlawful. This > e-mail may contain viruses. Infosys has taken every > reasonable precaution to minimize this risk, but is not > liable for any damage you may sustain as a result of any > virus in this e-mail. You should carry out your own virus > checks before opening the e-mail or attachment. Infosys > reserves the right to monitor and review the content of all > messages sent to or from this e-mail address. Messages sent > to or from this e-mail address may be stored on the Infosys > e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 09 20:43: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 1I83p4-0003fm-8p; Mon, 09 Jul 2007 20:43:22 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I83p2-0003fh-P1 for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 20:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I83p2-0003fU-1p for behave@ietf.org; Mon, 09 Jul 2007 20:43:20 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I83oy-0003BP-Mu for behave@ietf.org; Mon, 09 Jul 2007 20:43:20 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2007 17:43:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC5zkkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,519,1175497200"; d="scan'208"; a="7465853:sNHT13771596" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6A0hGKF032599; Mon, 9 Jul 2007 17:43:16 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6A0hBka003512; Tue, 10 Jul 2007 00:43:11 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA15598; Mon, 9 Jul 2007 17:42:17 -0700 (PDT) Date: Mon, 9 Jul 2007 17:42:17 -0700 From: Toerless Eckert To: "Manfredi, Albert E" Message-ID: <20070709174217.B13897@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2824; t=1184028196; x=1184892196; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20Toerless=20Eckert=20 |Subject:=20Re=3A=20multicast-08 |Sender:=20; bh=U9w5pZZCaCjIRfrChbvDtMupc1HW2hdVFOwsFPLaHaE=; b=KUC+oKoE3AonEbs0Rnj/mAWjtWZR7DRwDnXImjbEeHB+Mop5opDnDrcUWhm+uU3FHKaZUa0M AVdzWkFUW2qnBAr54lpKvCMcO0t3D++s4DYIpgRLf6uKeHoxQE4vM2D6; Authentication-Results: sj-dkim-3; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Brian Haberman , behave@ietf.org, Dan Wing , Jean-Jacques Pansiot , "Leymann, Nicolai" , Alvaro@soportemv.com, Marshall Eubanks , prashantj@huawei.com, Bharat Joshi Subject: [BEHAVE] Re: multicast-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org TTL scoping, aka: the use of small TTL to determine the reach of a particular multicast group or channel was deprecated by the IETF about 8 years ago. There should really be no mentioning of TTL scoping in an IETF document other than saying not to do it. If you do not believe me, ask the mboned working group. A NAT device needs to handle TTL for multicast as it handles TTL for unicast, which means that all the NAT that i think is considered in the draft must decrement TTL of IP multicast packets forwarded. If a NAT was acting as a bridge, rather than a router, then it would of course not decrementing TTL neither for unicast nor multicast packets, but i thought we do not consider that case at all. IGMP packets are not logically forwarded by a NAT acting as a router, instead they are logically always logically generated, whether the IGMP proxying is working transparently or not. That's why there is no arguing "Oh, but we receive IGMP packets with TTL=1 and we send out IGMP packets with TTL=1, so we do not decrement TTL". I thought the indented paragraph in section 3. explains this sufficiently. Cheers Toerless On Mon, Jul 09, 2007 at 06:53:24PM -0400, Manfredi, Albert E wrote: > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > > > In some cases of which I am aware, the scope of the multicast > > > is in part > > > controlled through use of low values of TTL. Routers are > > considered in > > > determining that value, but the NAT firewalls are not, in > > part because > > > these firewall requirements seem to emerge later in the > > design. So it > > > would be nice if the TTL were not decremented. > > > > It is my understanding that IGMPv3 doesn't discuss TTL because the > > consensus is that TTL isn't a good way to scope multicast > > traffic. That's > > why in draft-ietf-behave-multicast-08 we specified administratively- > > scoped addresses: > > > > REQ-6: A NAT MUST NOT forward administratively scoped > > IP multicast traffic (239.0.0.0/8) [RFC2365] from its > > 'inside' interface(s) to its 'outside' interface, > > unless the NAT has been configured to do so. > > > > > > However, this does leave me wondering what we can or should say about > > NATs decrementing the TTL of multicast data traffic if the host is > > receiving multicast via IGMPv1/v2, or if the host is sending multicast > > (and not listening, in which case the NAT can't decide if the host > > might be IGMPv1/v2/v3-aware). > > > > I'm open to suggestions. > > I would just make that a configurable item. I agree that using TTL to > limit multicast scope is discouraged. However, it is still a technique > used as a fail safe measure. > > Thanks, Dan > > Bert _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 09 23:48: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 1I86hz-0005M5-RD; Mon, 09 Jul 2007 23:48:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I86hy-0005Lz-Tz for behave-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 23:48:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I86hy-0005Lr-KR for behave@ietf.org; Mon, 09 Jul 2007 23:48:14 -0400 Received: from kecgate02.progeon.com ([61.95.162.76] helo=kecgate02.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I86hs-0006Mz-Ae for behave@ietf.org; Mon, 09 Jul 2007 23:48:14 -0400 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by kecgate02.infosys.com with InterScan Message Security Suite; Tue, 10 Jul 2007 09:16:23 +0530 Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 09:18:06 +0530 Received: from [10.10.10.170] (192.168.101.134) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server id 8.0.700.0; Tue, 10 Jul 2007 09:18:05 +0530 From: Bharat Joshi To: Dan Wing In-Reply-To: <0fbb01c7c26b$f3d37800$c3f0200a@amer.cisco.com> References: <0fbb01c7c26b$f3d37800$c3f0200a@amer.cisco.com> Content-Type: text/plain Organization: Infosys Technologies Ltd Date: Tue, 10 Jul 2007 09:21:14 +0530 Message-ID: <1184039474.8377.6.camel@magadha> MIME-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2007 03:48:06.0321 (UTC) FILETIME=[1FDB5A10:01C7C2A5] X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "behave@ietf.org" Subject: [BEHAVE] RE: multicast-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Dan, I looked at the diffs and it looks good to me. Thanks for making these changes. Please see one reply in line. Thanks, Bharat > > * I think I mentioned this last time also. I did not > > understand the differentiation you have mentioned for > > IGMPv1,v2 and IGMPv3 > > Are you referring to these requirements? > > REQ-7: A NAT MAY support IGMPv1 (although IGMPv1 is considered > obsolete). > > REQ-8: A NAT MUST support IGMPv2. > > REQ-9: A NAT SHOULD support IGMPv3. > > We're trying to require IGMPv2 and steer support towards v3. Should we add > some text describing that motivation? Mostly it's that IGMPv3 and SSM go > hand-in-hand, and we want to encourage IGMPv3 implementations. No. I was not pointing to this. I was trying to understand the requirement of saying "For IGMPv3, NAT must support IGMP proxying while for IGMPv1 and v2, its recommended and not mandatory" My understanding is that, NAT would be changing source address of these messages [IGMPv1 and IGMPv2] before sending them to upstream router. In case of IGMPv3, we do IGMP proxying i.e. aggregating reports in NAT device before generating the aggregated report. This would also have source IP as the outside interface IP. Now to me, generating a leave by an IGMPv3 host and immediately after this leave a join, looks to be a normal IGMPv3 host behavior. So why is it that we can not pass these messages the way we pass IGMPv1 and v2 messages? **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 09:58: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 1I8GEg-0006xs-K5; Tue, 10 Jul 2007 09:58:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8GEf-0006xk-KW for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 09:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GEf-0006xc-B3 for behave@ietf.org; Tue, 10 Jul 2007 09:58:37 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8GEf-0005Qe-5Z for behave@ietf.org; Tue, 10 Jul 2007 09:58:37 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6ADwCnB019262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Jul 2007 08:58:13 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6ADwCAI001277; Tue, 10 Jul 2007 06:58:12 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6ADw9pb001120; Tue, 10 Jul 2007 06:58:11 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 09:58:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jul 2007 09:58:10 -0400 Message-ID: In-Reply-To: <20070709174217.B13897@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multicast-08 Thread-Index: AcfCi08ww5iDpGU1Rq+sInJqfqCtMAAblkUg References: <20070709174217.B13897@cisco.com> From: "Manfredi, Albert E" To: "Toerless Eckert" X-OriginalArrivalTime: 10 Jul 2007 13:58:11.0160 (UTC) FILETIME=[5A0A8580:01C7C2FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Brian Haberman , behave@ietf.org, Dan Wing , Jean-Jacques Pansiot , "Leymann, Nicolai" , Alvaro@soportemv.com, Marshall Eubanks , prashantj@huawei.com, Bharat Joshi Subject: [BEHAVE] RE: multicast-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: Toerless Eckert [mailto:eckert@cisco.com]=20 >=20 > TTL scoping, aka: the use of small TTL to determine the reach > of a particular multicast group or channel was deprecated by > the IETF about 8 years ago. There should really be no mentioning > of TTL scoping in an IETF document other than saying not to do it. > If you do not believe me, ask the mboned working group.=20 >=20 > A NAT device needs to handle TTL for multicast as it handles > TTL for unicast, which means that all the NAT that i think is > considered in the draft must decrement TTL of IP multicast > packets forwarded. If a NAT was acting as a bridge, rather than > a router, then it would of course not decrementing TTL neither > for unicast nor multicast packets, but i thought we do not > consider that case at all. >=20 > IGMP packets are not logically forwarded by a NAT acting as a > router, instead they are logically always logically generated, > whether the IGMP proxying is working transparently or not. That's > why there is no arguing "Oh, but we receive IGMP packets with > TTL=3D1 and we send out IGMP packets with TTL=3D1, so we do not > decrement TTL". I thought the indented paragraph in section 3. > explains this sufficiently. I have no problem with words to explain that the NAT may also "act as a bridge," then. Unless I missed the words in the current draft. As a matter of fact, if the NAT is a 1:1 NAT, I see no reason why it can't also relay IGMP messages in IGMPv3 just as it is allowed to do in IGMPv2. In IGMPv3, there is the group-and-source-specific query that should prevent the NAT from "blackholing." Bert _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 11:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HsL-0003qD-Ns; Tue, 10 Jul 2007 11:43:41 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8HsK-0003q8-07 for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 11:43:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HsJ-0003q0-LZ for behave@ietf.org; Tue, 10 Jul 2007 11:43:39 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8HsJ-0008Lr-BR for behave@ietf.org; Tue, 10 Jul 2007 11:43:39 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 Jul 2007 08:43:38 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGtFk0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,523,1175497200"; d="scan'208"; a="501677981:sNHT307718096" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6AFhcf0005830; Tue, 10 Jul 2007 08:43:38 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6AFhTmo013919; Tue, 10 Jul 2007 15:43:29 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA21055; Tue, 10 Jul 2007 08:42:31 -0700 (PDT) Date: Tue, 10 Jul 2007 08:42:31 -0700 From: Toerless Eckert To: "Manfredi, Albert E" Message-ID: <20070710084231.D13897@cisco.com> References: <20070709174217.B13897@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from albert.e.manfredi@boeing.com on Tue, Jul 10, 2007 at 09:58:10AM -0400 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1265; t=1184082218; x=1184946218; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20Toerless=20Eckert=20 |Subject:=20Re=3A=20multicast-08 |Sender:=20; bh=a38JzWtDYdeCS/zbP9Xu2xERT2/P0zyzgFtt9yWsuVE=; b=iqRodtSEgOUJDbbbJhSVoupVVk1MedMMRt8D1iE7ZbyiQuPtPHd825r30AUIgsVcM98T4WG3 z1+x9T8i04BajHdIoxJbipjUzuJm6tPNKfdxGjeYV7JdH7Se1fTR55jZ; Authentication-Results: sj-dkim-4; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Brian Haberman , behave@ietf.org, Dan Wing , Jean-Jacques Pansiot , "Leymann, Nicolai" , Alvaro@soportemv.com, Marshall Eubanks , prashantj@huawei.com, Bharat Joshi Subject: [BEHAVE] Re: multicast-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tue, Jul 10, 2007 at 09:58:10AM -0400, Manfredi, Albert E wrote: > > IGMP packets are not logically forwarded by a NAT acting as a > > router, instead they are logically always logically generated, > > whether the IGMP proxying is working transparently or not. That's > > why there is no arguing "Oh, but we receive IGMP packets with > > TTL=1 and we send out IGMP packets with TTL=1, so we do not > > decrement TTL". I thought the indented paragraph in section 3. > > explains this sufficiently. > > I have no problem with words to explain that the NAT may also "act as a > bridge," then. Unless I missed the words in the current draft. I'd be very surprised if any NAT used in home gateways would do that. > As a matter of fact, if the NAT is a 1:1 NAT, I see no reason why it > can't also relay IGMP messages in IGMPv3 just as it is allowed to do in > IGMPv2. In IGMPv3, there is the group-and-source-specific query that > should prevent the NAT from "blackholing." Problem is if the upstream router wants to support explicit tracking for immediate channel changing, then it would require to really have the NAT be compliant to an IGMPv3 reporter that represents the aggregate joined state of multiple STBs. Cheers Toerless _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 11:54: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 1I8I2z-0001CV-2v; Tue, 10 Jul 2007 11:54:41 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8I2v-0001C0-CR for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 11:54:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8I2u-0001Bk-RU for behave@ietf.org; Tue, 10 Jul 2007 11:54:36 -0400 Received: from kecgate03.progeon.com ([220.227.179.21] helo=Kecgate03.infosys.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8I2f-00006R-3K for behave@ietf.org; Tue, 10 Jul 2007 11:54:36 -0400 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by Kecgate03.infosys.com with InterScan Message Security Suite; Tue, 10 Jul 2007 21:24:12 +0530 Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 21:22:58 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Tue, 10 Jul 2007 21:22:57 +0530 From: Bharat Joshi To: 'Toerless Eckert' , "'Manfredi, Albert E'" Date: Tue, 10 Jul 2007 21:22:54 +0530 Thread-Topic: multicast-08 Thread-Index: AcfDCRfyErfA3aPWTKqFEm6HW24xlwAAaGLw Message-ID: <31D55C4D55BEED48A4459EB64567589A092A6B8660@BLRKECMBX02.ad.infosys.com> References: <20070709174217.B13897@cisco.com> <20070710084231.D13897@cisco.com> In-Reply-To: <20070710084231.D13897@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2007 15:52:58.0138 (UTC) FILETIME=[62FFF7A0:01C7C30A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'Brian Haberman' , "'behave@ietf.org'" , 'Jean-Jacques Pansiot' , "'Leymann, Nicolai'" , "'Alvaro@soportemv.com'" , 'Marshall Eubanks' , "'prashantj@huawei.com'" , 'Dan Wing' Subject: [BEHAVE] RE: multicast-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org One question in line. Thanks, Bharat > > > IGMP packets are not logically forwarded by a NAT acting as a > > > router, instead they are logically always logically generated, > > > whether the IGMP proxying is working transparently or not. That's > > > why there is no arguing "Oh, but we receive IGMP packets with > > > TTL=3D1 and we send out IGMP packets with TTL=3D1, so we do not > > > decrement TTL". I thought the indented paragraph in section 3. > > > explains this sufficiently. > > > > I have no problem with words to explain that the NAT may also "act as a > > bridge," then. Unless I missed the words in the current draft. > > I'd be very surprised if any NAT used in home gateways would do that. > > > As a matter of fact, if the NAT is a 1:1 NAT, I see no reason why it > > can't also relay IGMP messages in IGMPv3 just as it is allowed to do in > > IGMPv2. In IGMPv3, there is the group-and-source-specific query that > > should prevent the NAT from "blackholing." > > Problem is if the upstream router wants to support explicit tracking > for immediate channel changing, then it would require to really > have the NAT be compliant to an IGMPv3 reporter that represents the > aggregate joined state of multiple STBs. > Will it not be the same for IGMPv2 as well? **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 11:59: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 1I8I7k-00072y-88; Tue, 10 Jul 2007 11:59:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8I7i-00071r-RV for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 11:59:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8I7i-00071j-Gm for behave@ietf.org; Tue, 10 Jul 2007 11:59:34 -0400 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8I7i-0000G5-8z for behave@ietf.org; Tue, 10 Jul 2007 11:59:34 -0400 X-TACSUNS: Virus Scanned Received: from rtp-cse-489.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l6AFwsJ19417; Tue, 10 Jul 2007 11:58:54 -0400 (EDT) Received: (from rodunn@localhost) by rtp-cse-489.cisco.com (8.11.7p1+Sun/8.11.6) id l6AFwno17108; Tue, 10 Jul 2007 11:58:49 -0400 (EDT) Date: Tue, 10 Jul 2007 11:58:49 -0400 From: Rodney Dunn To: Toerless Eckert Subject: Re: [BEHAVE] Re: multicast-08 Message-ID: <20070710155849.GA17066@rtp-cse-489.cisco.com> References: <20070709174217.B13897@cisco.com> <20070710084231.D13897@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710084231.D13897@cisco.com> User-Agent: Mutt/1.4.2.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "Manfredi, Albert E" , Brian Haberman , behave@ietf.org, Bharat Joshi , Jean-Jacques Pansiot , "Leymann, Nicolai" , Alvaro@soportemv.com, Marshall Eubanks , prashantj@huawei.com, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tue, Jul 10, 2007 at 08:42:31AM -0700, Toerless Eckert wrote: > On Tue, Jul 10, 2007 at 09:58:10AM -0400, Manfredi, Albert E wrote: > > > IGMP packets are not logically forwarded by a NAT acting as a > > > router, instead they are logically always logically generated, > > > whether the IGMP proxying is working transparently or not. That's > > > why there is no arguing "Oh, but we receive IGMP packets with > > > TTL=1 and we send out IGMP packets with TTL=1, so we do not > > > decrement TTL". I thought the indented paragraph in section 3. > > > explains this sufficiently. > > > > I have no problem with words to explain that the NAT may also "act as a > > bridge," then. Unless I missed the words in the current draft. > > I'd be very surprised if any NAT used in home gateways would do that. I agree. I didn't understand that part either. What deployment model is suggested there? Rodney > > > As a matter of fact, if the NAT is a 1:1 NAT, I see no reason why it > > can't also relay IGMP messages in IGMPv3 just as it is allowed to do in > > IGMPv2. In IGMPv3, there is the group-and-source-specific query that > > should prevent the NAT from "blackholing." > > Problem is if the upstream router wants to support explicit tracking > for immediate channel changing, then it would require to really > have the NAT be compliant to an IGMPv3 reporter that represents the > aggregate joined state of multiple STBs. > > Cheers > Toerless > > > _______________________________________________ > 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 Jul 10 12:11: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 1I8IIq-0000S4-3S; Tue, 10 Jul 2007 12:11:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8IIo-0000Oq-QF for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 12:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8IIo-0000Oh-Gd for behave@ietf.org; Tue, 10 Jul 2007 12:11:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8IIo-0001Js-9B for behave@ietf.org; Tue, 10 Jul 2007 12:11:02 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Jul 2007 09:11:01 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADdMk0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,523,1175497200"; d="scan'208"; a="179613537:sNHT26455599" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6AGB1bt015682; Tue, 10 Jul 2007 09:11:01 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6AGAwka024984; Tue, 10 Jul 2007 16:10:58 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA24577; Tue, 10 Jul 2007 09:10:09 -0700 (PDT) Date: Tue, 10 Jul 2007 09:10:09 -0700 From: "'Toerless Eckert'" To: Bharat Joshi Message-ID: <20070710091009.F13897@cisco.com> References: <20070709174217.B13897@cisco.com> <20070710084231.D13897@cisco.com> <31D55C4D55BEED48A4459EB64567589A092A6B8660@BLRKECMBX02.ad.infosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <31D55C4D55BEED48A4459EB64567589A092A6B8660@BLRKECMBX02.ad.infosys.com>; from bharat_joshi@infosys.com on Tue, Jul 10, 2007 at 09:22:54PM +0530 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=985; t=1184083861; x=1184947861; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20=22'Toerless=20Eckert'=22=20 |Subject:=20Re=3A=20multicast-08 |Sender:=20; bh=EUluC6LIq03GgbAN5XJURkAQxUg/ZyKNhgIzzMAY0eA=; b=WP3sRjGOHBx9WqYtTS0e6FoI1UxayLihPuFNGqhrsHcSc2nC8AwkjrJc+eXDHysY+oQrCps8 CnqR+Yr9uWbB983rjzs9oKcTBD11iMIf0a2JFaE/7S6LgTct1Tl/zRlV; Authentication-Results: sj-dkim-3; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "'Manfredi, Albert E'" , 'Brian Haberman' , "'behave@ietf.org'" , 'Jean-Jacques Pansiot' , "'Leymann, Nicolai'" , "'Alvaro@soportemv.com'" , 'Marshall Eubanks' , "'prashantj@huawei.com'" , 'Dan Wing' Subject: [BEHAVE] Re: multicast-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tue, Jul 10, 2007 at 09:22:54PM +0530, Bharat Joshi wrote: > > Problem is if the upstream router wants to support explicit tracking > > for immediate channel changing, then it would require to really > > have the NAT be compliant to an IGMPv3 reporter that represents the > > aggregate joined state of multiple STBs. > > > > Will it not be the same for IGMPv2 as well? You can not do explicit tracking in IGMPv2 without making implicit assumptions and in addition the reports in IGMPv2, so, unless you do those non-standards-compliant assumptions you're fine. In addition, i think it's also a question of whether or not you could see on the upstream router behavior of the NAT that would be incompliant to the IGMP reporter side, and because IGMPv2 reports are more atomic i think you would be able to do so with IGMPv2 when using such a shortcut, but you would in IGMPv3. I thought this was all written out in the draft appropriately. Cheers Toerless _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 12:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ILa-0005ho-HC; Tue, 10 Jul 2007 12:13:54 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8ILZ-0005hj-CX for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 12:13:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ILZ-0005hb-2Y for behave@ietf.org; Tue, 10 Jul 2007 12:13:53 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ILY-0001NV-SU for behave@ietf.org; Tue, 10 Jul 2007 12:13:53 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6AGDMf7029926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Jul 2007 09:13:22 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6AGDLgq003192; Tue, 10 Jul 2007 09:13:21 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6AGDKL9003153; Tue, 10 Jul 2007 09:13:20 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 12:13:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Re: multicast-08 Date: Tue, 10 Jul 2007 12:13:19 -0400 Message-ID: In-Reply-To: <20070710155849.GA17066@rtp-cse-489.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: multicast-08 Thread-Index: AcfDC1FB9CyQJIB2TgW0boE80PQMRwAAFnuA References: <20070709174217.B13897@cisco.com> <20070710084231.D13897@cisco.com> <20070710155849.GA17066@rtp-cse-489.cisco.com> From: "Manfredi, Albert E" To: "Rodney Dunn" , "Toerless Eckert" X-OriginalArrivalTime: 10 Jul 2007 16:13:20.0195 (UTC) FILETIME=[3B671130:01C7C30D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Brian Haberman , behave@ietf.org, Bharat Joshi , Jean-Jacques Pansiot , "Leymann, Nicolai" , Alvaro@soportemv.com, Marshall Eubanks , prashantj@huawei.com, 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 > -----Original Message----- > From: Rodney Dunn [mailto:rodunn@cisco.com]=20 > On Tue, Jul 10, 2007 at 08:42:31AM -0700, Toerless Eckert wrote: > > On Tue, Jul 10, 2007 at 09:58:10AM -0400, Manfredi, Albert E wrote: > > > I have no problem with words to explain that the NAT may=20 > also "act as a > > > bridge," then. Unless I missed the words in the current draft. > >=20 > > I'd be very surprised if any NAT used in home gateways=20 > would do that. >=20 > I agree. I didn't understand that part either.=20 > What deployment model is suggested there? Not the IPTV model. Consider transferring, for example, navigation data to hosts behind a 1:1 NAT firewall. You want to keep that firewall as dumb as possible, its designers concerned primarily with implementing an acceptable set of packet filters. IGMP aggregation is not an issue here. Best for the multicast router outside the NAT to behave just as it would if there were no NAT involved. The firewall's filters would probably be identical whether unicast or multicasts are transitting. In this case, it would be best to keep the details of IP multicast routing from impacting this firewall design.=20 Bert _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 12:34: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 1I8IfS-0001TE-WF; Tue, 10 Jul 2007 12:34:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8IfR-0001T9-V3 for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 12:34:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8IfR-0001T0-LR for behave@ietf.org; Tue, 10 Jul 2007 12:34:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8IfR-0001yR-9U for behave@ietf.org; Tue, 10 Jul 2007 12:34:25 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2007 09:33:49 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABBSk0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,523,1175497200"; d="scan'208"; a="384677300:sNHT83330133502" 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 l6AGXkoT030524; Tue, 10 Jul 2007 09:33:46 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6AGXkmo006605; Tue, 10 Jul 2007 16:33:46 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA27687; Tue, 10 Jul 2007 09:32:56 -0700 (PDT) Date: Tue, 10 Jul 2007 09:32:56 -0700 From: Toerless Eckert To: "Manfredi, Albert E" Subject: Re: [BEHAVE] Re: multicast-08 Message-ID: <20070710093256.G13897@cisco.com> References: <20070709174217.B13897@cisco.com> <20070710084231.D13897@cisco.com> <20070710155849.GA17066@rtp-cse-489.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from albert.e.manfredi@boeing.com on Tue, Jul 10, 2007 at 12:13:19PM -0400 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2944; t=1184085226; x=1184949226; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20Toerless=20Eckert=20 |Subject:=20Re=3A=20[BEHAVE]=20Re=3A=20multicast-08 |Sender:=20; bh=NP39bA36oTCu17UMaOAuaBgT3F6KX2elhHWQnD3B7dQ=; b=EZ06AiZI1BV0LNH6/1Nmyoaq2IgFaGZm1uIC5tqtf8tqK4qqj1cbroSw7/bSR9XW07o3lpGe h62/7yO1wn6+fbRC/zXoAuCSAS9Bt/MSYylZfgmv53CBjvHOIihX9ZzM; Authentication-Results: sj-dkim-3; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Brian Haberman , behave@ietf.org, Bharat Joshi , Jean-Jacques Pansiot , "Leymann, Nicolai" , Alvaro@soportemv.com, Marshall Eubanks , prashantj@huawei.com, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tue, Jul 10, 2007 at 12:13:19PM -0400, Manfredi, Albert E wrote: > > -----Original Message----- > > From: Rodney Dunn [mailto:rodunn@cisco.com] > > > I agree. I didn't understand that part either. > > What deployment model is suggested there? > > Not the IPTV model. > > Consider transferring, for example, navigation data to hosts behind a > 1:1 NAT firewall. You want to keep that firewall as dumb as possible, > its designers concerned primarily with implementing an acceptable set of > packet filters. > > IGMP aggregation is not an issue here. Best for the multicast router > outside the NAT to behave just as it would if there were no NAT > involved. The firewall's filters would probably be identical whether > unicast or multicasts are transitting. In this case, it would be best to > keep the details of IP multicast routing from impacting this firewall > design. I think i will fail to provide a short reply here, sorry ;-)) In my experience there are lots of other usage cases for NAT with multicast, and i have been trying to understand what scope we intend to have for the draft. Best i could come up with was to make it specific to IGMP proxy-routing, but exclude PIM for example. The second limitation is - and that's as well explicitly shown in the drafts picture, is that you have really NAT between the IGMP proxy-routing and the upstream interface. The key thing with the upstream interface is that it's not directly connected to hosts but with a router behind it. Now if i look into generic cases where i would have static manually configured 1:1 NATing, then this would often typically include connecting of eg: multiple LANs with sources and receivers, and that's the case that can not represented by the NAT box model used in the draft but would rather be a picture where you had NAT between multiple different downstream interfaces in the IGMP proxying device. The case which i think you are describing could be within scope, but i would like to resist to even further differentiate the conditions under which you could hack in a shortcut IGMP proxying implementation for such cases i would consider to be borderline for the scope of this draft (and as said above: i don't think your case is borderline, i just think it is borderline within the scope of the draft). We have already in the draft geven more leeway to hint at simplification possible with IGMPv2 than the actual IGMP proxy routing RFC, and quite frankly i consider all such shortcuts to be unnecessary and dangerous. The problem i explained with explicit tracking is also only something that we understood _only_ when some years back we first implemented this stuff, and quite frankly i am not sure that we should feel save to say that we have excluded all possible problems that might happen when using a shortcut - especially not with a protocl like IGMPv3. Cheers Toerless _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 16:30: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 1I8MLP-00055D-Nh; Tue, 10 Jul 2007 16:29:59 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8MLO-00054c-SS for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 16:29:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8MLO-00052Q-DA for behave@ietf.org; Tue, 10 Jul 2007 16:29:58 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8MLO-0004c1-0k for behave@ietf.org; Tue, 10 Jul 2007 16:29:58 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I8MLE-0008Ri-1S; Tue, 10 Jul 2007 16:29:49 -0400 In-Reply-To: <46929E54.50301@cisco.com> References: <46929E54.50301@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <384D0E59-4B9B-47EE-AA90-5A7DF9A53550@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] RFC3489bis-07 now available Date: Tue, 10 Jul 2007 16:30:17 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I think it is worthwhile talking a bit more about the organizational changes. The document now has a section (section 7) called "Basic Protocol Procedures" which defines all the basic rules for STUN message formation and processing. This section also defines the Binding method, which is the only method now defined in 3489bis. After this comes a bunch of sections that define optional "mechanisms". Each mechanism represents an extension to STUN that a usage can elect to use or not use as it sees fit. The mechanisms defined so far include: * The FINGERPRINT mechanism * DNS Discovery of a STUN Server * The two authentication and message-integrity mechanisms * The ALTERNATE-SERVER mechanism * Backward compatibility with RFC 3489. TURN is also envisioned as such a mechanism. So, for example, ICE chooses to use the FINGERPRINT mechanism, but SIP-Outbound might not. As Jonathan said, there were lots of other more minor changes made, most of them as a result of the WGLC comments. - Philip On 9-Jul-07, at 16:45 , Jonathan Rosenberg wrote: > RFC3489bis-07 is now available: > http://www.ietf.org/internet-drafts/draft-ietf-behave- > rfc3489bis-07.txt > > Firstly, I'd like to thank Philip Matthews and Dan Wing for taking > up much of the editing and administrative tasks required in > incorporating the huge number of comments that were made during the > previous WGLC. Philip has been added as a co-author for his work on > this document. > > We *think* we captured all of the comments, both nits and more > substantive issues, raised during WGLC. > > There are lots of changes in this draft, most of them around > structure, organization and terminology. On-the-wire only a little > has changed. A big part of the changes were an attempt to simplify > a document which really seemed too long for a protocol that > actually does very little. We eliminated 15 pages, going from 61 in > bis-06 to 46 here. > > Changes to note are: > > * completely redefined what a usage is. THis was the source of a > lot of fluff in the text. Now, a usage is just a protocol that > makes use of STUN for nat traversal. ICE is a usage. So is sip- > outbound. THere are no longer formal requirements for definition of > a usage; the usage just says how to use STUN, which these drafts > already do. STUN can have extensions - these are new attributes, > methods, and error codes. ICE uses STUN and also defines a few > extensions. > > * security considerations is pared down; really the job of defining > security lies with the usage. STUN by itself has security problems, > but when used with ICE they are mitigated. Since we are not ever > recommending stun by itself, no need to treat security of a pure > stun system > > * removed IAB consideartions - per above this is ICE's job now > > * removed shared secret request and response. This is just way too > complex. It had already been relegated to a usage. Now its gone. > THe main driving need has evaporated with ICE. > > * simplified the authentication sections, splitting them out into > two separte subsections which clearly explain how short term works > and how long term works. We no longer support dynamically switching > from one to the other. Rather a usage states which one is used. > > * removal of several error codes that could only happen in > implementation errors. > > * split IANA registry for attributes and methods into one that is > done by IETF, and a vendor first-come first-served space > > * defined length limits on all free-form fields > > > Dan or Philip - others you'd like to add? > > -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 Tue Jul 10 16:51: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 1I8MgK-0006zU-AB; Tue, 10 Jul 2007 16:51:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8Mg9-0006oj-VI for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 16:51:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8MGB-0003ag-DM for behave@ietf.org; Tue, 10 Jul 2007 16:24:35 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8MCK-0001q4-Om for behave@ietf.org; Tue, 10 Jul 2007 16:20:45 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I8MBI-0006mb-1S; Tue, 10 Jul 2007 16:19:32 -0400 In-Reply-To: <46929F98.5020706@acm.org> References: <46929F98.5020706@acm.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D0B500E-9A68-4BE0-9FF6-D69EE25709EB@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt Date: Tue, 10 Jul 2007 16:20:02 -0400 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 9-Jul-07, at 16:50 , Marc Petit-Huguenin wrote: > I read the new draft, and I am happy with the improvements. > > All nine comments in my review are fixed one way or another in this > draft. Many thanks to do not remove the 300 error code. > > Some comments: > > 1. Section 13: The second paragraph lists ICE, Outbound and NAT > Behavior > discovery as STUN usages. Shouldn't STUN relay be added to this list? First of all, we are proposing to change the name of "STUN relay" back to TURN. Cullen was the person who pushed for this, but in my opinion, this change just reflects reality -- everyone I know uses the terms "STUN" and "TURN", not "STUN" and "STUN-relay". The latest version of the TURN spec, which should appear in the archives shortly, will reflect this. I would be interested in hearing what the WG feels about this change. But to address the main question, we are proposing to view TURN as another extension to STUN, not a usage. That is, you don't run TURN by itself, but as a part of a larger usage, like ICE. TURN by itself, also has some security problems, but with ICE a lot of them go away. > > 2. Section 13: On the list of definitions that an usage should > provide, > it should be specified if a new method is idempotent (see section > 7.3.1) One of my personal goals for -07 was to try to not say the same thing twice in two different locations. Since 7.3.1 says that any new method must define this, perhaps this is sufficient? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 17:21:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8N9K-0004l5-4D; Tue, 10 Jul 2007 17:21:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8N9H-0004RA-R9 for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 17:21:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8N9H-0004K8-8G for behave@ietf.org; Tue, 10 Jul 2007 17:21:31 -0400 Received: from www.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8N8y-0006ad-NI for behave@ietf.org; Tue, 10 Jul 2007 17:21:31 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 19F5B3A02022; Tue, 10 Jul 2007 14:20:58 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 3AA953A02020; Tue, 10 Jul 2007 14:20:55 -0700 (PDT) Message-ID: <4693F836.9020502@acm.org> Date: Tue, 10 Jul 2007 14:20:54 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt References: <46929F98.5020706@acm.org> <8D0B500E-9A68-4BE0-9FF6-D69EE25709EB@magma.ca> In-Reply-To: <8D0B500E-9A68-4BE0-9FF6-D69EE25709EB@magma.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Philip Matthews wrote: > > On 9-Jul-07, at 16:50 , Marc Petit-Huguenin wrote: > >> I read the new draft, and I am happy with the improvements. >> >> All nine comments in my review are fixed one way or another in this >> draft. Many thanks to do not remove the 300 error code. >> >> Some comments: >> >> 1. Section 13: The second paragraph lists ICE, Outbound and NAT Behavior >> discovery as STUN usages. Shouldn't STUN relay be added to this list? > > First of all, we are proposing to change the name of "STUN relay" back > to TURN. > Cullen was the person who pushed for this, but in my opinion, this > change just > reflects reality -- everyone I know uses the terms "STUN" and "TURN", > not "STUN" > and "STUN-relay". I do but you are right, you do not know me. > The latest version of the TURN spec, which should > appear in > the archives shortly, will reflect this. I would be interested in > hearing what > the WG feels about this change. I think that "STUN relay" correctly describes what is in the spec, but there could be worst names than TURN. "router" for example. > > But to address the main question, we are proposing to view TURN as another > extension to STUN, not a usage. That is, you don't run TURN by itself, > but as a part of a larger usage, like ICE. In this case why do not merge STUN relay in the ICE spec? > > TURN by itself, also has some security problems, but with ICE a lot of > them go away. > > > >> >> 2. Section 13: On the list of definitions that an usage should provide, >> it should be specified if a new method is idempotent (see section 7.3.1) > > One of my personal goals for -07 was to try to not say the same thing > twice in two different locations. Since 7.3.1 says that any new method > must define this, perhaps this is sufficient? I understand, but in this case you should make the following modifications: Section 12: Remove "A usage must define if and when this procedure is used", because this is already in section 13 ("Whether backwards compatibility to RFC 3489 is required;") Section 9: Remove "A STUN usage must describe if and when this extension is used." because this is already in section 13 ("How a STUN client determines the IP address and port of the STUN server;") Section 10: Remove "... and each usage must specify if and when these mechanisms are used." because this is already in section 13 ("What authentication and message integrity mechanisms are used;") -- 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 Jul 10 20:44:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8QJI-0004qS-6f; Tue, 10 Jul 2007 20:44:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8QJH-0004od-CD for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 20:44:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8QJH-0004mv-1A for behave@ietf.org; Tue, 10 Jul 2007 20:44:03 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8QJC-0000RG-No for behave@ietf.org; Tue, 10 Jul 2007 20:44:03 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1I8QJC-0000xk-Kj; Tue, 10 Jul 2007 20:43:58 -0400 In-Reply-To: <4693F836.9020502@acm.org> References: <46929F98.5020706@acm.org> <8D0B500E-9A68-4BE0-9FF6-D69EE25709EB@magma.ca> <4693F836.9020502@acm.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74B6BF02-61AD-4E31-BFA4-C49F42D62427@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt Date: Tue, 10 Jul 2007 20:44:28 -0400 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 10-Jul-07, at 17:20 , Marc Petit-Huguenin wrote: > Philip Matthews wrote: >> >> But to address the main question, we are proposing to view TURN as >> another >> extension to STUN, not a usage. That is, you don't run TURN by >> itself, >> but as a part of a larger usage, like ICE. > > In this case why do not merge STUN relay in the ICE spec? This could be done. However: 1) The ICE spec is already pretty large, and 2) There is a chance that some usage other than ICE might use TURN (though I don't know what it would be right now). Also, ICE is an MMUSIC work item, while TURN is a BEHAVE work item. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 22:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8RYC-0007t6-Rm; Tue, 10 Jul 2007 22:03:32 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8RYB-0007sy-94 for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 22:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8RYA-0007sq-VZ for behave@ietf.org; Tue, 10 Jul 2007 22:03:30 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8RY3-0001lH-J0 for behave@ietf.org; Tue, 10 Jul 2007 22:03:30 -0400 Received: from lappy ([68.26.107.45]) by quinthar.com for ; Tue, 10 Jul 2007 19:03:14 -0700 From: "David Barrett" To: "'Philip Matthews'" , "'Marc Petit-Huguenin'" Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt Date: Tue, 10 Jul 2007 19:03:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfDVJ4Sq8+VghEnTsGnkkn+oFSh7wACd5JQ In-Reply-To: <74B6BF02-61AD-4E31-BFA4-C49F42D62427@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Message-Id: Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt > > On 10-Jul-07, at 17:20 , Marc Petit-Huguenin wrote: > > > Philip Matthews wrote: > >> > >> But to address the main question, we are proposing to view TURN as > >> another > >> extension to STUN, not a usage. That is, you don't run TURN by > >> itself, > >> but as a part of a larger usage, like ICE. > > > > In this case why do not merge STUN relay in the ICE spec? > > This could be done. However: > 1) The ICE spec is already pretty large, and > 2) There is a chance that some usage other than ICE might use TURN > (though I don't know what it would be right now). > Also, ICE is an MMUSIC work item, while TURN is a BEHAVE work item. I totally support the notion of focusing STUN/TURN on the requirements if their actual "customers" (etc, ICE). But are you proposing that there will be no such thing as an official "STUN server" that exists outside of ICE? For example, there's no such thing as a standalone "RTP server" that exists outside of some broader media streaming system. Are you proposing that similarly, there will be no standalone STUN server, but instead just clients and servers that happen to use the STUN protocol as one of many? I've got no strong opinion on the matter (though it actually sounds like a nice way to clarify and constrain scope, which I'm always a fan of); I just want to clarify the proposal. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 10 22:44:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8SCC-0003Nx-Ss; Tue, 10 Jul 2007 22:44:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8SCC-0003N5-Co for behave-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 22:44:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8SCC-0003Ke-1U for behave@ietf.org; Tue, 10 Jul 2007 22:44:52 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8SC7-0002b9-O6 for behave@ietf.org; Tue, 10 Jul 2007 22:44:52 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Jul 2007 19:44:47 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJLgk0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,524,1175497200"; d="scan'208"; a="7802068:sNHT14263164" 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 l6B2ilNC003026; Tue, 10 Jul 2007 19:44:47 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6B2iimo017825; Wed, 11 Jul 2007 02:44:44 GMT From: "Dan Wing" To: "'Philip Matthews'" , "'Marc Petit-Huguenin'" Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt Date: Tue, 10 Jul 2007 19:44:44 -0700 Message-ID: <070001c7c365$71c927b0$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: <74B6BF02-61AD-4E31-BFA4-C49F42D62427@magma.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfDVJ/bKnT3uV41QKyZWC/QhYV9qwAEEagw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=826; t=1184121887; x=1184985887; 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-07.txt |Sender:=20; bh=63swk/SSZRJrmxjzLV5EqFc4NGUMkwaNoOVD84EpeIw=; b=jQjpDU2BxXJqK8rVdPTAm88n90e2HKV4m3DVIQAcUJJLZsO4jTCyzNHxM69cpA8InMQCrkrX ObkFUEN94x0w9ZIgjFE1CWIaMVXxOf1tUBGqFynnG1Rza50s1KbFM/Rj; 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: 79899194edc4f33a41f49410777972f8 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > In this case why do not merge STUN relay in the ICE spec? > > This could be done. However: > 1) The ICE spec is already pretty large, and > 2) There is a chance that some usage other than ICE might use TURN > (though I don't know what it would be right now). HIP, MIP, or NUTSS, perchance, none of which will use ICE completely as-is (HIP and MIP are very unlikely to use ICE's SDP encoding; NUTSS might if NUTSS sticks with SIP signaling). But all of them could benefit from a UDP relay. I don't know of such a beast, defacto standard or not, except TURN. > Also, ICE is an MMUSIC work item, while TURN is a BEHAVE work item. That becomes moot when they are RFCs and their genesis in separate working groups is lost (except perhaps the brief mention on the banner on the first page). -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 11 02:12: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 1I8VRF-0004gX-2L; Wed, 11 Jul 2007 02:12:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8VRD-0004gS-Kz for behave-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 02:12:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8VRD-0004gK-8y for behave@ietf.org; Wed, 11 Jul 2007 02:12:35 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8VQx-0007IZ-Ra for behave@ietf.org; Wed, 11 Jul 2007 02:12:35 -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 l6B6Bs6v024221 for ; Wed, 11 Jul 2007 09:12:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:12:00 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:12:00 +0300 Received: from hed050122.research.nokia.com ([172.21.50.122]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:12:00 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt Date: Wed, 11 Jul 2007 09:11:56 +0300 User-Agent: KMail/1.9.6 References: <070001c7c365$71c927b0$c3f0200a@amer.cisco.com> In-Reply-To: <070001c7c365$71c927b0$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707110911.56334.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Jul 2007 06:12:00.0175 (UTC) FILETIME=[6472ABF0:01C7C382] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Wednesday 11 July 2007 05:44:44 ext Dan Wing wrote: > But all of them could > benefit from a UDP relay. I don't know of such a beast, defacto > standard or not, except TURN. Actually, SOCKS5 (which I recall as a IETF standard track protocol) does=20 support UDP relaying, including with authentication. However, it does not=20 currently support SIP credentials, and TCP->UDP relaying, nor TLS->(UDP|TCP= ).=20 Also it needs some framing for each UDP packets (i.e. no active destination= ). =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 11 06:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ZQ1-0000EP-1H; Wed, 11 Jul 2007 06:27:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8ZQ0-0000EJ-D0 for behave-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 06:27:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ZPw-0000DQ-M7 for behave@ietf.org; Wed, 11 Jul 2007 06:27:32 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8ZPh-0004GW-Co for behave@ietf.org; Wed, 11 Jul 2007 06:27:32 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1I8ZPA-0001ST-MU; Wed, 11 Jul 2007 06:26:45 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <963FEA7D-7C72-47FF-851D-9302338BC922@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt Date: Wed, 11 Jul 2007 06:27:15 -0400 To: "David Barrett" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] 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: , Errors-To: behave-bounces@ietf.org On 10-Jul-07, at 22:03 , David Barrett wrote: > > I totally support the notion of focusing STUN/TURN on the > requirements if > their actual "customers" (etc, ICE). But are you proposing that > there will > be no such thing as an official "STUN server" that exists outside > of ICE? > > For example, there's no such thing as a standalone "RTP server" > that exists > outside of some broader media streaming system. Are you proposing > that > similarly, there will be no standalone STUN server, but instead > just clients > and servers that happen to use the STUN protocol as one of many? > > I've got no strong opinion on the matter (though it actually sounds > like a > nice way to clarify and constrain scope, which I'm always a fan > of); I just > want to clarify the proposal. STUN by itself does not work very well, because there is no way for a client to tell when it should use the reflexive address learned. It also has some poor security properties, because there is no way to protect or confirm the reflexive address learned. So our idea is: STUN is now a tool. You use it in some usage, and as part of that usage, you describe how you are going to fix all the problems with STUN. ICE is one such usage - it fixes the problems using authenticated connectivity checks. Outbound is another such usage - it avoids the problems because it does not use reflexive addresses. Other usages might also be defined. This doesn't mean that there will not be public STUN servers that applications can use. It just means that a robust application should be aware of the limitations of STUN and have a way to work around them. Did this answer your question? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 11 12:15: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 1I8eqU-0000F9-0j; Wed, 11 Jul 2007 12:15:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8eqF-0008Mu-ER for behave-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 12:15:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8eqE-0008MW-NN; Wed, 11 Jul 2007 12:15:02 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8eqE-0004jy-Fu; Wed, 11 Jul 2007 12:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 3650C1761B; Wed, 11 Jul 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8eqD-0005oP-PK; Wed, 11 Jul 2007 12:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 12:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-nat-behavior-discovery-01.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 Behavior Discovery Using STUN Author(s) : D. MacDonald, B. Lowekamp Filename : draft-ietf-behave-nat-behavior-discovery-01.txt Pages : 24 Date : 2007-7-11 This specification defines a usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-01.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-behavior-discovery-01.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-behavior-discovery-01.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-7-11111604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-nat-behavior-discovery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-nat-behavior-discovery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11111604.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 Jul 12 07:45: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 1I8x7A-0006V9-3D; Thu, 12 Jul 2007 07:45:44 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I8x79-0006V3-7e for behave-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 07:45:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8x78-0006Uv-SV for behave@ietf.org; Thu, 12 Jul 2007 07:45:42 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8x6t-000779-Bi for behave@ietf.org; Thu, 12 Jul 2007 07:45:42 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 09AEE2177D; Thu, 12 Jul 2007 13:44:08 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-83-469614076f82 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D034D21779; Thu, 12 Jul 2007 13:44:07 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 13:44:03 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 13:44:02 +0200 Message-ID: <46961402.2070202@ericsson.com> Date: Thu, 12 Jul 2007 13:44:02 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Behave WG , Jonathan Rosenberg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 11:44:02.0730 (UTC) FILETIME=[F1A110A0:01C7C479] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [BEHAVE] Comments on draft-ietf-behave-rfc3489bis-07 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 have reviewed the draft and have couple of comments. Mostly minor nits, but there are a few that I would like to have answers on. But otherwise I think the draft is quite easy to read. 1. Section 7.2.1: I wonder if there shouldn't be a recommended minimal RTO time. I think 100 ms is small enough for all implementations. Configuring anything smaller seems to me to be inviting a to big risk to miss any replies because the total time waited until failure is declared is well within the time it could take for a request to traverse some path if the client is misstaking what paths it actually is on. 2. Section 7.2.2: I think there is some unclarity in regards to which event one starts ones failure timer when using TCP. Please remember that if it is the SYN that are lost in the connectivity establishment process then there will be only a one retransmission every 3 seconds. Thus during the 7.9 seconds there will be only 2 retransmissions. If one counts from succesful connectivity establishment one needs some timeout also for the connectivity step. In general TCP will manage fewer retransmissions than UDP with a RTO of 100 ms. 3. Section 10.2.1.1: I think it is unclear how the server is going to know that longterm credentials shall be used. Is there an assumption here that any STUN server using long-term credentials will use them for all requests? If that is the case that should be mentioned. 4. Does STUN work with deploying servers with anycast addresses? If no, then maybe it needs to be documented? 5. Section 15: I think it might be worth to mention that an attacker can use a STUN server to bounce messages of them towards a target. There are no amplification, but it can be used by an attacker to disperse attacks streams so that they appear to come from many different sources to reduce. But it assumes that they can spoof the source address of the packet reaching the server. Especially for usages when there are no integrity checks the STUN server will have no identity of the attacker. Nits N1. Section 14.4: I think there are two sentences in this paragraph that are in contradiction: "The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute." "Since the hash is computed over the entire STUN message, it includes the length field from the STUN message header." As I see it the problem is the "entire" in the second sentence. N2. Section 15.1.1: An attacker can try to modify STUN messages in transit, in order to cause a failure in STUN operation. These attacks are prevented for both requests and responses through the message integrity mechanism, using either a short term or long term credential. I think this paragraph is correct. You can always cause failure in STUN operation by modifying packets so the integrity fails or simple delete the packet. I think the paragraph needs to be reworded so that it doesn't ignore the fact. As I understand the goal of the paragraph is to say that with message integrity an attacker can't modify the STUN message to have STUN checks shutdown immeditely. N3. Section 15.2.3: "This attack is similar to attack III." I don't think this sentence in inteded to reference the section it self is present in, maybe "II" is the right? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 12 12:17: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 1I91Lp-00070S-Cu; Thu, 12 Jul 2007 12:17:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I91KM-0003mv-47 for behave-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 12:15:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91KJ-0003ll-Qq; Thu, 12 Jul 2007 12:15:36 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I91KJ-0005kc-JA; Thu, 12 Jul 2007 12:15:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 46B98175EC; Thu, 12 Jul 2007 16:15:05 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I91Jo-0003FJ-0Y; Thu, 12 Jul 2007 12:15:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Jul 2007 12:15:04 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --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 : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-04.txt Pages : 40 Date : 2007-7-12 This specification defines an extension of the Session Traversal Utilities for NAT (STUN) Protocol for asking the STUN server to relay packets towards a client. This extension, called Traversal Using Relays around NAT (TURN), 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-04.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-04.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-04.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-7-12110255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12110255.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 Jul 12 22:47:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9BBM-00055U-0G; Thu, 12 Jul 2007 22:47:00 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I9BBK-00055F-Sg for behave-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 22:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9BBK-000555-Iv; Thu, 12 Jul 2007 22:46:58 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9BBF-0006CU-FC; Thu, 12 Jul 2007 22:46:58 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2c4697549a; Fri, 13 Jul 2007 10:58:31 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm104692175c; Mon, 09 Jul 2007 16:57:10 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 09 Jul 2007 16:57:09 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7kPu-0002D4-Tw; Mon, 09 Jul 2007 00:00:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7kPr-0002Ci-2I; Mon, 09 Jul 2007 00:00:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7kPq-000306-Ot; Mon, 09 Jul 2007 00:00:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A417C2AC75; Mon, 9 Jul 2007 04:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7kPq-0002AF-3H; Mon, 09 Jul 2007 00:00:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jul 2007 00:00:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.2 (++) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt X-BeenThere: behave@ietf.org Reply-To: internet-drafts@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 --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-07.txt Pages : 46 Date : 2007-07-08 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-07-08235854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-08235854.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Jul 13 17:51:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9T2i-0002Az-JR; Fri, 13 Jul 2007 17:51:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I9T2g-0002Ae-To for behave-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 17:51:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9T2g-0002AT-HP for behave@ietf.org; Fri, 13 Jul 2007 17:51:14 -0400 Received: from submit01.sysedata.no ([195.159.29.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9T2f-0002Gs-Gc for behave@ietf.org; Fri, 13 Jul 2007 17:51:14 -0400 Received: from [84.215.127.238] (helo=[10.0.0.8]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1I9T1r-0004Tv-M6; Fri, 13 Jul 2007 23:50:23 +0200 Message-ID: <4697F431.7090001@db.org> Date: Fri, 13 Jul 2007 23:52:49 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] RFC3489bis-07 now available References: <46929E54.50301@cisco.com> In-Reply-To: <46929E54.50301@cisco.com> Content-Type: multipart/mixed; boundary="------------090005070500080303070102" X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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 This is a multi-part message in MIME format. --------------090005070500080303070102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Great work guys! It could be added that the REFRESH-INTERVAL attribute is also removed. please see my comments attached /alfred Jonathan Rosenberg wrote: > RFC3489bis-07 is now available: > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt > > Firstly, I'd like to thank Philip Matthews and Dan Wing for taking up > much of the editing and administrative tasks required in incorporating > the huge number of comments that were made during the previous WGLC. > Philip has been added as a co-author for his work on this document. > > We *think* we captured all of the comments, both nits and more > substantive issues, raised during WGLC. > > There are lots of changes in this draft, most of them around structure, > organization and terminology. On-the-wire only a little has changed. A > big part of the changes were an attempt to simplify a document which > really seemed too long for a protocol that actually does very little. We > eliminated 15 pages, going from 61 in bis-06 to 46 here. > > Changes to note are: > > * completely redefined what a usage is. THis was the source of a lot of > fluff in the text. Now, a usage is just a protocol that makes use of > STUN for nat traversal. ICE is a usage. So is sip-outbound. THere are no > longer formal requirements for definition of a usage; the usage just > says how to use STUN, which these drafts already do. STUN can have > extensions - these are new attributes, methods, and error codes. ICE > uses STUN and also defines a few extensions. > > * security considerations is pared down; really the job of defining > security lies with the usage. STUN by itself has security problems, but > when used with ICE they are mitigated. Since we are not ever > recommending stun by itself, no need to treat security of a pure stun > system > > * removed IAB consideartions - per above this is ICE's job now > > * removed shared secret request and response. This is just way too > complex. It had already been relegated to a usage. Now its gone. THe > main driving need has evaporated with ICE. > > * simplified the authentication sections, splitting them out into two > separte subsections which clearly explain how short term works and how > long term works. We no longer support dynamically switching from one to > the other. Rather a usage states which one is used. > > * removal of several error codes that could only happen in > implementation errors. > > * split IANA registry for attributes and methods into one that is done > by IETF, and a vendor first-come first-served space > > * defined length limits on all free-form fields > > > Dan or Philip - others you'd like to add? > > -Jonathan R. > --------------090005070500080303070102 Content-Type: text/plain; name="comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="comments.txt" Comments on draft-ietf-behave-rfc3489bis-07 by Alfred E. Heggestad 13. July 2007 > Section 1 > > authentication mechanism is to be used. Interactive Connectivity > Establishment (ICE) [I-D.ietf-mmusic-ice] is one usage of ICE. SIP ^^^^^^^^^^^^ should be "usage of STUN" ? > Outbound [I-D.ietf-sip-outbound] is another usage of ICE. In some ^^^^^^^^^^^^ should be "usage of STUN"? I guess outbound is not a usage of ICE .. > Section 6. 8th paragraph: > > The magic cookie field MUST contain the fixed value 0x2112A442 in > network byte order. In RFC 3489 [RFC3489], this field was part of... > > and Section 14.2 > > For example, using the "^" character to indicate exclusive or, if the > IP address is 192.168.1.1 (0xc0a80101) and the port is 5555 (0x15B3), > the X-Port would be 0x15B3 ^ 0x2112 = 0x34A1, and the X-Address would > be 0xc0a80101 ^ 0x2112A442 = 0xe1baa543. > I am still confused with the endianess of the magic cookie. I have always believed that any numeric values in the spec are in host order, and encoded to network byte order when put on the wire. Consider the following C code to encode a STUN header and send the buffer on the wire: #define STUN_MAGIC_COOKIE 0x2112A442 uint32_t hdr[5], *p = hdr; *p++ = /* STUN Type and Length */ *p++ = htonl(STUN_MAGIC_COOKIE); Here is magic cookie is converted from host order to network byte order. Is this wrong? > Section 10.1.2 > > * If the message is a request, the server MUST reject the request > with an error response. This response MUST use an error code > of 431. the 431 error code was deleted in -07. Either we must use a different error code here, or put back the definition of 431. some deleted error codes are referenced by turn-04: "Response with an appropriate error response code, such as a 431 (Integrity Failure) or 436 (Unknown User)." NITS: > Section 6. 4th paragraph > > a response message), and indication transactions (which consists a > single indication message). Response classes are split into error add "of" between "consists" and "a" -> "...(which consists of a single..." ^^ > Section 6. 6th paragraph > > method, Binding. The method and class are orthogonal, so that four > each method, a request, success response, error response and ^^^^ -> should be "for" > Section 7.2.1 > > the 3s recommended in RFC 2988). In fixed- line access links, a ^^^^^^^^^^^ could be "fixed-line" --------------090005070500080303070102 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 --------------090005070500080303070102-- From behave-bounces@ietf.org Sun Jul 15 10:49: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 1IA5PD-00084F-Kq; Sun, 15 Jul 2007 10:49:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IA5PB-000844-PV for behave-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 10:49:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5PB-00083t-Cd for behave@ietf.org; Sun, 15 Jul 2007 10:49:01 -0400 Received: from submit01.sysedata.no ([195.159.29.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA5P7-0004uw-JT for behave@ietf.org; Sun, 15 Jul 2007 10:49:01 -0400 Received: from [84.215.127.238] (helo=[10.0.0.8]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1IA5P3-0005LI-Kl; Sun, 15 Jul 2007 16:48:53 +0200 Message-ID: <469A346C.6020306@db.org> Date: Sun, 15 Jul 2007 16:51:24 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: derek@counterpath.com, lowekamp@sipeerior.com, 'Behave WG' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Subject: [BEHAVE] Comments on draft-ietf-behave-nat-behavior-discovery-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Comments on draft-ietf-behave-nat-behavior-discovery-01 by Alfred E. Heggestad 15. July 2007 > Section 2 > > reasonable supernode candidate, meaning that its NAT(s) offer(s) > Address Independent Filtering. It might periodically re-run tests > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ There is no such things as "Address Independent Filtering". See RFC 4787 for the definitions. What you probably mean here is "Endpoint Independent" filtering > Section 3.6. Detecting Generic ALGs > I am glad to see this test added. It should be noted wether this test is applicable to UDP, TCP, TLS over TCP. > Section 4.3. Determining NAT Filtering Behavior > > a response the current behaviour of the NAT is Address Independent > Filtering. ^^^^^^^^^^^^^^^^^^^ > same as above > Section 5. Client Behavior > > OPEN ISSUE: is 430 the best approach to this (which should force the > client to get a new shared secret and retry the transaction) or > should a new return-type be used. Also, if shared secret is not > required, it's not at all appropriate. FYI, error code 430 is removed from rfc3489bis-07 > Section 7 > > 0x0003: CHANGE-REQUEST > 0x0004: SOURCE-ADDRESS > 0x0005: OTHER-ADDRESS > 0x0023: XOR-REFLECTED-FROM > 0x0027: XOR-RESPONSE-ADDRESS > 0x8026: PADDING > 0x8027: CACHE-TIMEOUT > > Section 9 > > 0x0003: CHANGE-REQUEST > 0x0004: SOURCE-ADDRESS > 0x0005: OTHER-ADDRESS > 0x0023: XOR-REFLECTED-FROM > 0x0027: XOR-RESPONSE-ADDRESS > 0x0026: PADDING > 0x8026: CACHE-TIMEOUT The values of PADDING and CACHE-TIMEOUT does not match _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 16 13:16:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUBT-0001OO-Ht; Mon, 16 Jul 2007 13:16:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAF4g-00052q-Qo for behave-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 21:08:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAF4g-00052i-Fs for behave@ietf.org; Sun, 15 Jul 2007 21:08:30 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAF4R-0006i8-3e for behave@ietf.org; Sun, 15 Jul 2007 21:08:30 -0400 Received: from source ([192.150.11.134]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Sun, 15 Jul 2007 18:07:48 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6G16Tot014528; Sun, 15 Jul 2007 18:06:29 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6G15nI9016566; Sun, 15 Jul 2007 18:05:49 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 18:07:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Re: removing application milestone Date: Sun, 15 Jul 2007 18:07:40 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AA9D5B@namail5.corp.adobe.com> In-Reply-To: <887981.79844.qm@web33309.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: removing application milestone Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4Q References: <887981.79844.qm@web33309.mail.mud.yahoo.com> From: "Henry Sinnreich" To: X-OriginalArrivalTime: 16 Jul 2007 01:07:41.0438 (UTC) FILETIME=[B57541E0:01C7C745] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Mon, 16 Jul 2007 13:16:29 -0400 Cc: henrys@adobe.com, baford@mit.edu, Dan Wing , dank@kegel.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan Wing wrote: >=20 > At the BEHAVE meeting in Prague there was strong consensus to remove=20 > the milestone: "Submit informational that discusses current NAT=20 > traversal techniques used by applications" from our charter, and to not=20 > adopt draft-ford-behave-app to meet that milestone. I must strongly disagree with this proposal for several reasons, besides the fact that majority consensus in a meeting has nothing to do with getting it right. The I-D ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-behave-p2p- state-03.txt has the outstanding value compared to most other proposals, such as the over abundant literature for ICE: * A study based on real networks and the Internet, * The authors have created a tool for testing NAT traversal, * Many contributors have used the tool and reported results, * The results are published, see http://pdos.csail.mit.edu/papers/p2pnat.pdf=20 This outstanding work is not only a model for the BEHAVE WG but also for most other IETF WGs, where concept I-D predominate unfortunately over proposals backed up by published research, running code and published performance. Given that ICE has now gained the status of a creed and maybe I have missed it: Are there any published results on the effectiveness of ICE, such as % of success in various NAT scenarios and call setup delay when used with SIP? I have seen one private report and it does not look that great. At any rate, must be the top BEHAVE WG item. Continuing this work should include identifying and measuring NAT types used by ISPs and also the multi-homed ISP network scenario. Updated test results such as in http://pdos.csail.mit.edu/papers/p2pnat.pdf would also be welcome. Thanks, Henry _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 16 14:44: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 1IAVYd-00029j-Sx; Mon, 16 Jul 2007 14:44:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAVYd-00022S-1J for behave-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 14:44:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVYc-0001yJ-Hy for behave@ietf.org; Mon, 16 Jul 2007 14:44:30 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAVYX-000735-VJ for behave@ietf.org; Mon, 16 Jul 2007 14:44:30 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 16 Jul 2007 11:44:17 -0700 From: "David Barrett" To: "'Henry Sinnreich'" , Subject: RE: [BEHAVE] Re: removing application milestone Date: Mon, 16 Jul 2007 11:44:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNA= In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AA9D5B@namail5.corp.adobe.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Message-Id: Cc: henrys@adobe.com, baford@mit.edu, 'Dan Wing' , dank@kegel.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Subject: RE: [BEHAVE] Re: removing application milestone > > Given that ICE has now gained the status of a creed and maybe I have > missed it: Are there any published results on the effectiveness of ICE, > such as % of success in various NAT scenarios and call setup delay when > used with SIP? > I have seen one private report and it does not look that great. Incidentally, I'm dealing with measuring peer connectivity of my own system (non-ICE), and here are some of the results for various NAT types: Type Count Connectivity Open Time Fullcone 150 (9%) 92% 1056ms Fullstatic 397 (25%) 94% 867ms Fw 68 (4%) 2% 374ms Rstrcone 598 (37%) 89% 706ms Rstrstatic 82 ( 5%) 91% 769ms symmetric 293 (18%) 94% 906ms This is read as "598 tested clients had a restricted cone NAT (making up 37% of all clients tested), with an average peer connectivity success rate of 89%". ("FullStatic" and "Rstrstatic" means a non-NAT'd client with endpoint independent/dependent filtering, respectively; "Fw" means a client that failed our STUN operation and thus might just have UDP blocked altogether; "Open Time" is the time it took to establish the connection and begin sending actual connection data.) fullcone fullstatic fw rstrcone rstrstatic symmetric fullcone 98% 96% 0% 96% 94% 98% fullstatic 97% 97% 5% 97% 90% 98% fw 0% 5% 0% 0% 0% 0% rstrcone 96% 97% 0% 16% 66% 27% rstrstatic 94% 92% 0% 66% 100% symmetric 98% 98% 0% 12% 100% Here are the pairwise peer connectivities. As you can see, this is a pretty small test (only maybe 1000 total clients), an thus not all pairwise scenarios got tested (ie, no rstrstatic:symmetric or symmetric:symmetric tests were attempted). Thus I wouldn't put too much faith in those numbers (especially anything claiming 100%) until I have numbers on a broader scale. For some reason I'm seeing peer connectivity problems at larger scales (average peer connectivity across the board is 90% in the above case, but drops to 40% when tested on 10x the clients), and I'm still ironing them out (there appears to be a problem in my test infrastructure). Basically, I'd love to see some results on ICE in the above format, as that'll let me do an apples-to-apples comparison of it versus mine. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 16 15:05: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 1IAVsz-00041i-Pg; Mon, 16 Jul 2007 15:05:33 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAVsz-00041d-0a for behave-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 15:05:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVsy-00041V-NI for behave@ietf.org; Mon, 16 Jul 2007 15:05:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAVsu-0007gd-BU for behave@ietf.org; Mon, 16 Jul 2007 15:05:32 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2007 12:05:27 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEhem0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,542,1175497200"; d="scan'208"; a="166815598:sNHT29402487" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6GJ5R1F008814; Mon, 16 Jul 2007 12:05:27 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6GJ5M4w025994; Mon, 16 Jul 2007 19:05:22 GMT From: "Dan Wing" To: "'David Barrett'" , "'Henry Sinnreich'" , Subject: RE: [BEHAVE] Re: removing application milestone Date: Mon, 16 Jul 2007 12:05:22 -0700 Message-ID: <02eb01c7c7dc$4568b110$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5v6k68$evumg@sj-inbound-d.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNAAAVY8gA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3683; t=1184612727; x=1185476727; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20removing=20application=20milestone |Sender:=20; bh=qnIDuSh/hGs3ta3Nb/iXeaRofnzXhdoA7v5MfhCNGyI=; b=u8Vd9fevhcb57pqFBXXUsP3DM1XpwEgkSaaWcACfteQe0BeORzpNyBJuyHE7o76WGjOaxH/B gslSkXhHTlVZbx6mTcDI2mBuGCZ3FuaPFQ5KFKkT8xL+xYPal/XwPR3vWwDSrCwdmXdu0Z5Csh LVQ7UnEv62Zy7x7IQBR7QAcCo=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: henrys@adobe.com, baford@mit.edu, dank@kegel.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org For several of those NAT types, the SDP answer needs to be received before the UDP hole-punching is successful. It's important to also know the (SIP?) signaling delay through your rendezvous servers (SIP prox(y|ies)), between the two RTP peers? For example, if it takes 250ms for the SDP offer to get to the called party, and another 250ms for their answer to get back there is built-in overhead of 500ms due to the signaling system -- ignoring all the STUN candidate gathering and ignoring all of the ICE connectivity checks. -d > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] > Sent: Monday, July 16, 2007 11:44 AM > To: 'Henry Sinnreich'; behave@ietf.org > Cc: henrys@adobe.com; baford@mit.edu; 'Dan Wing'; dank@kegel.com > Subject: RE: [BEHAVE] Re: removing application milestone > > > -----Original Message----- > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Subject: RE: [BEHAVE] Re: removing application milestone > > > > Given that ICE has now gained the status of a creed and maybe I have > > missed it: Are there any published results on the > effectiveness of ICE, > > such as % of success in various NAT scenarios and call > setup delay when > > used with SIP? > > I have seen one private report and it does not look that great. > > Incidentally, I'm dealing with measuring peer connectivity of > my own system > (non-ICE), and here are some of the results for various NAT types: > > Type Count Connectivity Open Time > Fullcone 150 (9%) 92% 1056ms > Fullstatic 397 (25%) 94% 867ms > Fw 68 (4%) 2% 374ms > Rstrcone 598 (37%) 89% 706ms > Rstrstatic 82 ( 5%) 91% 769ms > symmetric 293 (18%) 94% 906ms > > This is read as "598 tested clients had a restricted cone NAT > (making up 37% > of all clients tested), with an average peer connectivity > success rate of > 89%". ("FullStatic" and "Rstrstatic" means a non-NAT'd > client with endpoint > independent/dependent filtering, respectively; "Fw" means a > client that > failed our STUN operation and thus might just have UDP > blocked altogether; > "Open Time" is the time it took to establish the connection and begin > sending actual connection data.) > > fullcone fullstatic fw rstrcone rstrstatic symmetric > fullcone 98% 96% 0% 96% 94% 98% > fullstatic 97% 97% 5% 97% 90% 98% > fw 0% 5% 0% 0% 0% 0% > rstrcone 96% 97% 0% 16% 66% 27% > rstrstatic 94% 92% 0% 66% 100% > symmetric 98% 98% 0% 12% 100% > > Here are the pairwise peer connectivities. As you can see, > this is a pretty > small test (only maybe 1000 total clients), an thus not all pairwise > scenarios got tested (ie, no rstrstatic:symmetric or > symmetric:symmetric > tests were attempted). > > Thus I wouldn't put too much faith in those numbers > (especially anything > claiming 100%) until I have numbers on a broader scale. For > some reason I'm > seeing peer connectivity problems at larger scales (average peer > connectivity across the board is 90% in the above case, but > drops to 40% > when tested on 10x the clients), and I'm still ironing them out (there > appears to be a problem in my test infrastructure). > > Basically, I'd love to see some results on ICE in the above format, as > that'll let me do an apples-to-apples comparison of it versus mine. > > -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 16 15:25: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 1IAWBv-00039C-NZ; Mon, 16 Jul 2007 15:25:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAWBu-00037B-Oc for behave-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 15:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAWBu-000373-F0 for behave@ietf.org; Mon, 16 Jul 2007 15:25:06 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAWBp-00089W-UG for behave@ietf.org; Mon, 16 Jul 2007 15:25:06 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 16 Jul 2007 12:24:55 -0700 From: "David Barrett" To: "'Dan Wing'" , "'Henry Sinnreich'" , Subject: RE: [BEHAVE] Re: removing application milestone Date: Mon, 16 Jul 2007 12:24:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNAAAVY8gAAAciyA In-Reply-To: <02eb01c7c7dc$4568b110$c4f0200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Message-Id: Cc: henrys@adobe.com, baford@mit.edu, dank@kegel.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org To be clear, I'm not using SIP (or ICE, or standard STUN). So, I don't have the SDP exchange step -- can you remind me why that is necessary? The connection-establishment protocol in my architecture is: 0) Clients centrally register their addresses on startup ... 1) Client A asks the server how to contact B 2) The server returns B's address to A 3) Simultaneously, the server instructs B to connect to A 4) A and B connect to each other at the same time over all routes 5) The connection is established once a single route is identified 6) If a faster route is identified, it switches to that I don't have a detailed breakdown of the latencies of each step (though that would be interesting). -david > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, July 16, 2007 12:05 PM > To: 'David Barrett'; 'Henry Sinnreich'; behave@ietf.org > Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com > Subject: RE: [BEHAVE] Re: removing application milestone > > For several of those NAT types, the SDP answer needs to be received before > the UDP hole-punching is successful. It's important to also know the > (SIP?) > signaling delay through your rendezvous servers (SIP prox(y|ies)), between > the two RTP peers? For example, if it takes 250ms for the SDP offer to > get > to the called party, and another 250ms for their answer to get back there > is > built-in overhead of 500ms due to the signaling system -- ignoring all the > STUN candidate gathering and ignoring all of the ICE connectivity checks. > > -d > > > -----Original Message----- > > From: David Barrett [mailto:dbarrett@quinthar.com] > > Sent: Monday, July 16, 2007 11:44 AM > > To: 'Henry Sinnreich'; behave@ietf.org > > Cc: henrys@adobe.com; baford@mit.edu; 'Dan Wing'; dank@kegel.com > > Subject: RE: [BEHAVE] Re: removing application milestone > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Subject: RE: [BEHAVE] Re: removing application milestone > > > > > > Given that ICE has now gained the status of a creed and maybe I have > > > missed it: Are there any published results on the > > effectiveness of ICE, > > > such as % of success in various NAT scenarios and call > > setup delay when > > > used with SIP? > > > I have seen one private report and it does not look that great. > > > > Incidentally, I'm dealing with measuring peer connectivity of > > my own system > > (non-ICE), and here are some of the results for various NAT types: > > > > Type Count Connectivity Open Time > > Fullcone 150 (9%) 92% 1056ms > > Fullstatic 397 (25%) 94% 867ms > > Fw 68 (4%) 2% 374ms > > Rstrcone 598 (37%) 89% 706ms > > Rstrstatic 82 ( 5%) 91% 769ms > > symmetric 293 (18%) 94% 906ms > > > > This is read as "598 tested clients had a restricted cone NAT > > (making up 37% > > of all clients tested), with an average peer connectivity > > success rate of > > 89%". ("FullStatic" and "Rstrstatic" means a non-NAT'd > > client with endpoint > > independent/dependent filtering, respectively; "Fw" means a > > client that > > failed our STUN operation and thus might just have UDP > > blocked altogether; > > "Open Time" is the time it took to establish the connection and begin > > sending actual connection data.) > > > > fullcone fullstatic fw rstrcone rstrstatic symmetric > > fullcone 98% 96% 0% 96% 94% 98% > > fullstatic 97% 97% 5% 97% 90% 98% > > fw 0% 5% 0% 0% 0% 0% > > rstrcone 96% 97% 0% 16% 66% 27% > > rstrstatic 94% 92% 0% 66% 100% > > symmetric 98% 98% 0% 12% 100% > > > > Here are the pairwise peer connectivities. As you can see, > > this is a pretty > > small test (only maybe 1000 total clients), an thus not all pairwise > > scenarios got tested (ie, no rstrstatic:symmetric or > > symmetric:symmetric > > tests were attempted). > > > > Thus I wouldn't put too much faith in those numbers > > (especially anything > > claiming 100%) until I have numbers on a broader scale. For > > some reason I'm > > seeing peer connectivity problems at larger scales (average peer > > connectivity across the board is 90% in the above case, but > > drops to 40% > > when tested on 10x the clients), and I'm still ironing them out (there > > appears to be a problem in my test infrastructure). > > > > Basically, I'd love to see some results on ICE in the above format, as > > that'll let me do an apples-to-apples comparison of it versus mine. > > > > -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 16 17:05: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 1IAXlE-0006Xu-DY; Mon, 16 Jul 2007 17:05:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAXlC-0006Wj-N5 for behave-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 17:05:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXlC-0006Wb-Bg for behave@ietf.org; Mon, 16 Jul 2007 17:05:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAXlB-0003aB-O0 for behave@ietf.org; Mon, 16 Jul 2007 17:05:38 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2007 14:05:34 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAA57m0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,543,1175497200"; d="scan'208"; a="503748829:sNHT98591240" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6GL5X87007323; Mon, 16 Jul 2007 14:05:33 -0700 Received: from dwingwxp (dhcp-128-107-100-125.cisco.com [128.107.100.125]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6GL5WA0011057; Mon, 16 Jul 2007 21:05:32 GMT From: "Dan Wing" To: "'David Barrett'" , "'Henry Sinnreich'" , Subject: RE: [BEHAVE] Re: removing application milestone Date: Mon, 16 Jul 2007 14:05:31 -0700 Message-ID: <008001c7c7ed$0c3624c0$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <5v43jn$fggis@sj-inbound-c.cisco.com> Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNAAAVY8gAAAciyAAAOuUOA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5892; t=1184619933; x=1185483933; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20removing=20application=20milestone |Sender:=20; bh=GynQ7eYWD+/wpvu/pjCCWjcYLzbQZvXahjqe4NeZAjU=; b=rLrgNp/kwJwymYGfewgdmJ/5oqc99fIoB9LZ9BLkWA316sak8/htm5mPHlXBdIYaZOTcLo8W tEaaDuXKtDkqVnWd544XHPonUX8H+S6jN3jKAMlaofJQ1hxoE0L5fTZZxbOQmHr7zbWO4YY2qT DyjfJdvH1Gd0krS29cnUF8eow=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: henrys@adobe.com, baford@mit.edu, dank@kegel.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > To be clear, I'm not using SIP (or ICE, or standard STUN). Alright. Several of ICE's features are designed to allow ICE to complete quickly (most notably ICE's "triggered checks"). > So, I don't have the SDP exchange step -- can you remind > me why that is necessary? For UDP hole-punching to work, both sides need to indicate their IP address and UDP port to the other, via a rendezvous server of some sort. > The connection-establishment protocol in my architecture is: > > 0) Clients centrally register their addresses on startup Ok, so that's your rendezvous server. > ... > 1) Client A asks the server how to contact B > 2) The server returns B's address to A > 3) Simultaneously, the server instructs B to connect to A > 4) A and B connect to each other at the same time over all routes > 5) The connection is established once a single route is identified > 6) If a faster route is identified, it switches to that > > I don't have a detailed breakdown of the latencies of each > step (though that > would be interesting). What's the latency if there are no NATs involved whatsoever? Your numbers indicate hundreds of milliseconds for every NAT scenario, even for the kinds of NATs that allow connections from any IP address. NATs do not, on their own accord, add hundreds of milliseconds of delay. If they did, DNS queries would take too long and people would complain that "the Internet" is slow (web pages with lots of embedded objects on different servers). -d > -david > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Monday, July 16, 2007 12:05 PM > > To: 'David Barrett'; 'Henry Sinnreich'; behave@ietf.org > > Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com > > Subject: RE: [BEHAVE] Re: removing application milestone > > > > For several of those NAT types, the SDP answer needs to be > received before > > the UDP hole-punching is successful. It's important to > also know the > > (SIP?) > > signaling delay through your rendezvous servers (SIP > prox(y|ies)), between > > the two RTP peers? For example, if it takes 250ms for the > SDP offer to > > get > > to the called party, and another 250ms for their answer to > get back there > > is > > built-in overhead of 500ms due to the signaling system -- > ignoring all the > > STUN candidate gathering and ignoring all of the ICE > connectivity checks. > > > > -d > > > > > -----Original Message----- > > > From: David Barrett [mailto:dbarrett@quinthar.com] > > > Sent: Monday, July 16, 2007 11:44 AM > > > To: 'Henry Sinnreich'; behave@ietf.org > > > Cc: henrys@adobe.com; baford@mit.edu; 'Dan Wing'; dank@kegel.com > > > Subject: RE: [BEHAVE] Re: removing application milestone > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > > Subject: RE: [BEHAVE] Re: removing application milestone > > > > > > > > Given that ICE has now gained the status of a creed and > maybe I have > > > > missed it: Are there any published results on the > > > effectiveness of ICE, > > > > such as % of success in various NAT scenarios and call > > > setup delay when > > > > used with SIP? > > > > I have seen one private report and it does not look that great. > > > > > > Incidentally, I'm dealing with measuring peer connectivity of > > > my own system > > > (non-ICE), and here are some of the results for various NAT types: > > > > > > Type Count Connectivity Open Time > > > Fullcone 150 (9%) 92% 1056ms > > > Fullstatic 397 (25%) 94% 867ms > > > Fw 68 (4%) 2% 374ms > > > Rstrcone 598 (37%) 89% 706ms > > > Rstrstatic 82 ( 5%) 91% 769ms > > > symmetric 293 (18%) 94% 906ms > > > > > > This is read as "598 tested clients had a restricted cone NAT > > > (making up 37% > > > of all clients tested), with an average peer connectivity > > > success rate of > > > 89%". ("FullStatic" and "Rstrstatic" means a non-NAT'd > > > client with endpoint > > > independent/dependent filtering, respectively; "Fw" means a > > > client that > > > failed our STUN operation and thus might just have UDP > > > blocked altogether; > > > "Open Time" is the time it took to establish the > connection and begin > > > sending actual connection data.) > > > > > > fullcone fullstatic fw rstrcone > rstrstatic symmetric > > > fullcone 98% 96% 0% 96% 94% 98% > > > fullstatic 97% 97% 5% 97% 90% 98% > > > fw 0% 5% 0% 0% 0% 0% > > > rstrcone 96% 97% 0% 16% 66% 27% > > > rstrstatic 94% 92% 0% 66% 100% > > > symmetric 98% 98% 0% 12% 100% > > > > > > Here are the pairwise peer connectivities. As you can see, > > > this is a pretty > > > small test (only maybe 1000 total clients), an thus not > all pairwise > > > scenarios got tested (ie, no rstrstatic:symmetric or > > > symmetric:symmetric > > > tests were attempted). > > > > > > Thus I wouldn't put too much faith in those numbers > > > (especially anything > > > claiming 100%) until I have numbers on a broader scale. For > > > some reason I'm > > > seeing peer connectivity problems at larger scales (average peer > > > connectivity across the board is 90% in the above case, but > > > drops to 40% > > > when tested on 10x the clients), and I'm still ironing > them out (there > > > appears to be a problem in my test infrastructure). > > > > > > Basically, I'd love to see some results on ICE in the > above format, as > > > that'll let me do an apples-to-apples comparison of it > versus mine. > > > > > > -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 16 21:14:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbeI-0005ex-3J; Mon, 16 Jul 2007 21:14:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAbeF-0005eV-TE for behave-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 21:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbeF-0005e8-9p; Mon, 16 Jul 2007 21:14:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAbeA-0000EB-VH; Mon, 16 Jul 2007 21:14:43 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2007 18:14:38 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHq0m0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,544,1175497200"; d="scan'208"; a="503818148:sNHT28388012" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6H1EcXX008883; Mon, 16 Jul 2007 18:14:38 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6H1EbA0017496; Tue, 17 Jul 2007 01:14:37 GMT From: "Dan Wing" To: , , Date: Mon, 16 Jul 2007 18:14:37 -0700 Message-ID: <019a01c7c80f$d8623d50$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfID9fNkx1GEPGMRDKyfIQIZRj1Qw== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1746; t=1184634878; x=1185498878; 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:=20multiple=20SSM=20sources=20behind=20a=20NAT |Sender:=20; bh=AAkf/mELeDe++h8ajREJW7atXlJefFANqVxfMeX/+TY=; b=JZ04QbYVkD5LSTkXbjTPqQcw495bBSv8UstLiYCch119N8Yb+EgDLd0xwf0qw0pYBge4Qfuy m7IY8bH5LX/B7k0ciepv0BMXpgt2oTuUXnCeYMm/qkuoJCHjtShRn2p7; 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: 769a46790fb42fbb0b0cc700c82f7081 Cc: prashantj@huawei.com Subject: [BEHAVE] multiple SSM sources behind a NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org During some offline discussions, Prashant Jhingran brought up an issue we aren't sure how to best resolve. The problem is that if two (or more) SSM sources are on the 'inside' of a NAT, they can choose the same multicast IP address (G). This works fine on the 'inside' of the NAT -- they are distinguished because their SSM channel is unique because they have different source IP addresses (S). However, if their traffic is NATted, they will share the same IP source address on the Internet, as in the following diagram: +-----+ SSM source A -----+ | 192.168.1.1 | NAT +------------- Internet | |192.0.2.1 SSM source B -----+ | 192.168.1.2 +-----+ There seems to be only one viable approach to address this problem: First SSM source wins and new SSM source loses. That is, when the number of SSM sources exceeds the number of public IP interfaces, the first SSM source(s) win, and the newest SSM source loses. That is, the newest SSM source's traffic is not forwarded towards the public interface. Difficulties: - NAT can't detect that first SSM source has finished sending and the block should be removed, except with a timeout. How long should we recommend for that timeout? - We can't communicate to the losing SSM source that its SSM data isn't being forwarded by the NAT. - Do we want to RECOMMEND that a NAT allow the NAT administrator to override this behavior, and transmit multicast packets without regard to this problem? (This is functionally the same as using a timeout of 0ms). Comments and additional suggestions are welcome. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 16 21:23:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbmz-0003Vg-Ou; Mon, 16 Jul 2007 21:23:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAbmy-0003V5-NA for behave-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 21:23:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbmy-0003Ut-DQ; Mon, 16 Jul 2007 21:23:44 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAbmt-0000YJ-W2; Mon, 16 Jul 2007 21:23:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2007 18:23:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANO2m0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,544,1175497200"; d="scan'208"; a="503820034:sNHT29354616" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6H1Nc7k013165; Mon, 16 Jul 2007 18:23:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6H1NcTb021446; Tue, 17 Jul 2007 01:23:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 18:23:38 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 18:23:38 -0700 Message-ID: <469C1A1F.2090102@cisco.com> Date: Mon, 16 Jul 2007 21:23:43 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 01:23:38.0346 (UTC) FILETIME=[1A3B94A0:01C7C811] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1845; t=1184635418; x=1185499418; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE=20tutorial=20in=20Chicago=20[DO=20NOT=20REPLY]=20-=20PLEA SE=20ADVISE=20IF=20YOU=20WILL=0A=20ATTEND! |Sender:=20; bh=2mEMezIhgSd4fQtdetbfRv0w1jcLg1hf4bgHjST7IQc=; b=E8JzvIKOXdm/coVCa8PMIpZSSHcW1xP7WCAHJJydd1KTAo4rHvwnnmQbFu0sgmYA2MXhXiTZ 5mrrLKb6+K2doFKdUhVSQSvfLQ1cG+MRM5jN63ABURvqDhDJUyb32NZD; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [BEHAVE] ICE tutorial in Chicago [DO NOT REPLY] - PLEASE ADVISE IF YOU WILL ATTEND! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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've gotten very few responses indicating interest. If I don't get more acceptances I'll have to cancel. Please, if you do plan on attending, send me mail per the instructions below if you have not done so. (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- 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 Jul 17 02:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAg8S-0006hP-E9; Tue, 17 Jul 2007 02:02:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAg8Q-0006hB-Ol for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 02:02:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAg8P-0006gs-S5; Tue, 17 Jul 2007 02:02:09 -0400 Received: from kecgate02.infosysconsulting.com ([61.95.162.76] helo=kecgate02.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAg8K-0000uz-V4; Tue, 17 Jul 2007 02:02:09 -0400 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by kecgate02.infosys.com with InterScan Message Security Suite; Tue, 17 Jul 2007 11:31:03 +0530 Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:31:59 +0530 Received: from osfr-170.local (192.168.101.134) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server id 8.0.700.0; Tue, 17 Jul 2007 11:31:59 +0530 From: Bharat Joshi To: Dan Wing In-Reply-To: <019a01c7c80f$d8623d50$7d646b80@amer.cisco.com> References: <019a01c7c80f$d8623d50$7d646b80@amer.cisco.com> Content-Type: text/plain Organization: Infosys Technologies Ltd Date: Tue, 17 Jul 2007 11:34:35 +0530 Message-ID: <1184652275.14104.83.camel@magadha> MIME-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 06:01:59.0880 (UTC) FILETIME=[FD1F6C80:01C7C837] X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "mboned@ietf.org" , "magma@ietf.org" , "behave@ietf.org" Subject: [BEHAVE] Re: [MBONED] multiple SSM sources behind a NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan, > The problem is that if two (or more) SSM sources are on the 'inside' > of a NAT, they can choose the same multicast IP address (G). This > works fine on the 'inside' of the NAT -- they are distinguished > because their SSM channel is unique because they have different > source IP addresses (S). However, if their traffic is NATted, they > will share the same IP source address on the Internet, as in the > following diagram: > > +-----+ > SSM source A -----+ | > 192.168.1.1 | NAT +------------- Internet > | |192.0.2.1 > SSM source B -----+ | > 192.168.1.2 +-----+ > > > There seems to be only one viable approach to address this problem: > > First SSM source wins and new SSM source loses. That is, when the > number of SSM sources exceeds the number of public IP interfaces, the > first SSM source(s) win, and the newest SSM source loses. That is, > the newest SSM source's traffic is not forwarded towards the public > interface. > > Difficulties: > > - NAT can't detect that first SSM source has finished sending and > the block should be removed, except with a timeout. How long > should we recommend for that timeout? > > - We can't communicate to the losing SSM source that its SSM data > isn't being forwarded by the NAT. > > - Do we want to RECOMMEND that a NAT allow the NAT administrator > to override this behavior, and transmit multicast packets > without regard to this problem? (This is functionally the same > as using a timeout of 0ms). > First of all, for SSM, receives MUST know the source address so that they can subscribe to the SSM channel [A given S,G pair]. In the first place, I would say that this would be a wrong configuration. If someone wants to support this and gateway does NAT, NAT device could change the group address to something different. But there should be a way for receivers to find out what group address NAT device chooses for a given stream. Not allowing a second stream destined to same SSM group looks fine. I am not sure if receivers can differentiate the streams based on the destination port [if stream is destined for one] but this will not work if the hosts inside NAT uses the same destination port also. My 2 cents. Thanks, Bharat **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 02:44:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgnN-0004Y3-PD; Tue, 17 Jul 2007 02:44:29 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAgnM-0004WO-2r for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 02:44:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgnI-0004Tj-Fa for behave@ietf.org; Tue, 17 Jul 2007 02:44:24 -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 1IAgnE-00024P-02 for behave@ietf.org; Tue, 17 Jul 2007 02:44:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6H6hpdT026744 for ; Tue, 17 Jul 2007 09:44:18 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 09:44:16 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 09:44:14 +0300 Received: from esdhcp05132.research.nokia.com ([172.21.51.32]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 09:44:14 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Re: removing application milestone Date: Tue, 17 Jul 2007 09:44:15 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707170944.15956.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Jul 2007 06:44:14.0223 (UTC) FILETIME=[E3B579F0:01C7C83D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Monday 16 July 2007 22:24:51 ext David Barrett wrote: > To be clear, I'm not using SIP (or ICE, or standard STUN). So, I don't > have the SDP exchange step -- can you remind me why that is necessary? > > The connection-establishment protocol in my architecture is: > > 0) Clients centrally register their addresses on startup > ... > 1) Client A asks the server how to contact B I expect such a design increase ease of implementation a lot at the cost of= =20 success rate and battery lifetime. With ICE, the candidates may (it's up to= =20 the implementation) be generated right before sending the invitation. When using centralized registration of your binding, there is a much higher= =20 risk that bindings on the middleboxes have vanished (reboot?) or changed=20 between (I am not willing to guesstimate how high is higher) registration a= nd=20 use. Also, it supposedly means you have to keep refreshing the binding, which is= a=20 well-known battery killing process for mobile devices. In SIP+ICE case, I=20 figure you'd merely keep a TCP connection to your SIP proxy, which=20 (*according to research*) requires much fewer keep-alives packet than UDP. Nevertheless, your approach might be better suited for peer-to-peer=20 server-poor environments where even signaling (proxies) might be expensive. =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 Jul 17 03:57: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 1IAhw6-0008Eo-Ha; Tue, 17 Jul 2007 03:57:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAhw5-0008B5-Cv for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 03:57:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAhw4-0008Ap-JI for behave@ietf.org; Tue, 17 Jul 2007 03:57:32 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAhw4-0005vW-49 for behave@ietf.org; Tue, 17 Jul 2007 03:57:32 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Tue, 17 Jul 2007 00:57:02 -0700 From: "David Barrett" To: =?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?= , Subject: RE: [BEHAVE] Re: removing application milestone Date: Tue, 17 Jul 2007 00:56:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfIPfHhuK4heqxESAiViBPEquXt0gABxR2A In-Reply-To: <200707170944.15956.remi.denis-courmont@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Message-Id: 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 If anybody could provide *any* real world data on *any* ICE = implementation, of *any* draft version, used at *any* scale, that'd be really helpful. = It's really hard to do a real world analysis against something that only = exists in theory. (A friend of mine once said "Everything works in theory. I = want to move there someday.") But I'm happy to try. =20 Re: Peer connectivity The system I show achieves real-world peer connectivity over 90%. I'm = open to ICE achieving greater than that, but I don't see how that would be = the case. Are you saying ICE will try additional routes, or that the routes = it tries will somehow be more likely to work? (I should mention that peers = in my system keep their bindings alive; when they die, new bindings are discovered and the server is updated.) Re: Battery life This isn't a concern to me, but I'd love to see the data on this. Re: Server-poor I didn't follow the last bit -- I'm not sure what a "peer-to-peer server-poor environment" is. This is designed for and proven in the = real world internet at a very large scale around the globe. Are you = suggesting that somehow ICE is better adapted for reality than this system, or that this system is somehow better suited for some other environment than the = one it's currently being used in? -david > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] > Sent: Monday, July 16, 2007 11:44 PM > To: behave@ietf.org > Subject: Re: [BEHAVE] Re: removing application milestone >=20 > On Monday 16 July 2007 22:24:51 ext David Barrett wrote: > > To be clear, I'm not using SIP (or ICE, or standard STUN). So, I = don't > > have the SDP exchange step -- can you remind me why that is = necessary? > > > > The connection-establishment protocol in my architecture is: > > > > 0) Clients centrally register their addresses on startup > > ... > > 1) Client A asks the server how to contact B >=20 > I expect such a design increase ease of implementation a lot at the = cost > of > success rate and battery lifetime. With ICE, the candidates may (it's = up > to > the implementation) be generated right before sending the invitation. >=20 > When using centralized registration of your binding, there is a much > higher > risk that bindings on the middleboxes have vanished (reboot?) or = changed > between (I am not willing to guesstimate how high is higher) = registration > and > use. >=20 > Also, it supposedly means you have to keep refreshing the binding, = which > is a > well-known battery killing process for mobile devices. In SIP+ICE = case, I > figure you'd merely keep a TCP connection to your SIP proxy, which > (*according to research*) requires much fewer keep-alives packet than = UDP. >=20 > Nevertheless, your approach might be better suited for peer-to-peer > server-poor environments where even signaling (proxies) might be > expensive. >=20 > -- > R=E9mi Denis-Courmont >=20 >=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 Tue Jul 17 04:03:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAi2D-0004no-PE; Tue, 17 Jul 2007 04:03:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAi2B-0004nj-MT for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 04:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAi2A-0004nV-Bc for behave@ietf.org; Tue, 17 Jul 2007 04:03:50 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAi25-0004bf-T8 for behave@ietf.org; Tue, 17 Jul 2007 04:03:50 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Tue, 17 Jul 2007 01:03:38 -0700 From: "David Barrett" To: "'Dan Wing'" , "'Henry Sinnreich'" , Subject: RE: [BEHAVE] Re: removing application milestone Date: Tue, 17 Jul 2007 01:03:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNAAAVY8gAAAciyAAAOuUOAAFvmQ4A== In-Reply-To: <008001c7c7ed$0c3624c0$7d646b80@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Message-Id: Cc: henrys@adobe.com, baford@mit.edu, dank@kegel.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > > What's the latency if there are no NATs involved whatsoever? Your > numbers indicate hundreds of milliseconds for every NAT scenario, > even for the kinds of NATs that allow connections from any IP > address. NATs do not, on their own accord, add hundreds of > milliseconds of delay. If they did, DNS queries would take too > long and people would complain that "the Internet" is slow (web > pages with lots of embedded objects on different servers). I'm not sure I follow. The times I gave were the elapsed ms it took to establish the connection from start to finish. So it'd be roughly: (The RTT time between A and the RZ server) + (The processing time inside the RZ) + (The RTT time between A and B) + (The three-way handshake and NAT penetration time) Thus in general, it takes a second or less to establish the connection. However, once that connection has been established, there is no additional latency introduced by the system: packets flow between A and B directly at whatever latency is introduced by the intermediate networks. Does this answer your question? How long does it typically take ICE to establish a connection, including the "triggered check" optimization? Is it also subsecond on average between any two points on the globe? -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 04:18: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 1IAiGk-00030E-KK; Tue, 17 Jul 2007 04:18:54 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAiGf-0002wH-M2 for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 04:18:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAiGe-0002sY-PX for behave@ietf.org; Tue, 17 Jul 2007 04:18:48 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAiGe-0006ei-C4 for behave@ietf.org; Tue, 17 Jul 2007 04:18:48 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6H8IUU0014896; Tue, 17 Jul 2007 11:18:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:18:27 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:18:27 +0300 Received: from esdhcp05132.research.nokia.com ([172.21.51.32]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:18:27 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext David Barrett" , behave@ietf.org Subject: Re: [BEHAVE] Re: removing application milestone Date: Tue, 17 Jul 2007 11:18:27 +0300 User-Agent: KMail/1.9.6 References: <200707170757.l6H7vA23001528@mgw-mx04.nokia.com> In-Reply-To: <200707170757.l6H7vA23001528@mgw-mx04.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707171118.28086.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Jul 2007 08:18:27.0048 (UTC) FILETIME=[0D0E1E80:01C7C84B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 17 July 2007 10:56:59 you wrote: > Re: Battery life > This isn't a concern to me, but I'd love to see the data on this. http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc2= 007.pdf And this is a very serious concern to *me*. > Re: Server-poor > I didn't follow the last bit -- I'm not sure what a "peer-to-peer > server-poor environment" is. This is designed for and proven in the real > world internet at a very large scale around the globe. Are you suggesting > that somehow ICE is better adapted for reality than this system, or that > this system is somehow better suited for some other environment than the > one it's currently being used in? If you have lots of servers with enough bandwidth that you do not try to=20 minimize the volume of signaling, then using multiple and dymanically=20 generated candidates (as ICE calls them) is bound to yield better results=20 than a single candidate that would be computed at application startup. How much better "better" is, possibly not so significant. =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 Jul 17 04:25: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 1IAiNE-0007VP-EM; Tue, 17 Jul 2007 04:25:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAiND-0007V5-Aa for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 04:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAiND-0007Up-0T for behave@ietf.org; Tue, 17 Jul 2007 04:25:35 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAiN8-0005DI-IE for behave@ietf.org; Tue, 17 Jul 2007 04:25:34 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Tue, 17 Jul 2007 01:25:22 -0700 From: "David Barrett" To: =?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?= , Subject: RE: [BEHAVE] Re: removing application milestone Date: Tue, 17 Jul 2007 01:25:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfISyHjYjigTl89RQSDTlZT0duGQwAAB9Fg In-Reply-To: <200707171118.28086.remi.denis-courmont@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Message-Id: Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] >=20 > On Tuesday 17 July 2007 10:56:59 you wrote: > > Re: Battery life > > This isn't a concern to me, but I'd love to see the data on this. >=20 > = http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vt= c > 2007.pdf > And this is a very serious concern to *me*. Cool, thanks! > If you have lots of servers with enough bandwidth that you do not try = to > minimize the volume of signaling, then using multiple and dymanically > generated candidates (as ICE calls them) is bound to yield better = results > than a single candidate that would be computed at application startup. >=20 > How much better "better" is, possibly not so significant. I'm still not sure I see how this is the case. Can you give me a very precise example of how ICE (in theory) does better? Whether you do your STUN operation immediately before the connection or = you keep doing it continuously (as per the design I'm using), it comes up = with the same results. Except my results are readily available, and thus the connection establishes quicker. If this isn't the case, can you please give a very clear example of why = it's better to do it right before connection establishment instead of on = startup and continuously thereafter? -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 04: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 1IAifY-0002l2-7X; Tue, 17 Jul 2007 04:44:32 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAifW-0002kt-Nv for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 04:44:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAifW-0002kd-BN for behave@ietf.org; Tue, 17 Jul 2007 04:44:30 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAifV-0007Na-TN for behave@ietf.org; Tue, 17 Jul 2007 04:44:30 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6H8iF1e004878; Tue, 17 Jul 2007 11:44:28 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:44:23 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:44:23 +0300 Received: from esdhcp05132.research.nokia.com ([172.21.51.32]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:44:22 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext David Barrett" , behave@ietf.org Subject: Re: [BEHAVE] Re: removing application milestone Date: Tue, 17 Jul 2007 11:44:23 +0300 User-Agent: KMail/1.9.6 References: <200707170825.l6H8PUqf013539@mgw-mx06.nokia.com> In-Reply-To: <200707170825.l6H8PUqf013539@mgw-mx06.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707171144.23790.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Jul 2007 08:44:22.0685 (UTC) FILETIME=[AC497CD0:01C7C84E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 17 July 2007 11:25:19 ext David Barrett wrote: > Whether you do your STUN operation immediately before the connection or y= ou > keep doing it continuously (as per the design I'm using), it comes up with > the same results. Except my results are readily available, and thus the > connection establishes quicker. Sorry not always. I have had reports of some NATs doing very weird/very stu= pid=20 stuff with their ports mapping, e.g. when two clients behind the same NAT u= se=20 the same internal port number. It is also common sense that the fresher informations is usually more=20 accurate. =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 Jul 17 04:58:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAisn-0007OG-UH; Tue, 17 Jul 2007 04:58:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAism-0007O4-EH for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 04:58:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAism-0007Nw-3O for behave@ietf.org; Tue, 17 Jul 2007 04:58:12 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAisl-0007m4-PT for behave@ietf.org; Tue, 17 Jul 2007 04:58:12 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Tue, 17 Jul 2007 01:58:05 -0700 From: "David Barrett" To: =?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?= , Subject: RE: [BEHAVE] Re: removing application milestone Date: Tue, 17 Jul 2007 01:58:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfITrTRFQzdl0LRTkmQEtFtXMEqpQAAXOWA In-Reply-To: <200707171144.23790.remi.denis-courmont@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Message-Id: Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] > Subject: Re: [BEHAVE] Re: removing application milestone >=20 > On Tuesday 17 July 2007 11:25:19 ext David Barrett wrote: > > Whether you do your STUN operation immediately before the connection = or > you > > keep doing it continuously (as per the design I'm using), it comes = up > with > > the same results. Except my results are readily available, and thus = the > > connection establishes quicker. >=20 > Sorry not always. I have had reports of some NATs doing very = weird/very > stupid > stuff with their ports mapping, e.g. when two clients behind the same = NAT > use > the same internal port number. >=20 > It is also common sense that the fresher informations is usually more > accurate. Heh, will I'll totally agree with you about crazy NATs out there. The = other day I was testing on a network whose NAT would duplicate every packet = sent out of it *3-7 times*. That's right: send one UDP or TCP packet, and several identical copies would arrive at the destination in a big clump. So I agree with the theory that doing it right before the connection = might produce better results, and I'm eager to see that theory tested in = practice. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 07:07:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAku7-0002GS-P3; Tue, 17 Jul 2007 07:07:43 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAku4-000270-7p for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 07:07:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAku3-00023f-BL; Tue, 17 Jul 2007 07:07:39 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAku2-0003UM-S0; Tue, 17 Jul 2007 07:07:39 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 7907425; Tue, 17 Jul 2007 07:07:05 -0400 In-Reply-To: <469C6368.1090603@uninett.no> References: <019a01c7c80f$d8623d50$7d646b80@amer.cisco.com> <1184652275.14104.83.camel@magadha> <469C6368.1090603@uninett.no> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DA037FE-AE52-4004-86D9-38185143C6F7@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Tue, 17 Jul 2007 07:07:00 -0400 To: Stig Venaas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: "mboned@ietf.org" , "magma@ietf.org" , "behave@ietf.org" , Bharat Joshi Subject: [BEHAVE] Re: [magma] Re: [MBONED] multiple SSM sources behind a NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Jul 17, 2007, at 2:36 AM, Stig Venaas wrote: > Bharat Joshi wrote: >> Dan, >>> The problem is that if two (or more) SSM sources are on the 'inside' >>> of a NAT, they can choose the same multicast IP address (G). This >>> works fine on the 'inside' of the NAT -- they are distinguished >>> because their SSM channel is unique because they have different >>> source IP addresses (S). However, if their traffic is NATted, they >>> will share the same IP source address on the Internet, as in the >>> following diagram: >>> >>> +-----+ >>> SSM source A -----+ | >>> 192.168.1.1 | NAT +------------- Internet >>> | |192.0.2.1 >>> SSM source B -----+ | >>> 192.168.1.2 +-----+ >>> >>> >>> There seems to be only one viable approach to address this problem: >>> >>> First SSM source wins and new SSM source loses. That is, when the >>> number of SSM sources exceeds the number of public IP interfaces, >>> the >>> first SSM source(s) win, and the newest SSM source loses. That is, >>> the newest SSM source's traffic is not forwarded towards the public >>> interface. > > This sounds rather ugly to me, and the behaviour may be hard to > understand for users exposed to this. I would rather have both > being forwarded and say that it's a user error to try to use the > same group for the two. That is like Marshall said, use different > groups. However, I don't think it's a good idea to modify the group > in the NAT itself since that would also probably require the > announcement of which S,G to be used to be modified, and this can be > done through methods, e.g. SDP file through HTTP or email or whatever. > Note that in any case, the S is modified, and thus the outside SDP files etc. have to be too. > In short, I don't think you should solve this. In this not so common > situation, better let admins/users figure out that they should not > use the same G. In fact, there may be other reasons for choosing > different Gs as well (e.g. it may be good to use Gs that map to > different MAC addresses due to snooping devices and NICs). Thinking about this overnight, this seems to me to be a lot like port mapping in a NAT. If you have a simple NAT (i.e., where all internal addresses go to one external one), and you make sure that your SSM groups are all distinct, you can announce a SSM channel sourced from the inside. (Note that you still have to be knowledgeable enough to know your external IP address, which would weed out many home users.) If you want to use two SSM channels with the same group (maybe it's built into your handy SSM enabled video camera, and you have two of them), then it becomes like port mapping - presumably there will be a table in the NAT where you can set this up. You will almost certainly have to know what you are doing for this to work. Note that if there is more than one external S address for the NAT to pick from, you have a similar problem. (It's not enough just to get a new source address - the content source has to know what it is.) So, I think that it would be adequate to take Stig's solution, with something like "the NAT MAY provide additional means, such as mapping tables, to allow the NAT user to manage the mapping of sources, groups and ports of SSM transmissions." Regards Marshall > > Stig > >>> >>> Difficulties: >>> >>> - NAT can't detect that first SSM source has finished sending >>> and >>> the block should be removed, except with a timeout. How long >>> should we recommend for that timeout? >>> >>> - We can't communicate to the losing SSM source that its SSM >>> data >>> isn't being forwarded by the NAT. >>> >>> - Do we want to RECOMMEND that a NAT allow the NAT administrator >>> to override this behavior, and transmit multicast packets >>> without regard to this problem? (This is functionally the >>> same >>> as using a timeout of 0ms). >>> >> First of all, for SSM, receives MUST know the source address so that >> they can subscribe to the SSM channel [A given S,G pair]. In the >> first >> place, I would say that this would be a wrong configuration. >> If someone wants to support this and gateway does NAT, NAT device >> could >> change the group address to something different. But there should >> be a >> way for receivers to find out what group address NAT device >> chooses for >> a given stream. >> Not allowing a second stream destined to same SSM group looks fine. >> I am not sure if receivers can differentiate the streams based on the >> destination port [if stream is destined for one] but this will not >> work >> if the hosts inside NAT uses the same destination port also. >> My 2 cents. >> Thanks, >> Bharat >> **************** CAUTION - Disclaimer ***************** >> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION >> intended solely for the use of the addressee(s). If you are not >> the intended recipient, please notify the sender by e-mail and >> delete the original message. Further, you are not to copy, >> disclose, or distribute this e-mail or its contents to any other >> person and any such actions are unlawful. This e-mail may contain >> viruses. Infosys has taken every reasonable precaution to minimize >> this risk, but is not liable for any damage you may sustain as a >> result of any virus in this e-mail. You should carry out your own >> virus checks before opening the e-mail or attachment. Infosys >> reserves the right to monitor and review the content of all >> messages sent to or from this e-mail address. Messages sent to or >> from this e-mail address may be stored on the Infosys e-mail system. >> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >> _______________________________________________ >> magma mailing list >> magma@ietf.org >> https://www1.ietf.org/mailman/listinfo/magma > > > > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www1.ietf.org/mailman/listinfo/mboned _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 08:43: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 1IAmOd-0007Ix-Fn; Tue, 17 Jul 2007 08:43:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAmOc-0007Ih-9Z for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 08:43:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmOb-0007IZ-VV for behave@ietf.org; Tue, 17 Jul 2007 08:43:17 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAmOR-0006kG-Aj for behave@ietf.org; Tue, 17 Jul 2007 08:43:17 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6HCgVuc025802; Tue, 17 Jul 2007 15:42:39 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 15:42:21 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 15:42:21 +0300 Received: from esdhcp05132.research.nokia.com ([172.21.51.32]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 15:42:21 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, ext Jonathan Rosenberg Subject: Re: [BEHAVE] RFC3489bis-07 now available Date: Tue, 17 Jul 2007 15:42:19 +0300 User-Agent: KMail/1.9.6 References: <46929E54.50301@cisco.com> In-Reply-To: <46929E54.50301@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707171542.19726.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Jul 2007 12:42:21.0306 (UTC) FILETIME=[EB0225A0:01C7C86F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Monday 09 July 2007 23:45:08 ext Jonathan Rosenberg wrote: > RFC3489bis-07 is now available: > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt (...) > * removal of several error codes that could only happen in > implementation errors. By the way, why then does TURN define a "TCP-only operation error"? I might= be=20 mistaken, but it feels strongly like it can only happen with a broken clien= t=20 implementation. > * defined length limits on all free-form fields That's really appreciable! But but, the limit should most likely be express= ed=20 in bytes rather than in characters. Otherwise, it is pretty ambiguous wheth= er=20 the limit is in code points or bytes. Regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 09:08: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 1IAmme-0003Rr-CN; Tue, 17 Jul 2007 09:08:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAmma-0003Rm-Pq for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 09:08:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmma-0003Re-Eu for behave@ietf.org; Tue, 17 Jul 2007 09:08:04 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAmmY-0007Vz-Tv for behave@ietf.org; Tue, 17 Jul 2007 09:08:04 -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 l6HD7jJv004102; Tue, 17 Jul 2007 16:07:59 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 16:07:43 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 16:07:42 +0300 Received: from esdhcp05132.research.nokia.com ([172.21.51.32]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 16:07:42 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] RFC3489bis-07 now available Date: Tue, 17 Jul 2007 16:07:41 +0300 User-Agent: KMail/1.9.6 References: <46929E54.50301@cisco.com> In-Reply-To: <46929E54.50301@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707171607.41159.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Jul 2007 13:07:42.0707 (UTC) FILETIME=[75D58430:01C7C873] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Monday 09 July 2007 23:45:08 ext Jonathan Rosenberg wrote: > * removal of several error codes that could only happen in > implementation errors. Looks like 431 has been unduly removed. It is still used in section 10, but= is=20 not defined anymore. By the way, I am not the kind of security expert to determine whether this= =20 applies to STUN: Many protocols and applications are now purposedly returni= ng=20 the same error code whether the username or the password/shared-secret is=20 wrong. I suppose that's meant to harden against brute-forcing. Perhaps 431 should be returned instead of 401 when the username is wrong. I= n=20 any case, the client application will handle both cases the same way, since= =20 it could be that the user mistyped his/her username so that it ends up bein= g=20 that of someone else. =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 Jul 17 10:06: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 1IAngr-00072D-Ck; Tue, 17 Jul 2007 10:06:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAngp-0006sW-LO for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 10:06:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAngn-0006pd-1v; Tue, 17 Jul 2007 10:06:09 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAngl-00018R-Nu; Tue, 17 Jul 2007 10:06:08 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6HE658W002921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Jul 2007 09:06:06 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6HE65cZ028506; Tue, 17 Jul 2007 07:06:05 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6HE64BQ028462; Tue, 17 Jul 2007 07:06:04 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 10:06:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2007 10:06:04 -0400 Message-ID: In-Reply-To: <019a01c7c80f$d8623d50$7d646b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MBONED] multiple SSM sources behind a NAT Thread-Index: AcfID9fNkx1GEPGMRDKyfIQIZRj1QwAa4ECw References: <019a01c7c80f$d8623d50$7d646b80@amer.cisco.com> From: "Manfredi, Albert E" To: "Dan Wing" , , , X-OriginalArrivalTime: 17 Jul 2007 14:06:04.0290 (UTC) FILETIME=[9CF0AE20:01C7C87B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [BEHAVE] RE: [MBONED] multiple SSM sources behind a NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 =20 > During some offline discussions, Prashant Jhingran brought up an issue > we aren't sure how to best resolve. >=20 > The problem is that if two (or more) SSM sources are on the 'inside' > of a NAT, they can choose the same multicast IP address (G). This > works fine on the 'inside' of the NAT -- they are distinguished > because their SSM channel is unique because they have different > source IP addresses (S). However, if their traffic is NATted, they > will share the same IP source address on the Internet, as in the > following diagram: >=20 > +-----+ > SSM source A -----+ | > 192.168.1.1 | NAT +------------- Internet > | |192.0.2.1 =20 > SSM source B -----+ | > 192.168.1.2 +-----+ >=20 >=20 > There seems to be only one viable approach to address this problem: My assumption was always that the only NAT readily usable for this scenario would be a 1:1 NAT. In other words, a NAT, not a NAPT. Bert _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 10:33: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 1IAo6u-0003Tq-0o; Tue, 17 Jul 2007 10:33:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAo6s-0003Tf-Lt for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 10:33:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAo6s-0003S6-9k for behave@ietf.org; Tue, 17 Jul 2007 10:33:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAo6q-0002AT-S1 for behave@ietf.org; Tue, 17 Jul 2007 10:33:06 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 17 Jul 2007 07:33:04 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIJvnEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="166953831:sNHT27365112" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6HEX473015086; Tue, 17 Jul 2007 07:33:04 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6HEX3Sb025880; Tue, 17 Jul 2007 14:33:03 GMT From: "Dan Wing" To: "'David Barrett'" , "'Henry Sinnreich'" , Date: Tue, 17 Jul 2007 07:33:02 -0700 Message-ID: <027b01c7c87f$625221a0$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <5v6mls$hf9ae@sj-inbound-e.cisco.com> Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNAAAVY8gAAAciyAAAOuUOAAFvmQ4AANY7/A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3074; t=1184682784; x=1185546784; 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:=20ICE=20performance=20 |Sender:=20; bh=Vhxn+KcOugMEoYCv1twjWHSMxrh5KCcbOr+KbFeV2hs=; b=LXduu0dk657MwKIK5iduIdkJD9EEIi3xgd36RJLbT9FMe/6T9+jyyE3t4d5wDpvw+lHBMLq9 6D96jam3Es5l/fNUXbiWM7Tdnb8lKzLGwGNKVslffHNjCUft0rv19O3t; 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: 25620135586de10c627e3628c432b04a Cc: henrys@adobe.com, baford@mit.edu, dank@kegel.com Subject: [BEHAVE] ICE performance X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (Changing subject line) > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] > Sent: Tuesday, July 17, 2007 1:04 AM > To: 'Dan Wing'; 'Henry Sinnreich'; behave@ietf.org > Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com > Subject: RE: [BEHAVE] Re: removing application milestone > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > > > What's the latency if there are no NATs involved whatsoever? Your > > numbers indicate hundreds of milliseconds for every NAT scenario, > > even for the kinds of NATs that allow connections from any IP > > address. NATs do not, on their own accord, add hundreds of > > milliseconds of delay. If they did, DNS queries would take too > > long and people would complain that "the Internet" is slow (web > > pages with lots of embedded objects on different servers). > > I'm not sure I follow. The times I gave were the elapsed ms > it took to establish the connection from start to finish. So > it'd be roughly: > > (The RTT time between A and the RZ server) + > (The processing time inside the RZ) + > (The RTT time between A and B) + > (The three-way handshake and NAT penetration time) Without any NATs, that last event (NAT penetration time) doesn't occur. I'm curious what times you have without any NATs. This would allow learning the NAT penetration time for the non-ICE NAT traversal technique you're using. > Thus in general, it takes a second or less to establish the > connection. By 'the connection', I believe you're referring to that last step (3 way handshake and NAT penetration time)? Is the 3-way handshake TCP, or is that your NAT penetration code doing a 3-way handshake? I ask because ICE does a 4-way handshake (of sorts), which is its NAT penetration. > However, once that connection has been established, > there is no additional latency introduced by the system: packets > flow between A and B directly at whatever latency is introduced > by the intermediate networks. Right. > Does this answer your question? How long does it typically > take ICE to establish a connection, including the "triggered > check" optimization? I don't know. I don't have direct experience with ICE on the Internet. I haven't seen any published information with those numbers. You may have noticed Henry asking for such information on MMUSIC and on SIP, http://www1.ietf.org/mail-archive/web/mmusic/current/msg05997.html > Is it also subsecond on average between any two points on the globe? Most of the time, yes. ICE always establishes a direct, peer-to-peer connection when it can. In some cases [such as two endpoints behind 'symmetric' NATs (RFC3489 terminology) or non-Endpoint-Independent Mapping NATs (RFC4787 terminology)] there is no reliable technique to get a direct peer-to- peer connection. The unreliable technique to establish a direct peer-to-peer connection in that situation is to guess the port number assigned by the remote NAT. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 11:13:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAok8-0007lb-02; Tue, 17 Jul 2007 11:13:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAn5r-0007wL-N7 for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 09:27:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAn5r-0007wA-Bg; Tue, 17 Jul 2007 09:27:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAn5n-0008CI-Sd; Tue, 17 Jul 2007 09:27:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Jul 2007 06:27:55 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAP5cnEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="183508638:sNHT25931313" 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 l6HDRtBt028422; Tue, 17 Jul 2007 06:27:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6HDRs6C023122; Tue, 17 Jul 2007 13:27:55 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 06:27:54 -0700 Received: from bwilliam-wxp01.cisco.com ([10.89.5.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 06:27:54 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Jul 2007 08:27:53 -0500 To: Stig Venaas , Bharat Joshi From: Beau Williamson In-Reply-To: <469C6368.1090603@uninett.no> References: <019a01c7c80f$d8623d50$7d646b80@amer.cisco.com> <1184652275.14104.83.camel@magadha> <469C6368.1090603@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jul 2007 13:27:54.0382 (UTC) FILETIME=[480C72E0:01C7C876] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1413; t=1184678875; x=1185542875; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bwilliam@cisco.com; z=From:=20Beau=20Williamson=20 |Subject:=20Re=3A=20[magma]=20Re=3A=20[MBONED]=20multiple=20SSM=20sources =20behind=20a=20NAT |Sender:=20; bh=ndDfMr9iRtgtkGqfCNqOnLdYUZAvUNO/0/wSYQktdi0=; b=fe51qF6hjzgK3k5QCIHeZoM8YBkhmw/Gg2X6mA4vttVkV+0Sir5Yg2207LjmQnHJiiWJng85 O9Qp2WD7GKu3wKSdQs2+f1J3GZZQHVUtbVypKkRcZ3SOLJxPvg+E/Mg6; Authentication-Results: sj-dkim-3; header.From=bwilliam@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Tue, 17 Jul 2007 11:13:38 -0400 Cc: "mboned@ietf.org" , "magma@ietf.org" , "behave@ietf.org" Subject: [BEHAVE] Re: [magma] Re: [MBONED] multiple SSM sources behind a NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At 01:36 AM 7/17/2007, Stig Venaas wrote: >This sounds rather ugly to me, and the behaviour may be hard to >understand for users exposed to this. I would rather have both >being forwarded and say that it's a user error to try to use the >same group for the two. That is like Marshall said, use different >groups. However, I don't think it's a good idea to modify the group >in the NAT itself since that would also probably require the >announcement of which S,G to be used to be modified, and this can be >done through methods, e.g. SDP file through HTTP or email or whatever. > >In short, I don't think you should solve this. In this not so common >situation, better let admins/users figure out that they should not >use the same G. In fact, there may be other reasons for choosing >different Gs as well (e.g. it may be good to use Gs that map to >different MAC addresses due to snooping devices and NICs). I agree with Stig on this. I don't think we want to tackle this problem. If you have multiple SSM sources behind a NAT, there are other ways to solve this such as above or the best way (IMHO) is to get more global addresses from your SP so your SSM sources can each have a unique global address. I know this isn't always easily done but I still don't think we want to solve this problem for administrators by coming up with special NAT GW behaviors. Beau Williamson _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 11:13:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAok7-0007lU-Pz; Tue, 17 Jul 2007 11:13:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAgfd-0005hX-Nx for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 02:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgfd-0005fS-0F; Tue, 17 Jul 2007 02:36:29 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAgfb-0001kM-SI; Tue, 17 Jul 2007 02:36:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id B107EB5A75; Tue, 17 Jul 2007 08:36:26 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15412-01-95; Tue, 17 Jul 2007 08:36:26 +0200 (CEST) Received: from [IPv6?2001?700?1?1100?2968?386d?3a84?946c] (unknown [IPv6:2001:700:1:1100:2968:386d:3a84:946c]) by tyholt.uninett.no (Postfix) with ESMTP id 0801BB5A73; Tue, 17 Jul 2007 08:36:25 +0200 (CEST) Message-ID: <469C6368.1090603@uninett.no> Date: Tue, 17 Jul 2007 08:36:24 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Bharat Joshi References: <019a01c7c80f$d8623d50$7d646b80@amer.cisco.com> <1184652275.14104.83.camel@magadha> In-Reply-To: <1184652275.14104.83.camel@magadha> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-Mailman-Approved-At: Tue, 17 Jul 2007 11:13:38 -0400 Cc: "mboned@ietf.org" , "magma@ietf.org" , "behave@ietf.org" , Dan Wing Subject: [BEHAVE] Re: [magma] Re: [MBONED] multiple SSM sources behind a NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Bharat Joshi wrote: > Dan, > >> The problem is that if two (or more) SSM sources are on the 'inside' >> of a NAT, they can choose the same multicast IP address (G). This >> works fine on the 'inside' of the NAT -- they are distinguished >> because their SSM channel is unique because they have different >> source IP addresses (S). However, if their traffic is NATted, they >> will share the same IP source address on the Internet, as in the >> following diagram: >> >> +-----+ >> SSM source A -----+ | >> 192.168.1.1 | NAT +------------- Internet >> | |192.0.2.1 >> SSM source B -----+ | >> 192.168.1.2 +-----+ >> >> >> There seems to be only one viable approach to address this problem: >> >> First SSM source wins and new SSM source loses. That is, when the >> number of SSM sources exceeds the number of public IP interfaces, the >> first SSM source(s) win, and the newest SSM source loses. That is, >> the newest SSM source's traffic is not forwarded towards the public >> interface. This sounds rather ugly to me, and the behaviour may be hard to understand for users exposed to this. I would rather have both being forwarded and say that it's a user error to try to use the same group for the two. That is like Marshall said, use different groups. However, I don't think it's a good idea to modify the group in the NAT itself since that would also probably require the announcement of which S,G to be used to be modified, and this can be done through methods, e.g. SDP file through HTTP or email or whatever. In short, I don't think you should solve this. In this not so common situation, better let admins/users figure out that they should not use the same G. In fact, there may be other reasons for choosing different Gs as well (e.g. it may be good to use Gs that map to different MAC addresses due to snooping devices and NICs). Stig >> >> Difficulties: >> >> - NAT can't detect that first SSM source has finished sending and >> the block should be removed, except with a timeout. How long >> should we recommend for that timeout? >> >> - We can't communicate to the losing SSM source that its SSM data >> isn't being forwarded by the NAT. >> >> - Do we want to RECOMMEND that a NAT allow the NAT administrator >> to override this behavior, and transmit multicast packets >> without regard to this problem? (This is functionally the same >> as using a timeout of 0ms). >> > > First of all, for SSM, receives MUST know the source address so that > they can subscribe to the SSM channel [A given S,G pair]. In the first > place, I would say that this would be a wrong configuration. > > If someone wants to support this and gateway does NAT, NAT device could > change the group address to something different. But there should be a > way for receivers to find out what group address NAT device chooses for > a given stream. > > Not allowing a second stream destined to same SSM group looks fine. > > I am not sure if receivers can differentiate the streams based on the > destination port [if stream is destined for one] but this will not work > if the hosts inside NAT uses the same destination port also. > > My 2 cents. > > Thanks, > Bharat > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 11:52:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApLl-0000kZ-Mv; Tue, 17 Jul 2007 11:52:33 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IApLk-0000kR-Fo for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 11:52:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApLk-0000kJ-4B for behave@ietf.org; Tue, 17 Jul 2007 11:52:32 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IApLi-0005CB-Fb for behave@ietf.org; Tue, 17 Jul 2007 11:52:32 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 08:52:26 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HFqJWs018120; Tue, 17 Jul 2007 08:52:19 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6HFqI0c012987; Tue, 17 Jul 2007 08:52:18 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 08:52:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2007 08:48:36 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA283@namail5.corp.adobe.com> In-Reply-To: <027b01c7c87f$625221a0$7d646b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE performance Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNAAAVY8gAAAciyAAAOuUOAAFvmQ4AANY7/AAAJTKGA= References: <5v6mls$hf9ae@sj-inbound-e.cisco.com> <027b01c7c87f$625221a0$7d646b80@amer.cisco.com> From: "Henry Sinnreich" To: "Dan Wing" , "David Barrett" , X-OriginalArrivalTime: 17 Jul 2007 15:52:17.0927 (UTC) FILETIME=[73EC8170:01C7C88A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: henrys@adobe.com, baford@mit.edu, dank@kegel.com Subject: [BEHAVE] RE: ICE performance X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 ask because ICE does a 4-way handshake (of sorts), which > is its NAT penetration. This is a welcome discussion and points to the fact that we have no published facts on ICE. Faith is a poor replacement for measurements. ICE differs from say SIP in that it is far more than a protocol agreement. ICE is a technology that has to deal with countless NAT implementations and scenarios, with physical reality on the net vs. getting an agreement on some protocol header or data format. Excellent role models in BEHAVE where an I-D is based on facing and measuring reality on the net are: 1. "NAT Classification Test Results" ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-jennings-behave- test-results-04.txt =20 and=20 2. "Application Design Guidelines for Traversal through Network Address Translators"=20 < ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ford-behave-app- 05.txt> which is based on test tools and real testing on the net, as reported in=20 "Peer-to-Peer Communication Across Network Address Translators"=20 http://www.brynosaurus.com/pub/net/p2pnat/=20 This is BTW the reason why I have argued to be a WG item. Dan: Is there a way to squeeze it in? To conclude; this discussion would not have taken place if we would have had deployment results for ICE. Thanks, Henry -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Tuesday, July 17, 2007 7:33 AM To: 'David Barrett'; Henry Sinnreich; behave@ietf.org Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com Subject: ICE performance=20 (Changing subject line)=20 > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com]=20 > Sent: Tuesday, July 17, 2007 1:04 AM > To: 'Dan Wing'; 'Henry Sinnreich'; behave@ietf.org > Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com > Subject: RE: [BEHAVE] Re: removing application milestone >=20 > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > >=20 > > What's the latency if there are no NATs involved whatsoever? Your > > numbers indicate hundreds of milliseconds for every NAT scenario, > > even for the kinds of NATs that allow connections from any IP > > address. NATs do not, on their own accord, add hundreds of > > milliseconds of delay. If they did, DNS queries would take too > > long and people would complain that "the Internet" is slow (web > > pages with lots of embedded objects on different servers). >=20 > I'm not sure I follow. The times I gave were the elapsed ms=20 > it took to establish the connection from start to finish. So=20 > it'd be roughly: >=20 > (The RTT time between A and the RZ server) + > (The processing time inside the RZ) + > (The RTT time between A and B) + > (The three-way handshake and NAT penetration time) Without any NATs, that last event (NAT penetration time) doesn't occur. I'm curious what times you have without any NATs. This would allow learning the NAT penetration time for the non-ICE NAT traversal technique you're using. > Thus in general, it takes a second or less to establish the=20 > connection.=20 By 'the connection', I believe you're referring to that last step (3 way handshake and NAT penetration time)? Is the 3-way handshake TCP, or is that your NAT penetration code doing a 3-way handshake? I ask because ICE does a 4-way handshake (of sorts), which is its NAT penetration. > However, once that connection has been established,=20 > there is no additional latency introduced by the system: packets=20 > flow between A and B directly at whatever latency is introduced=20 > by the intermediate networks. Right. > Does this answer your question? How long does it typically=20 > take ICE to establish a connection, including the "triggered=20 > check" optimization?=20 I don't know. I don't have direct experience with ICE on=20 the Internet. I haven't seen any published information with those numbers. You may have noticed Henry asking for such information on MMUSIC and on SIP,=20 http://www1.ietf.org/mail-archive/web/mmusic/current/msg05997.html > Is it also subsecond on average between any two points on the globe? Most of the time, yes. ICE always establishes a direct, peer-to-peer connection when it can. =20 In some cases [such as two endpoints behind 'symmetric' NATs (RFC3489 terminology) or non-Endpoint-Independent Mapping NATs (RFC4787=20 terminology)] there is no reliable technique to get a direct peer-to- peer connection. The unreliable technique to establish a direct=20 peer-to-peer connection in that situation is to guess the port number=20 assigned by the remote NAT. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 12:46: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 1IAqBp-0001Ja-9a; Tue, 17 Jul 2007 12:46:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAqBo-0001JV-Ra for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 12:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqBo-0001JJ-HX for behave@ietf.org; Tue, 17 Jul 2007 12:46:20 -0400 Received: from hm398-1.locaweb.com.br ([200.234.205.169] helo=hm398.locaweb.com.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAqBn-0006lS-Ep for behave@ietf.org; Tue, 17 Jul 2007 12:46:20 -0400 Received: (qmail 19832 invoked from network); 17 Jul 2007 16:46:15 -0000 Received: from unknown (10.1.10.10) by hm398.locaweb.com.br with QMQP; 17 Jul 2007 16:46:15 -0000 Received: from unknown (HELO ?192.168.0.216?) (guibv@comunip.com.br@201.78.67.56) by hm10.locaweb.com.br with SMTP; 17 Jul 2007 16:46:25 -0000 Message-ID: <469CF252.9010803@comunip.com.br> Date: Tue, 17 Jul 2007 13:46:10 -0300 From: Guilherme Balena Versiani Organization: ComunIP User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] ICE performance References: <027b01c7c87f$625221a0$7d646b80@amer.cisco.com> In-Reply-To: <027b01c7c87f$625221a0$7d646b80@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: behave@ietf.org, baford@mit.edu, dank@kegel.com, 'Henry Sinnreich' , henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello Dan, I run a VoIP network on Internet that uses ICE-08 for establishing peer-to-peer sessions (we are now migrating to ICE-17). This network has about 80,000 registered clients. I will add below some practical values to this discussion. Comments in-line. Dan Wing wrote: > Without any NATs, that last event (NAT penetration time) doesn't occur. I'm > curious what times you have without any NATs. This would allow learning the > NAT penetration time for the non-ICE NAT traversal technique you're using. > First, we use "Binding Discovery" (as defined in RFC 3489) to determine the minimal number of candidates to offer (the least the candidates, less time to complete). So, if the client is behind Open and Cone NATs, we do not allocate Relay candidates (we use a proprietary HTTPS Tunnel Relay, so its use is something expensive). The default "Binding Discovery" process takes so much time to complete, so we have made some optimization of the process, so now it concludes in 2.5s at most. The "Checking" time for open x open NATs (ICE-17) is about an RTT between the two peers (plus half a SIP message delay between them) -- the practical values is about 100-300ms for our current operation (as expected, you get much less time if the two peers are in the same network connections -- about 20-50ms). For the cases where a Relay candidate is needed, the total time is the negotiation time between the local host and the Relay server plus an RTT between Relay server and remote peer -- as we run an HTTPS Relay, the time is much greater than a TURN/STUN Relay server, and that time is about 1000-1300ms. There are worst cases in which the concluding time is about 1500-3500ms (it occurs occurs when the two peers are behind UDP blocked firewalls, so we need two Relays to complete the call, and in this case the audio latency is very worse than 700ms). You could expect less time than 1000-1300ms for normal TCP connections, as we have SSL plus HTTP negotiation before sending packets (this long time is due a TCP 3-way-handshake, an SSL negotiation and an HTTP request/response). For an approximation, you could divide the total value by three, so the expected time would be 350-450ms for our conditions. But these values change between implementations and network conditions, so you must expect different values around the globe. Regards, Guilherme Balena Versiani. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 13:06: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 1IAqVD-0005HA-EU; Tue, 17 Jul 2007 13:06:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAqVC-00059d-3s for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 13:06:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqVB-00059R-Oz for behave@ietf.org; Tue, 17 Jul 2007 13:06:21 -0400 Received: from www.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAqVA-0007l8-BQ for behave@ietf.org; Tue, 17 Jul 2007 13:06:21 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 575A33A02022; Tue, 17 Jul 2007 10:06:17 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 262CC3A02020 for ; Tue, 17 Jul 2007 10:06:16 -0700 (PDT) Message-ID: <469CF707.8020305@acm.org> Date: Tue, 17 Jul 2007 10:06:15 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: behave@ietf.org Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-04.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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Some comments on this draft: 1. Section 5: "Note that the first octet is always distinguishable from an unframed STUN request or response (which is always 0x00 or 0x01)." This is true only if the method is > 0x03F. STUN-07 is section 17.1 explicitly says that methods can be in the range 0x000 to 0x3FF. 2. Section 6.1.1.1: The reference to the Shared Secret request should be removed as it was removed in STUN-07. Same thing in section 6.1.1.2. 3. Section 7: CONNECT_STAT should be CONNECT-STAT. Same thing in sections 7.9 and 13.2. 4. Section 7.4: "It is padded with zeros if its length is not divisible evenly by 4 octets." STUN-7 now says (section 14) that "[t]he padding bits are ignored, and may be any value." 5. Section 7.6: The names for the bit set in the fourth paragraph (Event Port is a request...) do not match the list in the third paragraph. Nits: 1. Section 6.1.1.2: s/explict/explicit/ 2. Section 10.1.2: s/REMOTE_ADDRESS/REMOTE-ADDRESS/ 3. Section 12: s/Allcoate/Allocate/ Thanks. 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 : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) > Author(s) : J. Rosenberg, et al. > Filename : draft-ietf-behave-turn-04.txt > Pages : 40 > Date : 2007-7-12 > > This specification defines an extension of the Session Traversal > Utilities for NAT (STUN) Protocol for asking the STUN server to relay > packets towards a client. This extension, called Traversal Using > Relays around NAT (TURN), 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. -- 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 Jul 17 13:19: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 1IAqiB-0004XN-Nd; Tue, 17 Jul 2007 13:19:47 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAqiA-0004XG-IZ for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 13:19:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqiA-0004Wz-6o for behave@ietf.org; Tue, 17 Jul 2007 13:19:46 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAqi8-0008Bi-L8 for behave@ietf.org; Tue, 17 Jul 2007 13:19:46 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2007 10:19:41 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAB+XnEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="386247358:sNHT1677235212" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6HHJePh022440; Tue, 17 Jul 2007 10:19:40 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HHJXA0025468; Tue, 17 Jul 2007 17:19:34 GMT From: "Dan Wing" To: "'Guilherme Balena Versiani'" Subject: RE: [BEHAVE] ICE performance Date: Tue, 17 Jul 2007 10:19:31 -0700 Message-ID: <03bd01c7c896$a739c860$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <469CF252.9010803@comunip.com.br> Thread-Index: AcfIkgIj8SEaE/9ZQDKGYhRWYpsgXgAAhZ5A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4254; t=1184692780; x=1185556780; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20ICE=20performance |Sender:=20; bh=McVy9KsX+n2417rW5psOzCM+B0FArk7KhrEPLCxEJZo=; b=tvyE7Alfex9NhHHX4Pwtw6fjrPD5RUZ3QoInjGGpOvS5GLLGMjOyzAlX23NuR/YWYjIyTgrf t0GXKkagkfaMjPsY4LYkUD8UNyKe+vHGSYSpsWiQf2TuN59r9x5kKVVK; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: behave@ietf.org, baford@mit.edu, dank@kegel.com, 'Henry Sinnreich' , henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > I run a VoIP network on Internet that uses ICE-08 for establishing > peer-to-peer sessions (we are now migrating to ICE-17). This > network has about 80,000 registered clients. I will add below > some practical values to this discussion. Comments in-line. > > Dan Wing wrote: > > Without any NATs, that last event (NAT penetration time) > > doesn't occur. I'm > > curious what times you have without any NATs. This would > > allow learning the > > NAT penetration time for the non-ICE NAT traversal > > technique you're using. > > First, we use "Binding Discovery" (as defined in RFC 3489) to > determine the minimal number of candidates to offer (the least > the candidates, less time to complete). So, if the client is > behind Open and Cone NATs, we do not allocate Relay candidates > (we use a proprietary HTTPS Tunnel Relay, so its use is something > expensive). As an aside: (Analyzing the NAT's type is risky. For example, I am familiar with the operation of one of Cisco's NATs which, depending on exactly how ports are allocated, can appear to be a 'cone' NAT but if ports are allocated differently will be 'symmetric' (and thus will need a media relay). This specific NAT is not the sole example of this behavior in the market. But this sort of non-deterministic behavior is why we deprecated learning the style of NAT (symmetric, cone, etc.) in draft-ietf-behave-rfc3489bis. Mind you, I'm not saying "the optimization you are doing doesn't work"; I am just saying that the optimization you are doing is risky because, for some kinds of NATs in some situations, this optimization will fail to establish a connection.) > The default "Binding Discovery" process takes so much time to > complete, so we have made some optimization of the process, so > now it concludes in 2.5s at most. I am interested in how those 2.5 seconds are being consumed -- when you say 2.5 seconds, are you considering the case where you do a UDP STUN Binding Request and an HTTPS relay request? A STUN binding discovery should take roughly the same amount of time as a DNS query; less, in fact, because the STUN server has far less processing to do than a DNS caching-only server. You should be seeing something closer to 100ms, worst case, for a DSL subscriber doing a STUN Binding Discovery. If you send two STUN Binding Discovery requests (to two different servers, for example a STUN server and a TURN server) and pace those requests 20ms apart (to avoid killing a low-end NAT), this should be 120ms of wall-clock time. > The "Checking" time for open x open NATs (ICE-17) is about an RTT > between the two peers (plus half a SIP message delay between them) -- > the practical values is about 100-300ms for our current operation (as > expected, you get much less time if the two peers are in the same > network connections -- about 20-50ms). If your network has 100-300ms of round trip delay, I guess it has half that (50ms-150ms) of one-way delay, which is pretty high. > For the cases where a Relay candidate is needed, the total time is > the negotiation time between the local host and the Relay server > plus an RTT between Relay server and remote peer -- as we run an > HTTPS Relay, the time is much greater than a TURN/STUN Relay > server, and that time is about 1000-1300ms. > > There are worst cases in which the concluding time is about > 1500-3500ms (it occurs occurs when the two peers are behind UDP > blocked firewalls, so we need two Relays to complete the call, and > in this case the audio latency is very worse than 700ms). > > You could expect less time than 1000-1300ms for normal TCP > connections, as we have SSL plus HTTP negotiation before sending > packets (this long time is due a TCP 3-way-handshake, an SSL > negotiation and an HTTP request/response). For an approximation, you > could divide the total value by three, so the expected time would be > 350-450ms for our conditions. But these values change between > implementations and network conditions, so you must expect different > values around the globe. Thanks, -d > Regards, > > Guilherme Balena Versiani. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 13:30: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 1IAqsT-0006yh-IF; Tue, 17 Jul 2007 13:30:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAqsS-0006yR-KE for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 13:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqsS-0006yJ-89 for behave@ietf.org; Tue, 17 Jul 2007 13:30:24 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAqsR-00085d-PC for behave@ietf.org; Tue, 17 Jul 2007 13:30:24 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Tue, 17 Jul 2007 10:30:22 -0700 From: "David Barrett" To: "'Guilherme Balena Versiani'" , "'Dan Wing'" Subject: RE: [BEHAVE] ICE performance Date: Tue, 17 Jul 2007 10:30:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfIku4s4TvxhMvoROCbElqu6Bq1JgABKg1w In-Reply-To: <469CF252.9010803@comunip.com.br> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Message-Id: Cc: henrys@adobe.com, 'Henry Sinnreich' , behave@ietf.org, baford@mit.edu, dank@kegel.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org This is really, really fantastic. Do you have any capability to measure direct peer connectivity success rates on an individual or pairwise NAT basis (I'm assuming that at worst it'll always "work" through a relay, but I'm more interested in the direct case)? Is it above 90%? Also, I see excellent estimates and such made for the timing -- do you have any solid measurements? Basically, I've laid out the data as I've found it most valuable to obtain for my own testing purposes, and I'd *love* to see ICE's capabilities laid out in a similar fashion for direct comparison. (Or, if you have ICE connectivity/establishment-time data organized in a different way, I'd be happy to reorganize my data to match.) -david > -----Original Message----- > From: Guilherme Balena Versiani [mailto:guibv@comunip.com.br] > Sent: Tuesday, July 17, 2007 9:46 AM > To: Dan Wing > Cc: 'David Barrett'; 'Henry Sinnreich'; behave@ietf.org; henrys@adobe.com; > baford@mit.edu; dank@kegel.com > Subject: Re: [BEHAVE] ICE performance > > Hello Dan, > > I run a VoIP network on Internet that uses ICE-08 for establishing > peer-to-peer sessions (we are now migrating to ICE-17). This network has > about 80,000 registered clients. I will add below some practical values > to this discussion. Comments in-line. > > Dan Wing wrote: > > Without any NATs, that last event (NAT penetration time) doesn't occur. > I'm > > curious what times you have without any NATs. This would allow learning > the > > NAT penetration time for the non-ICE NAT traversal technique you're > using. > > > First, we use "Binding Discovery" (as defined in RFC 3489) to determine > the minimal number of candidates to offer (the least the candidates, > less time to complete). So, if the client is behind Open and Cone NATs, > we do not allocate Relay candidates (we use a proprietary HTTPS Tunnel > Relay, so its use is something expensive). The default "Binding > Discovery" process takes so much time to complete, so we have made some > optimization of the process, so now it concludes in 2.5s at most. > > The "Checking" time for open x open NATs (ICE-17) is about an RTT > between the two peers (plus half a SIP message delay between them) -- > the practical values is about 100-300ms for our current operation (as > expected, you get much less time if the two peers are in the same > network connections -- about 20-50ms). For the cases where a Relay > candidate is needed, the total time is the negotiation time between the > local host and the Relay server plus an RTT between Relay server and > remote peer -- as we run an HTTPS Relay, the time is much greater than a > TURN/STUN Relay server, and that time is about 1000-1300ms. > > There are worst cases in which the concluding time is about 1500-3500ms > (it occurs occurs when the two peers are behind UDP blocked firewalls, > so we need two Relays to complete the call, and in this case the audio > latency is very worse than 700ms). > > You could expect less time than 1000-1300ms for normal TCP connections, > as we have SSL plus HTTP negotiation before sending packets (this long > time is due a TCP 3-way-handshake, an SSL negotiation and an HTTP > request/response). For an approximation, you could divide the total > value by three, so the expected time would be 350-450ms for our > conditions. But these values change between implementations and network > conditions, so you must expect different values around the globe. > > Regards, > > Guilherme Balena Versiani. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 13:39:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAr1e-0007ku-7j; Tue, 17 Jul 2007 13:39:54 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAr1c-0007km-Ol for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 13:39:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAr1c-0007ke-Ey for behave@ietf.org; Tue, 17 Jul 2007 13:39:52 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAr1a-0008Nr-Qh for behave@ietf.org; Tue, 17 Jul 2007 13:39:52 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 17 Jul 2007 10:39:50 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFabnEarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="8991247:sNHT16643280" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6HHdoGZ007448; Tue, 17 Jul 2007 10:39:50 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6HHdn6C006246; Tue, 17 Jul 2007 17:39:49 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'David Barrett'" , Date: Tue, 17 Jul 2007 10:39:45 -0700 Message-ID: <03ef01c7c899$77b7e380$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA283@namail5.corp.adobe.com> Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNAAAVY8gAAAciyAAAOuUOAAFvmQ4AANY7/AAAJTKGAAAjAVAA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6330; t=1184693990; x=1185557990; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Re=3A=20removing=20application=20milestone |Sender:=20; bh=Tr6kfjF0UZ0l4cWWFLB/S2NZ52XP4ABk8DlYAN3PIX4=; b=OiLMeIj9vOlUpKETDRqeiW8BjqjOuJkGb6lHTvhhkXNLbMqNUhIVJEtc5JulNMUTZylJdfad 6cjQbHdNWTznqZdLNqOJTq3fwahnkJH7QMRjYeEu28zA8CslbG9bbXmzAfCHWBZOLBf2EfM3Av mNmBGKYguPfB5IBgdzv3Rf8Qw=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: henrys@adobe.com, baford@mit.edu, dank@kegel.com Subject: [BEHAVE] Re: removing application milestone X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (I adjusted the subject, because this thread is about BEHAVE's application milestone). > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Tuesday, July 17, 2007 8:49 AM > To: Dan Wing; David Barrett; behave@ietf.org > Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com > Subject: [BEHAVE] RE: ICE performance > > > I ask because ICE does a 4-way handshake (of sorts), which > > is its NAT penetration. > > This is a welcome discussion and points to the fact that we have no > published facts on ICE. Faith is a poor replacement for measurements. > > ICE differs from say SIP in that it is far more than a protocol > agreement. ICE is a technology that has to deal with countless NAT > implementations and scenarios, with physical reality on the net vs. > getting an agreement on some protocol header or data format. > > Excellent role models in BEHAVE where an I-D is based on facing and > measuring reality on the net are: > > 1. "NAT Classification Test Results" > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-jennin > gs-behave- > test-results-04.txt > > and > > 2. "Application Design Guidelines for Traversal through > Network Address > Translators" > < > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ford-b > ehave-app- > 05.txt> which is based on test tools and real testing on the net, as > reported in > > "Peer-to-Peer Communication Across Network Address Translators" > http://www.brynosaurus.com/pub/net/p2pnat/ > > This is BTW the reason why I have argued > > to be a WG item. > > Dan: Is there a way to squeeze it in? I don't believe draft-ford-behave-app-05.txt contains the same information as http://www.brynosaurus.com/pub/net/p2pnat. Rather, draft-ietf-behave-p2p-state-03.txt seems to contain the same information as http://www.brynosaurus.com/pub/net/p2pnat. draft-ietf-behave-p2p-state-03.txt is a working group item, and I expect to be issuing a WGLC in the next day or two. In Prague's BEHAVE meeting, there was consensus to not adopt draft-ford-behave-app, and there was consensus to remove our application milestone altogether, per my post on April 11: http://www1.ietf.org/mail-archive/web/behave/current/msg02128.html which had no replies on the list until Suresh's reply on July 7, http://www1.ietf.org/mail-archive/web/behave/current/msg02459.html > To conclude; this discussion would not have taken place if we > would have had deployment results for ICE. (I responded to that last point in your MMUSIC/SIP thread.) -d > Thanks, Henry > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, July 17, 2007 7:33 AM > To: 'David Barrett'; Henry Sinnreich; behave@ietf.org > Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com > Subject: ICE performance > > > (Changing subject line) > > > -----Original Message----- > > From: David Barrett [mailto:dbarrett@quinthar.com] > > Sent: Tuesday, July 17, 2007 1:04 AM > > To: 'Dan Wing'; 'Henry Sinnreich'; behave@ietf.org > > Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com > > Subject: RE: [BEHAVE] Re: removing application milestone > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > > > > What's the latency if there are no NATs involved whatsoever? Your > > > numbers indicate hundreds of milliseconds for every NAT scenario, > > > even for the kinds of NATs that allow connections from any IP > > > address. NATs do not, on their own accord, add hundreds of > > > milliseconds of delay. If they did, DNS queries would take too > > > long and people would complain that "the Internet" is slow (web > > > pages with lots of embedded objects on different servers). > > > > I'm not sure I follow. The times I gave were the elapsed ms > > it took to establish the connection from start to finish. So > > it'd be roughly: > > > > (The RTT time between A and the RZ server) + > > (The processing time inside the RZ) + > > (The RTT time between A and B) + > > (The three-way handshake and NAT penetration time) > > Without any NATs, that last event (NAT penetration time) > doesn't occur. > I'm > curious what times you have without any NATs. This would > allow learning > the > NAT penetration time for the non-ICE NAT traversal technique you're > using. > > > Thus in general, it takes a second or less to establish the > > connection. > > By 'the connection', I believe you're referring to that last > step (3 way > handshake and NAT penetration time)? > > Is the 3-way handshake TCP, or is that your NAT penetration > code doing a > 3-way handshake? I ask because ICE does a 4-way handshake (of sorts), > which > is its NAT penetration. > > > However, once that connection has been established, > > there is no additional latency introduced by the system: packets > > flow between A and B directly at whatever latency is introduced > > by the intermediate networks. > > Right. > > > Does this answer your question? How long does it typically > > take ICE to establish a connection, including the "triggered > > check" optimization? > > I don't know. I don't have direct experience with ICE on > the Internet. I haven't seen any published information with > those numbers. You may have noticed Henry asking for such > information on MMUSIC and on SIP, > http://www1.ietf.org/mail-archive/web/mmusic/current/msg05997.html > > > Is it also subsecond on average between any two points on the globe? > > Most of the time, yes. > > ICE always establishes a direct, peer-to-peer connection when > it can. > In some cases [such as two endpoints behind 'symmetric' NATs (RFC3489 > terminology) or non-Endpoint-Independent Mapping NATs (RFC4787 > terminology)] there is no reliable technique to get a direct peer-to- > peer connection. The unreliable technique to establish a direct > peer-to-peer connection in that situation is to guess the port number > assigned by the remote NAT. > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 13:56: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 1IArI0-0001rf-2j; Tue, 17 Jul 2007 13:56:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IArHy-0001im-I1 for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 13:56:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArHx-0001bu-9n for behave@ietf.org; Tue, 17 Jul 2007 13:56:45 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IArHv-0000ti-JP for behave@ietf.org; Tue, 17 Jul 2007 13:56:45 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Tue, 17 Jul 2007 10:56:40 -0700 From: "David Barrett" To: "'Dan Wing'" , "'Henry Sinnreich'" , Date: Tue, 17 Jul 2007 10:56:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNAAAVY8gAAAciyAAAOuUOAAFvmQ4AANY7/AAAbk4jA= In-Reply-To: <027b01c7c87f$625221a0$7d646b80@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Message-Id: Cc: henrys@adobe.com, baford@mit.edu, dank@kegel.com Subject: [BEHAVE] RE: ICE performance X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: Dan Wing [mailto:dwing@cisco.com] > > > > What's the latency if there are no NATs involved whatsoever? Your > > > numbers indicate hundreds of milliseconds for every NAT scenario, > > > even for the kinds of NATs that allow connections from any IP > > > address. NATs do not, on their own accord, add hundreds of > > > milliseconds of delay. If they did, DNS queries would take too > > > long and people would complain that "the Internet" is slow (web > > > pages with lots of embedded objects on different servers). > > > > I'm not sure I follow. The times I gave were the elapsed ms > > it took to establish the connection from start to finish. So > > it'd be roughly: > > > > (The RTT time between A and the RZ server) + > > (The processing time inside the RZ) + > > (The RTT time between A and B) + > > (The three-way handshake and NAT penetration time) > > Without any NATs, that last event (NAT penetration time) doesn't occur. > I'm > curious what times you have without any NATs. This would allow learning > the > NAT penetration time for the non-ICE NAT traversal technique you're using. Well, the three-way handshake needs to occur either way. So the only real difference would be the "NAT penetration time", which in practice just means "the time it takes for all the retries and voodoo to find a working route" -- the exact same algorithm is used in all configurations**, it just happens to work better/faster between some NAT pairs than others. Regardless, the specific answer to your question is "770ms" is how long it takes on average between "fullstatic" and "fullstatic" clients (ie, non-NAT'd, endpoint-independent filtering), which is about ~200ms faster than the total average of "961ms". ** I've prototyped additional optimizations for symmetric/symmetric and symmetric/rstrcone, but I don't have data on how effective those are. > By 'the connection', I believe you're referring to that last step (3 way > handshake and NAT penetration time)? > > Is the 3-way handshake TCP, or is that your NAT penetration code doing a > 3-way handshake? I ask because ICE does a 4-way handshake (of sorts), > which > is its NAT penetration. Correct, the connection is the last step. My protocol is UDP based, but does a 3-way handshake using strongly modeled off of TCP (though I find DCCP to be a great model as well). > > Does this answer your question? How long does it typically > > take ICE to establish a connection, including the "triggered > > check" optimization? > > I don't know. I don't have direct experience with ICE on > the Internet. I haven't seen any published information with > those numbers. You may have noticed Henry asking for such > information on MMUSIC and on SIP, > http://www1.ietf.org/mail-archive/web/mmusic/current/msg05997.html > > > Is it also subsecond on average between any two points on the globe? > > Most of the time, yes. Er, I don't mean to be contrarian, but without data or direct experience, how can you claim this? I think you'll find as you get real-world data and experience that all this works much slower and less reliably than you'd expect. At least, that has been my experience. Thus I'd respectfully ask that we stick to the data, and avoid (or at least label) guesswork. > ICE always establishes a direct, peer-to-peer connection when it can. Heh, this is a safe statement! > In some cases [such as two endpoints behind 'symmetric' NATs (RFC3489 > terminology) or non-Endpoint-Independent Mapping NATs (RFC4787 > terminology)] there is no reliable technique to get a direct peer-to- > peer connection. The unreliable technique to establish a direct > peer-to-peer connection in that situation is to guess the port number > assigned by the remote NAT. Correct. Does ICE support this? I haven't had great luck with it myself, but I haven't put a lot of energy into it yet. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 14:11:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArVm-0001eK-5J; Tue, 17 Jul 2007 14:11:02 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IArVk-0001e5-S7 for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:11:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArVk-0001dx-Hv for behave@ietf.org; Tue, 17 Jul 2007 14:11:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IArVj-0001HE-7r for behave@ietf.org; Tue, 17 Jul 2007 14:11:00 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2007 11:10:59 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABKjnEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="386265415:sNHT25806724" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6HIAwoF014614; Tue, 17 Jul 2007 11:10:58 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HIArA0016271; Tue, 17 Jul 2007 18:10:53 GMT From: "Dan Wing" To: "'David Barrett'" , "'Henry Sinnreich'" , Date: Tue, 17 Jul 2007 11:10:53 -0700 Message-ID: <049501c7c89d$d34da410$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <5v43jn$fp61b@sj-inbound-c.cisco.com> Thread-Index: AcfHPY8KxiowVIjfSd+OivP/BbhPqQAAvR4QACV7HNAAAVY8gAAAciyAAAOuUOAAFvmQ4AANY7/AAAbk4jAAAPP+4A== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1736; t=1184695858; x=1185559858; 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=20ICE=20performance=20 |Sender:=20; bh=mgh/CZ88HxeRFSeviz0wtOVctoCH5p/wFBa09OjJ0qA=; b=N30yxhha6G9sIkgYulHUjeQ/Fvj9+mm5Zq3Qb82SMGfMajvBXQE0wznrbzQKJEempc9hXxpY m4hMUWnXaJyoJUvPsjx12aMZOJ3GYXDrLpXMaQXOw7tIx+tFp8he4qql; 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: 8b431ad66d60be2d47c7bfeb879db82c Cc: henrys@adobe.com, baford@mit.edu, dank@kegel.com Subject: [BEHAVE] RE: ICE performance X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 it also subsecond on average between any two points on > > > the globe? > > > > Most of the time, yes. > > Er, I don't mean to be contrarian, but without data or direct > experience, how can you claim this? By analyzing the protocol. > I think you'll find as you get real-world data and experience > that all this works much slower and less reliably than you'd > expect. At least, that has been my experience. Thus I'd > respectfully ask that we stick to the data, and avoid (or at > least label) guesswork. That's fair. > > ICE always establishes a direct, peer-to-peer connection > > when it can. > > Heh, this is a safe statement! ICE doesn't perform magic; many people think it does. > > In some cases [such as two endpoints behind 'symmetric' > > NATs (RFC3489 > > terminology) or non-Endpoint-Independent Mapping NATs (RFC4787 > > terminology)] there is no reliable technique to get a > > direct peer-to- > > peer connection. The unreliable technique to establish a direct > > peer-to-peer connection in that situation is to guess the > > port number assigned by the remote NAT. > > Correct. Does ICE support this? No, ICE doesn't do that. Doing such hunting is only has a chance of success if the NAT is quiescent and if the NAT has some predictability in its UDP port assignment (assigns the next- higher port, for example). > I haven't had great luck with it myself, > but I haven't put a lot of energy into it yet. Some NAT traversal techniques (such as in some games) try to guess ports, and exchange tokens (much like ICE's usernames) to see if they're talking to the intended peer. I wouldn't recommend using that technique. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 14:24: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 1IArij-0005yl-VD; Tue, 17 Jul 2007 14:24:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IArij-0005yg-78 for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:24:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArii-0005yX-T1 for behave@ietf.org; Tue, 17 Jul 2007 14:24:24 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IArih-0002Gz-Ek for behave@ietf.org; Tue, 17 Jul 2007 14:24:24 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IArib-00055k-39; Tue, 17 Jul 2007 14:24:18 -0400 In-Reply-To: <200707171542.19726.remi.denis-courmont@nokia.com> References: <46929E54.50301@cisco.com> <200707171542.19726.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] RFC3489bis-07 now available Date: Tue, 17 Jul 2007 14:24:30 -0400 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 On 17-Jul-07, at 08:42 , R=E9mi Denis-Courmont wrote: > On Monday 09 July 2007 23:45:08 ext Jonathan Rosenberg wrote: >> RFC3489bis-07 is now available: >> http://www.ietf.org/internet-drafts/draft-ietf-behave-=20 >> rfc3489bis-07.txt > (...) >> * removal of several error codes that could only happen in >> implementation errors. > > By the way, why then does TURN define a "TCP-only operation error"? =20= > I might be > mistaken, but it feels strongly like it can only happen with a =20 > broken client > implementation. > I'll let Rohan comment on this one. >> * defined length limits on all free-form fields > > That's really appreciable! But but, the limit should most likely be =20= > expressed > in bytes rather than in characters. Otherwise, it is pretty =20 > ambiguous whether > the limit is in code points or bytes. I don't really see this. For the username, it says It MUST contain a UTF-8 encoded sequence of less than 128 characters. How is this ambiguous? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 14:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArlw-0007fB-MD; Tue, 17 Jul 2007 14:27:44 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IArlu-0007dH-2M for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArlt-0007cz-OZ for behave@ietf.org; Tue, 17 Jul 2007 14:27:41 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IArls-0002K9-CD for behave@ietf.org; Tue, 17 Jul 2007 14:27:41 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1IArlz-0006z9-EG; Tue, 17 Jul 2007 14:27:47 -0400 In-Reply-To: <200707171607.41159.remi.denis-courmont@nokia.com> References: <46929E54.50301@cisco.com> <200707171607.41159.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] RFC3489bis-07 now available Date: Tue, 17 Jul 2007 14:27:47 -0400 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 17-Jul-07, at 09:07 , R=E9mi Denis-Courmont wrote: > On Monday 09 July 2007 23:45:08 ext Jonathan Rosenberg wrote: >> * removal of several error codes that could only happen in >> implementation errors. > > Looks like 431 has been unduly removed. It is still used in section =20= > 10, but is > not defined anymore. Thanks! There were some last minute changes in this area, and a couple of =20 small errors crept in. > > By the way, I am not the kind of security expert to determine =20 > whether this > applies to STUN: Many protocols and applications are now purposedly =20= > returning > the same error code whether the username or the password/shared-=20 > secret is > wrong. I suppose that's meant to harden against brute-forcing. > > Perhaps 431 should be returned instead of 401 when the username is =20 > wrong. In > any case, the client application will handle both cases the same =20 > way, since > it could be that the user mistyped his/her username so that it ends =20= > up being > that of someone else. Or perhaps both should return a 401. Anyway, we will look at this. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 14:50:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7t-0004N0-3k; Tue, 17 Jul 2007 14:50:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAs7s-0004Mh-K7 for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7s-0004MY-Aa; Tue, 17 Jul 2007 14:50:24 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAs7q-0003b8-V8; Tue, 17 Jul 2007 14:50:24 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 11:50:19 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HIoDWs025784; Tue, 17 Jul 2007 11:50:17 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6HIoB0e007207; Tue, 17 Jul 2007 11:50:12 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:50:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2007 11:50:07 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: ICE deployment data before LC for RFC Thread-Index: AcfIoaN6k6PDRX4fSfO/54PtQP6CcQ== From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 17 Jul 2007 18:50:11.0013 (UTC) FILETIME=[4D942F50:01C7C8A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: behave@ietf.org Subject: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Following some discussions and soul searching, the best approach for ICE-17 for LC would be to _go ahead and make it an experimental RFC_. This would support the development of interoperable implementations, the collection of deployment data and also hopefully open source code. Though I have full faith in ICE, following the practices that made the IETF successful take precedent here, I believe. This is a change from the attached that I wrote on 7/16/2007. Note: We can only hope the proliferation of SBC in VoIP service provider networks will not make these concerns and ICE for SIP a moot issue, but this is another topic. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. >However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry=20 >(that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or=20 >(2) publish some deployment data showing such items as: >* NAT scenarios that have been tested, >* The % of success, >* Performance, such as call setup delay using SIP. >I have not seen any such public data on ICE deployment, for example with SIP.=20 >A private report has raised my concern about the performance of ICE. >In the best IETF tradition, it would also help to have open source code >available for ICE, before declaring it a standard. >ICE is too important for the IETF (good work Jonathan and other authors!) >not to publish=20 >(1) deployment results and (2) publish open source code as well. >The various nits discussed on the lists are only of secondary importance to >the LC=20 >compared to the above and would get resolved with such a process anyway. >These are my personal two cents. Henry Sinnreich _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 14:50:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7v-0004QX-KW; Tue, 17 Jul 2007 14:50:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAs7u-0004PT-IM for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7u-0004OX-6B; Tue, 17 Jul 2007 14:50:26 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAs7t-0003b3-NL; Tue, 17 Jul 2007 14:50:26 -0400 Received: from source ([192.150.11.134]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 11:50:18 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HIn1ot011398; Tue, 17 Jul 2007 11:49:02 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6HIoB0k007207; Tue, 17 Jul 2007 11:50:16 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:50:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2007 11:48:09 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F6@namail5.corp.adobe.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAoNGJwAAIRH/A= References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> From: "Henry Sinnreich" To: "DRAGE, Keith (Keith)" , , X-OriginalArrivalTime: 17 Jul 2007 18:50:15.0060 (UTC) FILETIME=[4FFDB540:01C7C8A3] X-Spam-Score: 0.5 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: behave@ietf.org Subject: [BEHAVE] RE: [MMUSIC] ICE deployment data before LC for RFC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Keith, Thanks for the attention and sorry our mail has crossed. Feel free to proceed as you best think. (I have made my point as well). Henry -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Tuesday, July 17, 2007 10:56 AM To: Henry Sinnreich; mmusic@ietf.org; sip@ietf.org Cc: Cullen Jennings; jon.peterson@neustar.biz Subject: RE: [MMUSIC] ICE deployment data before LC for RFC As SIP WG chair and the document shepherd for draft-ietf-sip-ice-option-tag this is what I shall be doing with regard to the ancillary document in this process... I went to RFC 2026 and carefully read the section on proposed standard: 4.1.1 Proposed Standard The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. My judgement is that at least the in terms of its draft, the SIP WG has fulfilled the requirements for a request to publish a proposed standard. It appears to me that any further decision about implementation rests with the IESG, who should obviously take into account any submissions made during the IESG last call process. It is therefore my intent to proceed with the publish request for draft-ietf-sip-ice-option-tag. Regards Keith ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, July 16, 2007 11:38 PM To: mmusic@ietf.org; sip@ietf.org Cc: Cullen Jennings; jon.peterson@neustar.biz Subject: [MMUSIC] ICE deployment data before LC for RFC =09 =09 The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. =20 However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry (that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or (2) publish some deployment data showing such items as: =20 * NAT scenarios that have been tested,=20 * The % of success,=20 * Performance, such as call setup delay using SIP.=20 =20 I have not seen any such public data on ICE deployment, for example with SIP. A private report has raised my concern about the performance of ICE. =20 In the best IETF tradition, it would also help to have open source code available for ICE, before declaring it a standard. =20 ICE is too important for the IETF (good work Jonathan and other authors!) not to publish (1) deployment results and (2) publish open source code as well. The various nits discussed on the lists are only of secondary importance to the LC compared to the above and would get resolved with such a process anyway. =20 These are my personal two cents. Henry Sinnreich =09 =09 =09 =20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 16:48: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 1IAtxx-0000TJ-Dg; Tue, 17 Jul 2007 16:48:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAtxw-0000TD-81 for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 16:48:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAtxv-0000T4-A0 for behave@ietf.org; Tue, 17 Jul 2007 16:48:15 -0400 Received: from hm398-1.locaweb.com.br ([200.234.205.169] helo=hm398.locaweb.com.br) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAtxs-00073n-QI for behave@ietf.org; Tue, 17 Jul 2007 16:48:14 -0400 Received: (qmail 8933 invoked from network); 17 Jul 2007 20:48:08 -0000 Received: from unknown (10.1.10.10) by hm398.locaweb.com.br with QMQP; 17 Jul 2007 20:48:08 -0000 Received: from unknown (HELO ?192.168.0.216?) (guibv@comunip.com.br@201.78.67.56) by hm10.locaweb.com.br with SMTP; 17 Jul 2007 20:48:19 -0000 Message-ID: <469D2B03.3040002@comunip.com.br> Date: Tue, 17 Jul 2007 17:48:03 -0300 From: Guilherme Balena Versiani Organization: ComunIP User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] ICE performance References: <03bd01c7c896$a739c860$7d646b80@amer.cisco.com> In-Reply-To: <03bd01c7c896$a739c860$7d646b80@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: behave@ietf.org, baford@mit.edu, dank@kegel.com, 'Henry Sinnreich' , henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Comments in-line. Dan Wing wrote: > As an aside: > > (Analyzing the NAT's type is risky. For example, I am familiar > with the operation of one of Cisco's NATs which, depending on > exactly how ports are allocated, can appear to be a 'cone' NAT but > if ports are allocated differently will be 'symmetric' (and thus > will need a media relay). This specific NAT is not the sole example > of this behavior in the market. But this sort of non-deterministic > behavior is why we deprecated learning the style of NAT (symmetric, > cone, etc.) in draft-ietf-behave-rfc3489bis. Mind you, I'm not > saying "the optimization you are doing doesn't work"; I am just > saying that the optimization you are doing is risky because, for > some kinds of NATs in some situations, this optimization will fail > to establish a connection.) > OK, I know I am running against the current way of BEHAVE and MMUSIC. I know there are known issues in "Binding Discovery" usage, but I just let the market respond. Until now, for the current user profiles, I don't have a substantial problem. I just can't let the clients open an HTTPS Relay connection for all calls. It is overkill. > I am interested in how those 2.5 seconds are being consumed -- > when you say 2.5 seconds, are you considering the case where > you do a UDP STUN Binding Request and an HTTPS relay request? > This time is consumed during the "Binding Discovery" usage, as defined in RFC 3489 Section 10.1, and that I meant to be the "default" discovery process. If you follow the flow described there, for example, you could get 4 * T, where T is the STUN transaction time, for Restricted/Port Restricted Cones. I think this could be of some interest of the current work: I developed a new flow to discover the NAT type, so I get the result in less time, based on the old draft-takeda-symmetric-nat-traversal-00.txt. The new flow is as follow: Test I ----\ /---- Try A Test II ----+---+---- Try B Test III ----/ \---- Try C After sending these requests I check the results and then I can determine the NAT type. The Test I, Test II and Test III have CHANGE-REQUEST "0b00" (no change), "0b10" (change IP), "0b11" (change IP and change port) respectivelly. The Try A, Try B and Try C have CHANGE-REQUEST "0b00" (no change). Then, the worst case is 2 * T instead of 4 * T. I check the results using the following flow: +----------------+ N | Test I worked? |-----> Blocked +-------+--------+ | Y +---> Open V Y | +-------------+ Y +-------+---------+ N | IP same? |------->| Test II worked? |----> Sym Firewall +-----+-------+ +-----------------+ | N V +-----------------+ N +------------------+ | Test II worked? |---->| Test III worked? |----> Port Sensitive +-----+-----------+ +--------+---------+ Filter | Y | V V No Filter Address Sensitive Filter For the last three types (No filter, Address Sensitive, Port Sensitive), I get the four allocated ports and name them as p0, p1, p2 and p3 for the MAPPED-ADDRESS (or XOR-MAPPED-ADDRESS as defined in 'bis') of Test I, Try A, Try B, and Try C respectively. Then a follow this flow: +-----------------------------------+ Y | p0 == p1 && p1 == p2 && p2 == p3? |----> Cone +-----------+-----------------------+ | N V +----------------------------------+ Y | p0 == p2 && p1 == p3 && p0 != p1 |-----> Exceptional +-----------+----------------------+ Behavior | N V +----------------------------------+ Y | p0 == p1 && p1 == p2 && p2 != p3 |-----> Address Sensitive +-----------+----------------------+ Allocation | N V Port Sensitive Allocation Them I use the Table 6.3.1 in draft-takeda-symmetric-nat-traversal-00.txt to determine the NAT type: +----------------------+-----------------------------------+ | | Incoming Packet Filter | | |-----------------------------------| | | No Filter | AS Filter | PS Filter | +----------+-----------+-----------+-----------+-----------+ | | Cone | Full-cone |Restricted-|Port restr-| | Port | | |cone |icted-cone | |Allocation|-----------+-----------+-----------+-----------| | Rule | AS | Symmetric | Symmetric | Symmetric | | | Symmetric | (a) | (b) | (c) | | |-----------+-----------+-----------+-----------| | | PS | Symmetric | Symmetric | Symmetric | | | Symmetric | (d) | (e) | (f) | +----------------------+-----------------------------------+ AS: Address Sensitive, PS: Port Sensitive The way described above is a more robust solution than described in RFC 3489, and is capable to detect a known issue in Linux NAT boxes (this was written by Remi Denis-Courmont/Nokia): "FYI, my personal experience with Linux/NetFilter was that it also showed this symmetric behavior on an almost systematic basis when the firewall part of NetFilter was configured to "accept" unexpected UDP traffic from the outside, and that traffic happened to have the allocated port as a destination. Linux would then reject the packet with ICMP Port Unreachable and record a conflicting association of this port with itself (ie. the NAT box) as a destination, instead of the user behind the NAT." BTW, *the normal use of RFC 3489 detects this type of NAT as Port Restricted*! > A STUN binding discovery should take roughly the same amount > of time as a DNS query; less, in fact, because the STUN server > has far less processing to do than a DNS caching-only server. > I didn't compute the DNS resolution time. > You should be seeing something closer to 100ms, worst case, for a > DSL subscriber doing a STUN Binding Discovery. If you send two > STUN Binding Discovery requests (to two different servers, for > example a STUN server and a TURN server) and pace those requests > 20ms apart (to avoid killing a low-end NAT), this should be 120ms > of wall-clock time. > Yes, but the clients are distributed around many providers, so the STUN servers aren't so close to clients. The 150-300ms is a mean time for "outside clients" (if you are in the same provider as the STUN server, you would get less times). > If your network has 100-300ms of round trip delay, I guess it has > half that (50ms-150ms) of one-way delay, which is pretty high. > Yes, as I said, this value represents the "outside providers" around the globe. And the values varies for different networks and locations, so there are no "standard values". Regards, Guilherme Balena Versiani. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 16:58: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 1IAu89-0008Kv-Od; Tue, 17 Jul 2007 16:58:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAu89-0008K9-4i for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 16:58:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAu88-0008G8-QA for behave@ietf.org; Tue, 17 Jul 2007 16:58:48 -0400 Received: from hm398-1.locaweb.com.br ([200.234.205.169] helo=hm398.locaweb.com.br) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAu86-0007LO-S3 for behave@ietf.org; Tue, 17 Jul 2007 16:58:48 -0400 Received: (qmail 9536 invoked from network); 17 Jul 2007 20:58:44 -0000 Received: from unknown (10.1.10.10) by hm398.locaweb.com.br with QMQP; 17 Jul 2007 20:58:44 -0000 Received: from unknown (HELO ?192.168.0.216?) (guibv@comunip.com.br@201.78.67.56) by hm10.locaweb.com.br with SMTP; 17 Jul 2007 20:58:55 -0000 Message-ID: <469D2D7F.8040309@comunip.com.br> Date: Tue, 17 Jul 2007 17:58:39 -0300 From: Guilherme Balena Versiani Organization: ComunIP User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: David Barrett Subject: Re: [BEHAVE] ICE performance Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: behave@ietf.org, baford@mit.edu, dank@kegel.com, 'Henry Sinnreich' , 'Dan Wing' , henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Comments in-line. David Barrett wrote: > This is really, really fantastic. Do you have any capability to measure > direct peer connectivity success rates on an individual or pairwise NAT > basis (I'm assuming that at worst it'll always "work" through a relay, but > I'm more interested in the direct case)? Is it above 90%? > I have this capability, but this is not implemented yet in the current version (production) to collect the data. I expect to start the "real-time" collecting work in the next release and then I could share more precise data for these subjects (Open x Open, Sym x Sym, etc). > Also, I see excellent estimates and such made for the timing -- do you have > any solid measurements? > Just a parenthesis: is there any "formal" procedure to collect the data? I'm thinking to get relevant NAT type data from SDP and do a simple counting. How do you collected your data? Regards, Guilherme Balena Versiani. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 17:22: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 1IAuUy-0007VJ-KS; Tue, 17 Jul 2007 17:22:24 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAuUw-0007UK-Sb for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 17:22:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAuUu-0007SY-G6; Tue, 17 Jul 2007 17:22:22 -0400 Received: from [80.81.115.248] (helo=soportemv.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAuUo-00082B-Aq; Tue, 17 Jul 2007 17:22:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [BEHAVE] Re: [magma] Re: [MBONED] multiple SSM sources behind a NAT X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 17 Jul 2007 23:17:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: [magma] Re: [MBONED] multiple SSM sources behind a NAT Thread-Index: AcfIhRT1mfWnAfBtS0CqoSibEJf5PwAMtM2y References: <019a01c7c80f$d8623d50$7d646b80@amer.cisco.com><1184652275.14104.83.camel@magadha> <469C6368.1090603@uninett.no> From: "Alvaro Fernandez" To: "Beau Williamson" , "Stig Venaas" , "Bharat Joshi" X-Spam-Score: 0.6 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: mboned@ietf.org, magma@ietf.org, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1059220546==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1059220546== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C8B8.6CD980A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C8B8.6CD980A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 A very simple solution: =20 Multicast senders can choose the multicast group from 224.0.0.0 to = 239.255.255.255. =20 A simple solution is to recommend (ietf draft) multicast sender to use = groups in the form: xxx.yyy.zzz.xxx where the user can choose x and =20 1) yyy.zzz are the last two bytes of the internal IP address. (for = example 192.168.yyy.zzz) =20 Or another solution (when using more than one NAPT): =20 2) yyy is the last byte of the internal IP address and zzz is the = public IP address. =20 note that SSM range is shorter than ASM. =20 Regards Alvaro ________________________________ De: Beau Williamson [mailto:bwilliam@cisco.com] Enviado el: mar 17/07/2007 15:27 Para: Stig Venaas; Bharat Joshi CC: mboned@ietf.org; magma@ietf.org; behave@ietf.org Asunto: [BEHAVE] Re: [magma] Re: [MBONED] multiple SSM sources behind a = NAT At 01:36 AM 7/17/2007, Stig Venaas wrote: >This sounds rather ugly to me, and the behaviour may be hard to >understand for users exposed to this. I would rather have both >being forwarded and say that it's a user error to try to use the >same group for the two. That is like Marshall said, use different >groups. However, I don't think it's a good idea to modify the group >in the NAT itself since that would also probably require the >announcement of which S,G to be used to be modified, and this can be >done through methods, e.g. SDP file through HTTP or email or whatever. > >In short, I don't think you should solve this. In this not so common >situation, better let admins/users figure out that they should not >use the same G. In fact, there may be other reasons for choosing >different Gs as well (e.g. it may be good to use Gs that map to >different MAC addresses due to snooping devices and NICs). I agree with Stig on this. I don't think we want to tackle this problem. If you have multiple SSM sources behind a NAT, there are other ways to solve this such as above or the best way (IMHO) is to get more global addresses from your SP so your SSM sources can each have a unique global address. I know this isn't always easily done but I still don't think we want to solve this problem for administrators by coming up with special NAT GW behaviors. Beau Williamson=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave ------_=_NextPart_001_01C7C8B8.6CD980A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BEHAVE] Re: [magma] Re: [MBONED] multiple = SSM sources behind a NAT=0A= =0A= =0A= =0A=
=0A=
=0A=

Hello,

=0A=

 

=0A=

A very simple solution:

=0A=

 

=0A=

Multicast senders can choose the multicast group from = 224.0.0.0 to 239.255.255.255.

=0A=

 

=0A=

A simple solution is to recommend (ietf draft) multicast = sender to use groups in the form: xxx.yyy.zzz.xxx where the user can = choose x and

=0A=

 

=0A=

1)      = yyy.zzz are the last two bytes of the internal IP = address. (for example = 192.168.yyy.zzz)

=0A=

 

=0A=

Or another solution (when using more than one = NAPT):

=0A=

 

=0A=

2)      = yyy is the last byte of the internal IP address = and zzz is the public IP address.

=0A=

 

=0A=

note that SSM range is shorter than = ASM.

=0A=

 

=0A=

Regards

=0A=


Alvaro

=0A=

=0A=
=0A= De: Beau Williamson = [mailto:bwilliam@cisco.com]
Enviado el: mar 17/07/2007 = 15:27
Para: Stig Venaas; Bharat Joshi
CC: = mboned@ietf.org; magma@ietf.org; behave@ietf.org
Asunto: = [BEHAVE] Re: [magma] Re: [MBONED] multiple SSM sources behind a = NAT

=0A=
=0A=

At 01:36 AM 7/17/2007, Stig Venaas wrote:
>This = sounds rather ugly to me, and the behaviour may be hard = to
>understand for users exposed to this. I would rather have = both
>being forwarded and say that it's a user error to try to use = the
>same group for the two. That is like Marshall said, use = different
>groups. However, I don't think it's a good idea to = modify the group
>in the NAT itself since that would also probably = require the
>announcement of which S,G to be used to be modified, = and this can be
>done through methods, e.g. SDP file through HTTP = or email or whatever.
>
>In short, I don't think you should = solve this. In this not so common
>situation, better let = admins/users figure out that they should not
>use the same G. In = fact, there may be other reasons for choosing
>different Gs as = well (e.g. it may be good to use Gs that map to
>different MAC = addresses due to snooping devices and NICs).

I agree with Stig on = this.  I don't think we want to tackle this
problem.  If = you have multiple SSM sources behind a NAT, there are
other ways to = solve this such as above or the best way (IMHO) is to
get more global = addresses from your SP so your SSM sources can each
have a unique = global address.   I know this isn't always easily done
but = I still don't think we want to solve this problem for
administrators = by coming up with special NAT GW behaviors.

Beau = Williamson 


_____________________________________________= __
Behave mailing list
Behave@ietf.org
https://www1.ietf.= org/mailman/listinfo/behave

------_=_NextPart_001_01C7C8B8.6CD980A0-- --===============1059220546== 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 --===============1059220546==-- From behave-bounces@ietf.org Tue Jul 17 17:22: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 1IAuVM-0000KT-3M; Tue, 17 Jul 2007 17:22:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAuVK-0000DR-LB for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 17:22:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAuVJ-0000Au-PT for behave@ietf.org; Tue, 17 Jul 2007 17:22:45 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAuVI-00083L-GE for behave@ietf.org; Tue, 17 Jul 2007 17:22:45 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 14:22:38 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HLL7ot011140; Tue, 17 Jul 2007 14:21:07 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HLKPIT024042; Tue, 17 Jul 2007 14:20:29 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 14:22:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] ICE performance Date: Tue, 17 Jul 2007 14:22:06 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED4F7@namail5.corp.adobe.com> In-Reply-To: <469D2D7F.8040309@comunip.com.br> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] ICE performance Thread-Index: AcfItUcv5glqvEO7QLS4hSpE2kuWcgAAtjyA References: <469D2D7F.8040309@comunip.com.br> From: "Henry Sinnreich" To: "Guilherme Balena Versiani" , "David Barrett" X-OriginalArrivalTime: 17 Jul 2007 21:22:16.0895 (UTC) FILETIME=[8D0744F0:01C7C8B8] X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: henrys@adobe.com, baford@mit.edu, behave@ietf.org, Dan Wing , dank@kegel.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > How do you collect your data? Sorry for the probably duplicate information, but an impressive way and tool to collect the data is described in http://www.brynosaurus.com/pub/net/p2pnat/=20 Henry -----Original Message----- From: Guilherme Balena Versiani [mailto:guibv@comunip.com.br]=20 Sent: Tuesday, July 17, 2007 1:59 PM To: David Barrett Cc: 'Dan Wing'; Henry Sinnreich; behave@ietf.org; henrys@adobe.com; baford@mit.edu; dank@kegel.com Subject: Re: [BEHAVE] ICE performance Comments in-line. David Barrett wrote: > This is really, really fantastic. Do you have any capability to measure > direct peer connectivity success rates on an individual or pairwise NAT > basis (I'm assuming that at worst it'll always "work" through a relay, but > I'm more interested in the direct case)? Is it above 90%? > =20 I have this capability, but this is not implemented yet in the current=20 version (production) to collect the data. I expect to start the=20 "real-time" collecting work in the next release and then I could share=20 more precise data for these subjects (Open x Open, Sym x Sym, etc). > Also, I see excellent estimates and such made for the timing -- do you have > any solid measurements? > =20 Just a parenthesis: is there any "formal" procedure to collect the data? I'm thinking to get relevant NAT type data from SDP and do a simple=20 counting. How do you collected your data? Regards, Guilherme Balena Versiani. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 17:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAuWV-00032e-Mk; Tue, 17 Jul 2007 17:23:59 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAuWU-00032Z-UD for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 17:23:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAuWU-00032R-K4 for behave@ietf.org; Tue, 17 Jul 2007 17:23:58 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAuWS-000861-49 for behave@ietf.org; Tue, 17 Jul 2007 17:23:58 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Tue, 17 Jul 2007 14:23:52 -0700 From: "David Barrett" To: "'Guilherme Balena Versiani'" Subject: RE: [BEHAVE] ICE performance Date: Tue, 17 Jul 2007 14:23:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfItUlvmJ4oKyrgQWCL6QpustjqtAAAoFdA In-Reply-To: <469D2D7F.8040309@comunip.com.br> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Message-Id: Cc: behave@ietf.org, baford@mit.edu, dank@kegel.com, 'Henry Sinnreich' , 'Dan Wing' , henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Guilherme Balena Versiani [mailto:guibv@comunip.com.br] > Subject: Re: [BEHAVE] ICE performance > > > I have this capability, but this is not implemented yet in the current > version (production) to collect the data. I expect to start the > "real-time" collecting work in the next release and then I could share > more precise data for these subjects (Open x Open, Sym x Sym, etc). Awesome. I look forward to the results. > Just a parenthesis: is there any "formal" procedure to collect the data? > I'm thinking to get relevant NAT type data from SDP and do a simple > counting. How do you collected your data? I've done it a couple different ways, but in general the best I've found is to simply have a server to which clients upload a success/failure report after each peer connection attempt, generally including: - My NAT type - The peer's NAT type - My unique ID - The peer's unique ID - Did I succeed? - How long did it take to connect? Then, dump all this data into a simple RDBMS and run queries against it, such as: select fromnat, count(*), avg(success), avg(opentime) from peerconnectivity group by fromnat; select fromnat, tonat, count(*), avg(success), avg(opentime) from peerconnectivity group by fromnat, tonat; That'll spit out tables across each NAT type, and each combination. Does this make sense? -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 17 20:24: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 1IAxLY-0007YU-VI; Tue, 17 Jul 2007 20:24:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IAsGD-0000Ux-Q3 for behave-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:59:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsGD-0000UY-5d; Tue, 17 Jul 2007 14:59:01 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAsGC-0003v1-NJ; Tue, 17 Jul 2007 14:59:01 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6HIww9H004652; Tue, 17 Jul 2007 13:58:58 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 13:58:58 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 20:58:56 +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: Tue, 17 Jul 2007 20:58:55 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014366C2@DEEXC1U01.de.lucent.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F6@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAoNGJwAAIRH/AAADGJEA== References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F6@namail5.corp.adobe.com> From: "DRAGE, Keith \(Keith\)" To: "Henry Sinnreich" , , X-OriginalArrivalTime: 17 Jul 2007 18:58:56.0655 (UTC) FILETIME=[86E2C9F0:01C7C8A4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.5 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 X-Mailman-Approved-At: Tue, 17 Jul 2007 20:24:52 -0400 Cc: behave@ietf.org Subject: [BEHAVE] RE: [MMUSIC] ICE deployment data before LC for RFC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org A further word on this. Attempting to do any status change is going to create all sorts of downreferencing problems, which while not unresolvable, will certainly delay getting this out. In order to register a new SIP option tag, draft-ietf-sip-ice-option-tag must be a standards track document. RFC 3427 mandates this. Draft-ietf-sip-ice-option-tag normatively references draft-ietf-mmusic-ice. If the former is standards track and the latter is either informational or experimental, I understand that would be a down reference.=20 I was unable to fire up the reference dependency tool to find out what other intended standards track documents normatively referenced draft-ietf-mmusic-ice, but I suspect there are a number. I would therefore suggest you investigate the potential referencing impact further if you wish to proceed. Regards Keith > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Tuesday, July 17, 2007 7:48 PM > To: DRAGE, Keith (Keith); mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz; behave@ietf.org > Subject: RE: [MMUSIC] ICE deployment data before LC for RFC >=20 > Keith, >=20 > Thanks for the attention and sorry our mail has crossed. >=20 > Feel free to proceed as you best think. (I have made my point=20 > as well). >=20 > Henry >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Tuesday, July 17, 2007 10:56 AM > To: Henry Sinnreich; mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz > Subject: RE: [MMUSIC] ICE deployment data before LC for RFC >=20 > As SIP WG chair and the document shepherd for=20 > draft-ietf-sip-ice-option-tag this is what I shall be doing=20 > with regard to the ancillary document in this process... >=20 > I went to RFC 2026 and carefully read the section on proposed=20 > standard: >=20 >=20 > 4.1.1 Proposed Standard >=20 > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. >=20 > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood,=20 > has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. >=20 > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. >=20 > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. >=20 > A Proposed Standard should have no known technical omissions with > respect to the requirements placed upon it. However, the IESG may > waive this requirement in order to allow a specification to advance > to the Proposed Standard state when it is considered to be=20 > useful and > necessary (and timely) even with known technical omissions. >=20 > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. >=20 > My judgement is that at least the in terms of its draft, the=20 > SIP WG has fulfilled the requirements for a request to=20 > publish a proposed standard. > It appears to me that any further decision about=20 > implementation rests with the IESG, who should obviously take=20 > into account any submissions made during the IESG last call process. >=20 > It is therefore my intent to proceed with the publish request=20 > for draft-ietf-sip-ice-option-tag. >=20 > Regards >=20 > Keith >=20 >=20 > ________________________________ >=20 > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Monday, July 16, 2007 11:38 PM > To: mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz > Subject: [MMUSIC] ICE deployment data before LC for RFC > =09 > =09 >=20 > The work on ICE is truly impressive and so are the=20 > numerous I-Ds associated with ICE. >=20 > =20 >=20 > However, before sending the I-D for LC to the=20 > IESG, it would be prudent and responsible to the industry=20 > (that spends considerable resources on ICE in good faith)=20 > implementing ICE, to either > (1) make it an informational RFC or (2) publish some=20 > deployment data showing such items as: >=20 > =20 >=20 > * NAT scenarios that have been tested,=20 > * The % of success,=20 > * Performance, such as call setup delay using SIP.=20 >=20 > =20 >=20 > I have not seen any such public data on ICE deployment,=20 > for example with SIP. A private report has raised my concern=20 > about the performance of ICE. >=20 > =20 >=20 > In the best IETF tradition, it would also help to have=20 > open source code available for ICE, before declaring it a standard. >=20 > =20 >=20 > ICE is too important for the IETF (good work Jonathan and other > authors!) not to publish (1) deployment results and (2)=20 > publish open source code as well. >=20 > The various nits discussed on the lists are only of=20 > secondary importance to the LC compared to the above and=20 > would get resolved with such a process anyway. >=20 > =20 >=20 > These are my personal two cents. >=20 > Henry Sinnreich > =09 > =09 > =09 >=20 > =20 >=20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 02:46: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 1IB3IS-000475-E6; Wed, 18 Jul 2007 02:46:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IB3IN-0003wh-9k for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 02:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB3IJ-0003kV-KA for behave@ietf.org; Wed, 18 Jul 2007 02:45:55 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB3IJ-0005Ic-5d for behave@ietf.org; Wed, 18 Jul 2007 02:45:55 -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 l6I6jd0r015626; Wed, 18 Jul 2007 09:45:50 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:45:49 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:45:49 +0300 Received: from esdhcp05132.research.nokia.com ([172.21.51.32]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:45:48 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Philip Matthews" , Behave WG , ext Jonathan Rosenberg , Dan Wing Subject: Re: [BEHAVE] RFC3489bis-07 now available Date: Wed, 18 Jul 2007 09:45:45 +0300 User-Agent: KMail/1.9.6 References: <46929E54.50301@cisco.com> <200707171542.19726.remi.denis-courmont@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707180945.46590.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 18 Jul 2007 06:45:48.0799 (UTC) FILETIME=[467E60F0:01C7C907] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 17 July 2007 21:24:30 you wrote: > >> * defined length limits on all free-form fields > > > > That's really appreciable! But but, the limit should most likely be > > expressed > > in bytes rather than in characters. Otherwise, it is pretty > > ambiguous whether > > the limit is in code points or bytes. > > I don't really see this. > For the username, it says > It MUST contain a > UTF-8 encoded sequence of less than 128 characters. > How is this ambiguous? To re-iterate the question, does "character" mean "code point" or "byte"? I= t=20 is totally ambiguous. To me, a UTF-8 encoded sequence of less than 128 characters is up to=20 (128-1)*6+1=3D763 bytes, counting the terminating nul (and that's a bit big= ,=20 IMHO). To most implementors it's going to be 127(+1) bytes. I would much rather have: It MUST contain a valid UTF-8 encoded sequence of less than 128 bytes. =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 Jul 18 03:40: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 1IB48l-0006WS-5I; Wed, 18 Jul 2007 03:40:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IB48j-0006WI-HS for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 03:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB48j-0006W7-5t for behave@ietf.org; Wed, 18 Jul 2007 03:40:05 -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 1IB48h-0006ok-MY for behave@ietf.org; Wed, 18 Jul 2007 03:40:05 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6I7dP5c022275; Wed, 18 Jul 2007 10:39:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:39:49 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:39:48 +0300 Received: from esdhcp05132.research.nokia.com ([172.21.51.32]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:39:48 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] ICE performance Date: Wed, 18 Jul 2007 10:39:45 +0300 User-Agent: KMail/1.9.6 References: <03bd01c7c896$a739c860$7d646b80@amer.cisco.com> <469D2B03.3040002@comunip.com.br> In-Reply-To: <469D2B03.3040002@comunip.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707181039.45588.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 18 Jul 2007 07:39:48.0310 (UTC) FILETIME=[D1648760:01C7C90E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 'Henry Sinnreich' , dank@kegel.com, baford@mit.edu, Dan Wing , henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 17 July 2007 23:48:03 ext Guilherme Balena Versiani wrote: > The way described above is a more robust solution than described in RFC > 3489, and is capable to detect a known issue in Linux NAT boxes (this > was written by Remi Denis-Courmont/Nokia): > > "FYI, my personal experience with Linux/NetFilter was that it also showed > this symmetric behavior on an almost systematic basis when the firewall > part of NetFilter was configured to "accept" unexpected UDP traffic from > the outside, and that traffic happened to have the allocated port as a > destination. Linux would then reject the packet with ICMP Port > Unreachable and record a conflicting association of this port with > itself (ie. the NAT box) as a destination, instead of the user behind > the NAT." I did write this. Note though that this is collected from running the Tered= o=20 qualification procedure (RFC4380), rather than classic STUN (RFC3489). The major practical problem with NAT type checks that I've had is that it=20 incorrectly return "cone" if the procedure is re-run too quickly, such as i= f=20 the application is restarted. > BTW, *the normal use of RFC 3489 detects this type of NAT as Port > Restricted*! If you used ICE, you would not care. However, if you used ICE, it might or= =20 might not work depending on the timing of each side's connectivity checks.= =20 The problem here is, when sending connectivity checks, you punch a hole in= =20 your NAT, but you may confuse the other side's NAT (particularly if it is a= n=20 ICMP-sending NAT). To have it (almost) always work with these annoying ICMP-sending NATs, you'= d=20 have to punch holes into your own NAT in a way that does not interfere with= =20 the peer's NAT, first. Once both sides have taken care of their own NAT, th= ey=20 would then actually start the real connectivity checks. That looks nice on the paper. Unfortunately, it is not that easy. One way=20 would consist of sending connectivity checks with synchronically increasing= =20 TTL values, but that would be terribly slow, unless you know exactly how ma= ny=20 hops away your outermost NAT/firewall is. There are ways to determine this.= =20 =46or instance, you could send packets increasing TTL to a STUN or Teredo=20 server's other address, then a Binding Request with the change-address fla= g=20 to the main address, until you receive a response. I have never tested this, and I would expect this may either be impractical= =20 and/or break other types of NATs. Misconfigured Linux NATs are probably not= =20 the most common case. =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 Jul 18 04:10: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 1IB4cT-0001gW-Dg; Wed, 18 Jul 2007 04:10:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IB4cR-0001fj-Qj for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 04:10:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4cR-0001f5-2L; Wed, 18 Jul 2007 04:10:47 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IB4cP-0000Th-2l; Wed, 18 Jul 2007 04:10:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4F5D1215D8; Wed, 18 Jul 2007 10:10:44 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-61-469dcb042312 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 27FA6204A6; Wed, 18 Jul 2007 10:10:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:10:43 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:10:43 +0200 Message-ID: <469DCB03.9040300@ericsson.com> Date: Wed, 18 Jul 2007 10:10:43 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 08:10:43.0584 (UTC) FILETIME=[2338E000:01C7C913] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org, behave@ietf.org, mmusic@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 Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. > > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. > > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. > > This is a change from the attached that I wrote on 7/16/2007. > > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. Henry, I don't quite understand why you are requesting a status change of ICE? To me it appears that ICE is almost finished spec. It has been implemented, used and feedback has been influencing the protocol. It is definitly one of the better examples of current IETF work that actually has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE works in the intended core cases. If there are some corner cases where it fails, that may be. But that is not information we will have until really large scale deployement or someone makes very extensive tests. I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. And to be clear, proposed standard is allowed to be published without a single implementation exists. It might not be good practice, but it is allowed by our process. And as I said before ICE has had enough implementation that I am very confortable in balloting YES for it when it appears on the IESGs table. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 10:20: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 1IBAOX-0000R2-Bx; Wed, 18 Jul 2007 10:20:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBAOU-0000GI-Tr for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 10:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAOT-0000ED-Ta; Wed, 18 Jul 2007 10:20:45 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAOS-0002QK-2I; Wed, 18 Jul 2007 10:20:45 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 07:20:36 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IEKWWs012870; Wed, 18 Jul 2007 07:20:32 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IEKT0g004802; Wed, 18 Jul 2007 07:20:31 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 07:20:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 07:20:23 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> In-Reply-To: <469DCB03.9040300@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkg References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> From: "Henry Sinnreich" To: "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 14:20:30.0725 (UTC) FILETIME=[CBC9EB50:01C7C946] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0c92ca299e0607fbf0058472806b19df Cc: sip@ietf.org, behave@ietf.org, mmusic@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="===============2034249612==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============2034249612== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C946.CB4C2FCF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C946.CB4C2FCF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Magnus, =20 I sincerely appreciate your interest and this note! =20 > I don't quite understand why you are requesting a status change of ICE =20 However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas the facts are some cause for serious concern, and I will just mention a few facts: =20 RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, but now clearly admits that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution." http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt My guess is, in plain English, RFC 3489 turned out just NOT to be an acceptable solution as it was hoped to be.=20 =20 The excellent I-D shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 messages just for the SIP INVITE! http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07. txt=20 What happens if the two endpoints are in different ISPs that have NAT of their own in addition to the ones in Fig. 22? What happens if one would try ICE along a P2PSIP route with say 5-8 hops? Would there be hundreds of messages? What is the likelihood for failure? =20 By contrast with such approaches based on hope and faith, the BEHAVE WG has produced work based on real measurements and tools to do the measurements, such as =20 "NAT Classification Test Results" =20 "Application Design Guidelines for Traversal through Network Address Translators"=20 The measurements for hole punching are reported in "Peer-to-Peer Communication Across Network Address Translators"=20 http://www.brynosaurus.com/pub/net/p2pnat/ =20 I am also a believer in ICE and have actually urged Jonathan Rosenberg to do this work and he has given his best. Now that we have ICE-17 version, it is in the best interest of the industry and the IETF to make it an experimental RFC, but not yet a standard so that: 1. Independent, compliant implementations will be developed, 2. Testing in events such as SIPit, 3. Reporting the results, such as reported for the "hole punching" above. =20 What happens if indeed hole punching proves to be the far more effective approach? =20 The industry can ill afford a new series of RFC[ICE]-bis and all the years it takes to move from believing to measuring and proving. I am sure IETF procedures were meant in this spirit (though I am not good in producing the right quotes). =20 Thanks again for your attention to this concern about ICE.=20 Also my apology to all the anguish to the numerous contributors to the ICE related I-Ds, but writing test tools and reporting measurements is the right way to go. =20 Henry =20 =20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Wednesday, July 18, 2007 1:11 AM To: Henry Sinnreich Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC =20 Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. >=20 > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. >=20 > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. >=20 > This is a change from the attached that I wrote on 7/16/2007. >=20 > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. =20 Henry, =20 I don't quite understand why you are requesting a status change of ICE?=20 To me it appears that ICE is almost finished spec. It has been=20 implemented, used and feedback has been influencing the protocol. It is=20 definitly one of the better examples of current IETF work that actually=20 has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE=20 works in the intended core cases. If there are some corner cases where=20 it fails, that may be. But that is not information we will have until=20 really large scale deployement or someone makes very extensive tests. =20 I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. =20 And to be clear, proposed standard is allowed to be published without a=20 single implementation exists. It might not be good practice, but it is=20 allowed by our process. And as I said before ICE has had enough=20 implementation that I am very confortable in balloting YES for it when=20 it appears on the IESGs table. =20 Cheers =20 Magnus Westerlund =20 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 ---------------------------------------------------------------------- ------_=_NextPart_001_01C7C946.CB4C2FCF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Magnus,

 

I sincerely appreciate your interest and this = note!

 

> I don't quite understand why you are requesting a status = change of ICE

 

However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas = the facts are some cause for serious concern, and I will just mention a few = facts:

 

RFC 3489 (STUN) was also presented as a NAT traversal solution = back in 2003, but <draft-ietf-behave-rfc3489bis-07> now clearly admits = that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be = used in the context of a NAT traversal solution. This is an important change = from the previous version of this specification (RFC 3489), which presented STUN = as a complete solution."

http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-= 07.txt

My guess is, in plain English, RFC 3489 turned out just NOT to = be an acceptable solution as it was hoped to be.

 

The excellent I-D <draft-ietf-sipping-nat-scenarios-07> = shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) = require 66 messages just for the SIP INVITE!

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sc= enarios-07.txt

What happens if the two endpoints are in different ISPs that = have NAT of their own in addition to the ones in Fig. = 22?

What happens if one would try ICE along a P2PSIP route with say = 5-8 hops? Would there be hundreds of messages? What is the likelihood for = failure?

 

By contrast with such approaches based on hope and faith, the = BEHAVE WG has produced work based on real measurements and tools to do the = measurements, such as

 

"NAT Classification Test = Results"

 

"Application Design Guidelines for Traversal through = Network Address Translators"

The measurements for hole punching are reported = in

"Peer-to-Peer Communication Across Network Address Translators"

http://www.brynosauru= s.com/pub/net/p2pnat/

 

I am also a believer in ICE and have actually urged Jonathan Rosenberg to do = this work and he has given his best. Now that we have ICE-17 version, it is in the = best interest of the industry and the IETF to make it an experimental RFC, but not yet = a standard so that:

 1. Independent, compliant implementations will be = developed,

 2. Testing in events such as = SIPit,

 3. Reporting the results, such as reported for the = "hole punching" above.

 

What happens if indeed hole punching proves to be the far more effective approach?

 

The industry can ill afford a new series of RFC[ICE]-bis and all = the years it takes to move from believing to measuring and proving. I am = sure IETF procedures were meant in this spirit (though I am not good in producing = the right quotes).

 

Thanks again for your attention to this concern about ICE. =

Also my apology to all the anguish to the numerous contributors = to the ICE related I-Ds, but writing test tools and reporting measurements is = the right way to go.

 

Henry

 

 

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Wednesday, July 18, 2007 1:11 AM
To: Henry Sinnreich
Cc: mmusic@ietf.org; sip@ietf.org; = behave@ietf.org
Subject: Re: [BEHAVE] Re: ICE deployment data before LC for = RFC

 

Henry = Sinnreich skrev:

> Following some discussions and soul searching, the best = approach for

> ICE-17 for LC would be to _go ahead and make it an = experimental RFC_.

>

> This would support the development of interoperable implementations, the

> collection of deployment data and also hopefully open = source code.

>

> Though I have full faith in ICE, following the practices = that made the

> IETF successful take precedent here, I = believe.

>

> This is a change from the attached that I wrote on = 7/16/2007.

>

> Note: We can only hope the proliferation of SBC in VoIP = service provider

> networks will not make these concerns and ICE for SIP a = moot issue, but

> this is another topic.

 

Henry,

 

I don't quite understand why you are requesting a status change = of ICE?

To me it appears that ICE is almost finished spec. It has been =

implemented, used and feedback has been influencing the = protocol. It is

definitly one of the better examples of current IETF work that = actually

has running code. Sure, the implementations may not be fully = updated yet

to the latest draft version. But I think it is safe to say that = ICE

works in the intended core cases. If there are some corner cases = where

it fails, that may be. But that is not information we will have = until

really large scale deployement or someone makes very extensive = tests.

 

I think the IETF and the Internet has much more benefit from a standards

track solution than any of the risks existing with ICE of = today.

 

And to be clear, proposed standard is allowed to be published = without a

single implementation exists. It might not be good practice, but = it is

allowed by our process. And as I said before ICE has had enough =

implementation that I am very confortable in balloting YES for = it when

it appears on the IESGs table.

 

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

-----------------------------------------------------------------= -----

------_=_NextPart_001_01C7C946.CB4C2FCF-- --===============2034249612== 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 --===============2034249612==-- From behave-bounces@ietf.org Wed Jul 18 10:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAuQ-0000O2-Bo; Wed, 18 Jul 2007 10:53:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBAuN-0000NB-90 for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 10:53:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAuM-0000Ms-F4; Wed, 18 Jul 2007 10:53:42 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAuK-0003FJ-Jn; Wed, 18 Jul 2007 10:53:42 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 3E9A5758069; Wed, 18 Jul 2007 09:53:39 -0500 (CDT) From: "Frank W. Miller" To: "'Henry Sinnreich'" , "'Magnus Westerlund'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 08:53:30 -0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAKU9CA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070718145339.3E9A5758069@smtpauth00.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3c3f5218b222da1e73e850f1438da613 Cc: sip@ietf.org, behave@ietf.org, mmusic@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="===============0313922170==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0313922170== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01C7C919.1DDFF390" This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01C7C919.1DDFF390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings, What I think Henry is advocating is a systematic approach to making sure that the content of the ICE spec is right for its intended purpose, i.e. a complete, general NAT traversal solution. NAT traversal has been in my opinion one of the most difficult aspects of SIP implementation and its very important that its eventual standardized solution be right. I know I spent a lot of time implementing all the "tests" in the first 3489, only to discover that they were not that useful. There are two valid technical concerns that are put forth in this email: 1) Viability of correct operation in practical implementations. ICE can result in very complicated message transfers. 2) Performance. As pointed out in this email and in other places, the additional latency associated with ICE operations can be significant. Henry also points out that there are competing approaches (e.g. Hole Punching) that can perform well in many situations and have better performance. IMHO, another approach by the IETF in general would be to standardize on Hole Punching and leverage the IETF's considerable influence to force NAT vendors to migrate towards implementations that are friendly to Hole Punching. The bottom line is that I agree with Henry in that labeling ICE as an experimental draft is the right thing to do. It will allow those implementing ICE (including myself in all likelihood) to proceed but signals to the users the correct status of the standard's contents. I also want to applaud loudly the underlying tone of Henry's thread here. That is, in solving specific technical problems within the IETF forum, focusing on empirical observation of working implementations should be the MO that we all strive for when developing and proposing what may become protocol standards. Thanks, FM _____ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Wednesday, July 18, 2007 8:20 AM To: Magnus Westerlund Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Magnus, I sincerely appreciate your interest and this note! > I don't quite understand why you are requesting a status change of ICE However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas the facts are some cause for serious concern, and I will just mention a few facts: RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, but now clearly admits that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution." http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt My guess is, in plain English, RFC 3489 turned out just NOT to be an acceptable solution as it was hoped to be. The excellent I-D shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 messages just for the SIP INVITE! http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.txt What happens if the two endpoints are in different ISPs that have NAT of their own in addition to the ones in Fig. 22? What happens if one would try ICE along a P2PSIP route with say 5-8 hops? Would there be hundreds of messages? What is the likelihood for failure? By contrast with such approaches based on hope and faith, the BEHAVE WG has produced work based on real measurements and tools to do the measurements, such as "NAT Classification Test Results" "Application Design Guidelines for Traversal through Network Address Translators" The measurements for hole punching are reported in "Peer-to-Peer Communication Across Network Address Translators" http://www.brynosaurus.com/pub/net/p2pnat/ I am also a believer in ICE and have actually urged Jonathan Rosenberg to do this work and he has given his best. Now that we have ICE-17 version, it is in the best interest of the industry and the IETF to make it an experimental RFC, but not yet a standard so that: 1. Independent, compliant implementations will be developed, 2. Testing in events such as SIPit, 3. Reporting the results, such as reported for the "hole punching" above. What happens if indeed hole punching proves to be the far more effective approach? The industry can ill afford a new series of RFC[ICE]-bis and all the years it takes to move from believing to measuring and proving. I am sure IETF procedures were meant in this spirit (though I am not good in producing the right quotes). Thanks again for your attention to this concern about ICE. Also my apology to all the anguish to the numerous contributors to the ICE related I-Ds, but writing test tools and reporting measurements is the right way to go. Henry -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Wednesday, July 18, 2007 1:11 AM To: Henry Sinnreich Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. > > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. > > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. > > This is a change from the attached that I wrote on 7/16/2007. > > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. Henry, I don't quite understand why you are requesting a status change of ICE? To me it appears that ICE is almost finished spec. It has been implemented, used and feedback has been influencing the protocol. It is definitly one of the better examples of current IETF work that actually has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE works in the intended core cases. If there are some corner cases where it fails, that may be. But that is not information we will have until really large scale deployement or someone makes very extensive tests. I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. And to be clear, proposed standard is allowed to be published without a single implementation exists. It might not be good practice, but it is allowed by our process. And as I said before ICE has had enough implementation that I am very confortable in balloting YES for it when it appears on the IESGs table. 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 ---------------------------------------------------------------------- ------=_NextPart_000_00CF_01C7C919.1DDFF390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Greetings,<= /p>

 

What I think Henry is advocating is = a systematic approach to making sure that the content of the ICE spec is = right for its intended purpose, i.e. a complete, general NAT traversal = solution.  NAT traversal has been in my opinion one of the most difficult aspects = of SIP implementation and its very important that its eventual standardized = solution be right.  I know I spent a lot of time implementing all the = “tests” in the first 3489, only to discover that they were not that = useful.  There are two valid technical concerns that are put forth in this = email:

 

1)     = Viability of correct operation in practical implementations.  ICE can result in very complicated message transfers.

2)     = Performance.  As pointed out in this email and in other places, the additional latency associated with ICE operations can be = significant.

 

Henry also points out that there = are competing approaches (e.g. Hole Punching) that can perform well in many situations and have better performance.  IMHO, another approach by = the IETF in general would be to standardize on Hole Punching and leverage = the IETF’s considerable influence to force NAT vendors to migrate towards = implementations that are friendly to Hole Punching.

 

The bottom line is that I agree = with Henry in that labeling ICE as an experimental draft is the right thing to = do.  It will allow those implementing ICE (including myself in all = likelihood) to proceed but signals to the users the correct status of the standard’s = contents.

 

I also want to applaud loudly the underlying tone of Henry’s thread here.  That is, in solving specific technical problems within the IETF forum, focusing on empirical = observation of working implementations should be the MO that we all strive for when developing and proposing what may become protocol = standards.

 

Thanks,

=

FM

 

 

From: Henry = Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, July 18, = 2007 8:20 AM
To: Magnus Westerlund
Cc: sip@ietf.org; = behave@ietf.org; mmusic@ietf.org
Subject: [Sip] RE: = [BEHAVE] Re: ICE deployment data before LC for RFC

 

Magnus,

 

I sincerely appreciate your interest and this = note!

 

> I don't quite understand why you are requesting a status = change of ICE

 

However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas = the facts are some cause for serious concern, and I will just mention a few = facts:

 

RFC 3489 (STUN) was also presented as a NAT traversal solution = back in 2003, but <draft-ietf-behave-rfc3489bis-07> now clearly admits = that "STUN is not a NAT traversal solution by itself. Rather, it is a = tool to be used in the context of a NAT traversal solution. This is an important = change from the previous version of this specification (RFC 3489), which = presented STUN as a complete solution."

http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-= 07.txt

My guess is, in plain English, RFC 3489 turned out just NOT to = be an acceptable solution as it was hoped to be.

 

The excellent I-D <draft-ietf-sipping-nat-scenarios-07> = shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) = require 66 messages just for the SIP INVITE!

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sc= enarios-07.txt

What happens if the two endpoints are in different ISPs that = have NAT of their own in addition to the ones in Fig. = 22?

What happens if one would try ICE along a P2PSIP route with say = 5-8 hops? Would there be hundreds of messages? What is the likelihood for = failure?

 

By contrast with such approaches based on hope and faith, the = BEHAVE WG has produced work based on real measurements and tools to do the = measurements, such as

 

"NAT Classification Test = Results"

 

"Application Design Guidelines for Traversal through = Network Address Translators"

The measurements for hole punching are reported = in

"Peer-to-Peer Communication Across Network Address Translators"

http://www.brynosauru= s.com/pub/net/p2pnat/

 

I am also a believer in ICE and have actually urged Jonathan Rosenberg to do = this work and he has given his best. Now that we have ICE-17 version, it is in the = best interest of the industry and the IETF to make it an experimental RFC, = but not yet a standard so that:

 1. Independent, compliant implementations will be = developed,

 2. Testing in events such as = SIPit,

 3. Reporting the results, such as reported for the = "hole punching" above.

 

What happens if indeed hole punching proves to be the far more effective approach?

 

The industry can ill afford a new series of RFC[ICE]-bis and all = the years it takes to move from believing to measuring and proving. I am = sure IETF procedures were meant in this spirit (though I am not good in producing = the right quotes).

 

Thanks again for your attention to this concern about ICE. =

Also my apology to all the anguish to the numerous contributors = to the ICE related I-Ds, but writing test tools and reporting measurements is = the right way to go.

 

Henry

 

 

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Wednesday, July 18, 2007 1:11 AM
To: Henry Sinnreich
Cc: mmusic@ietf.org; sip@ietf.org; = behave@ietf.org
Subject: Re: [BEHAVE] Re: ICE deployment data before LC for = RFC

 

Henry = Sinnreich skrev:

> Following some discussions and soul searching, the best = approach for

> ICE-17 for LC would be to _go ahead and make it an = experimental RFC_.

>

> This would support the development of interoperable implementations, the

> collection of deployment data and also hopefully open = source code.

>

> Though I have full faith in ICE, following the practices = that made the

> IETF successful take precedent here, I = believe.

>

> This is a change from the attached that I wrote on = 7/16/2007.

>

> Note: We can only hope the proliferation of SBC in VoIP = service provider

> networks will not make these concerns and ICE for SIP a = moot issue, but

> this is another topic.

 

Henry,

 

I don't quite understand why you are requesting a status change = of ICE?

To me it appears that ICE is almost finished spec. It has been =

implemented, used and feedback has been influencing the = protocol. It is

definitly one of the better examples of current IETF work that = actually

has running code. Sure, the implementations may not be fully = updated yet

to the latest draft version. But I think it is safe to say that = ICE

works in the intended core cases. If there are some corner cases = where

it fails, that may be. But that is not information we will have = until

really large scale deployement or someone makes very extensive = tests.

 

I think the IETF and the Internet has much more benefit from a standards

track solution than any of the risks existing with ICE of = today.

 

And to be clear, proposed standard is allowed to be published = without a

single implementation exists. It might not be good practice, but = it is

allowed by our process. And as I said before ICE has had enough =

implementation that I am very confortable in balloting YES for = it when

it appears on the IESGs table.

 

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

-----------------------------------------------------------------= -----

------=_NextPart_000_00CF_01C7C919.1DDFF390-- --===============0313922170== 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 --===============0313922170==-- From behave-bounces@ietf.org Wed Jul 18 11:37: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 1IBBaW-0000ph-S9; Wed, 18 Jul 2007 11:37:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBBaV-0000pH-0O for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 11:37:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBaU-0000oy-Jz for behave@ietf.org; Wed, 18 Jul 2007 11:37:14 -0400 Received: from web33301.mail.mud.yahoo.com ([68.142.206.116]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBBaS-0005ig-PI for behave@ietf.org; Wed, 18 Jul 2007 11:37:14 -0400 Received: (qmail 20356 invoked by uid 60001); 18 Jul 2007 15:37:12 -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=RcWaY5dlPfv7Wn3bij5Yf8r9MyWFv3X7biBuAwQPozF1tnGNjOKR3Akeq04ufr9PpQZFrcNa5fmPB5DfiWJx9m2TC1+Lko5IOEX83LPy0y4quxBwXdK/9uRTUeeIN6goG5I1q1/UQq5sEXeU7u8oqsx3JzwY580a3M0pmCbAUk4=; X-YMail-OSG: YHPVtOsVM1muHnYjzgz5BvnlxjIGUXyjqCvFQHcu Received: from [69.236.76.222] by web33301.mail.mud.yahoo.com via HTTP; Wed, 18 Jul 2007 08:37:12 PDT Date: Wed, 18 Jul 2007 08:37:12 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: "Frank W. Miller" , 'Henry Sinnreich' , 'Magnus Westerlund' In-Reply-To: <20070718145339.3E9A5758069@smtpauth00.csee.onr.siteprotect.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <239224.19734.qm@web33301.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: sip@ietf.org, behave@ietf.org, mmusic@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 Thanks to Henry and Frank for so eloquently articulating this. As both Henry and Frank mentioned, I fully support standardizing on HOLE PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence to force NAT vendors to migrate towards implementations that are friendly to Hole Punching and the Application developers to design applications using the hole punching techniques. That should be the FIRST order of priority. Yet, what is happening in BEHAVE WG is the other way around. Some people have put their weight so heavily in favor of ICE that they asked to drop the work on hole punching technique as WG item. THIS IS WRONG. I no longer see "NAT Traveral application design guidelines" as BEHAVE WG milestone. Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING TECHNIQUES to move forward as a WG item? regards, suresh --- "Frank W. Miller" wrote: > > > Greetings, > > > > What I think Henry is advocating is a systematic approach to making sure > that the content of the ICE spec is right for its intended purpose, i.e. a > complete, general NAT traversal solution. NAT traversal has been in my > opinion one of the most difficult aspects of SIP implementation and its very > important that its eventual standardized solution be right. I know I spent > a lot of time implementing all the "tests" in the first 3489, only to > discover that they were not that useful. There are two valid technical > concerns that are put forth in this email: > > > > 1) Viability of correct operation in practical implementations. ICE can > result in very complicated message transfers. > > 2) Performance. As pointed out in this email and in other places, the > additional latency associated with ICE operations can be significant. > > > > Henry also points out that there are competing approaches (e.g. Hole > Punching) that can perform well in many situations and have better > performance. IMHO, another approach by the IETF in general would be to > standardize on Hole Punching and leverage the IETF's considerable influence > to force NAT vendors to migrate towards implementations that are friendly to > Hole Punching. > > > > The bottom line is that I agree with Henry in that labeling ICE as an > experimental draft is the right thing to do. It will allow those > implementing ICE (including myself in all likelihood) to proceed but signals > to the users the correct status of the standard's contents. > > > > I also want to applaud loudly the underlying tone of Henry's thread here. > That is, in solving specific technical problems within the IETF forum, > focusing on empirical observation of working implementations should be the > MO that we all strive for when developing and proposing what may become > protocol standards. > > > > Thanks, > > FM > > > > > > _____ > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, July 18, 2007 8:20 AM > To: Magnus Westerlund > Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org > Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > > > Magnus, > > > > I sincerely appreciate your interest and this note! > > > > > I don't quite understand why you are requesting a status change of ICE > > > > However the arguments stated by the WG co-chairs and by you here are > procedural in nature, whereas the facts are some cause for serious concern, > and I will just mention a few facts: > > > > RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, > but now clearly admits that "STUN is not a > NAT traversal solution by itself. Rather, it is a tool to be used in the > context of a NAT traversal solution. This is an important change from the > previous version of this specification (RFC 3489), which presented STUN as a > complete solution." > > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt > > My guess is, in plain English, RFC 3489 turned out just NOT to be an > acceptable solution as it was hoped to be. > > > > The excellent I-D shows the ICE call > flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 > messages just for the SIP INVITE! > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.txt > > What happens if the two endpoints are in different ISPs that have NAT of > their own in addition to the ones in Fig. 22? > > What happens if one would try ICE along a P2PSIP route with say 5-8 hops? > Would there be hundreds of messages? What is the likelihood for failure? > > > > By contrast with such approaches based on hope and faith, the BEHAVE WG has > produced work based on real measurements and tools to do the measurements, > such as > > > > "NAT Classification Test Results" > > > > "Application Design Guidelines for Traversal through Network Address > Translators" > > The measurements for hole punching are reported in > > "Peer-to-Peer Communication Across Network Address Translators" > > http://www.brynosaurus.com/pub/net/p2pnat/ > > > > I am also a believer in ICE and have actually urged Jonathan Rosenberg to do > this work and he has given his best. Now that we have ICE-17 version, it is > in the best interest of the industry and the IETF to make it an experimental > RFC, but not yet a standard so that: > > 1. Independent, compliant implementations will be developed, > > 2. Testing in events such as SIPit, > > 3. Reporting the results, such as reported for the "hole punching" above. > > > > What happens if indeed hole punching proves to be the far more effective > approach? > > > > The industry can ill afford a new series of RFC[ICE]-bis and all the years > it takes to move from believing to measuring and proving. I am sure IETF > procedures were meant in this spirit (though I am not good in producing the > right quotes). > > > > Thanks again for your attention to this concern about ICE. > > Also my apology to all the anguish to the numerous contributors to the ICE > related I-Ds, but writing test tools and reporting measurements is the right > way to go. > > > > Henry > > > > > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, July 18, 2007 1:11 AM > To: Henry Sinnreich > Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > > > Henry Sinnreich skrev: > > > Following some discussions and soul searching, the best approach for > > > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. > > > > > > This would support the development of interoperable implementations, the > > > collection of deployment data and also hopefully open source code. > > > > > > Though I have full faith in ICE, following the practices that made the > > > IETF successful take precedent here, I believe. > > > > > > This is a change from the attached that I wrote on 7/16/2007. > > > > > > Note: We can only hope the proliferation of SBC in VoIP service provider > > > networks will not make these concerns and ICE for SIP a moot issue, but > > > this is another topic. > > > > Henry, > > > > I don't quite understand why you are requesting a status change of ICE? > > To me it appears that ICE is almost finished spec. It has been > > implemented, used and feedback has been influencing the protocol. It is > > definitly one of the better examples of current IETF work that actually > > has running code. Sure, the implementations may not be fully updated yet > > to the latest draft version. But I think it is safe to say that ICE > > works in the intended core cases. If there are some corner cases where > > it fails, that may be. But that is not information we will have until > > really large scale deployement or someone makes very extensive tests. > > > > I think the IETF and the Internet has much more benefit from a standards > > track solution than any of the risks existing with ICE of today. > > > > And to be clear, proposed standard is allowed to be published without a > > single implementation exists. It might not be good practice, but it is > > allowed by our process. And as I said before ICE has had enough > > implementation that I am very confortable in balloting YES for it when > > it appears on the IESGs table. > > > > 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 > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 12:13:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBC9O-00041n-Mt; Wed, 18 Jul 2007 12:13:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBC9K-0003xB-0S for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBC9J-0003wb-E4 for behave@ietf.org; Wed, 18 Jul 2007 12:13:13 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBC9I-0005XI-5d for behave@ietf.org; Wed, 18 Jul 2007 12:13:13 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBC9H-0007dL-1E; Wed, 18 Jul 2007 12:13:11 -0400 In-Reply-To: <200707180945.46590.remi.denis-courmont@nokia.com> References: <46929E54.50301@cisco.com> <200707171542.19726.remi.denis-courmont@nokia.com> <200707180945.46590.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <12539761-29C6-42B8-BDE9-4FBF3D8368EC@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] RFC3489bis-07 now available Date: Wed, 18 Jul 2007 12:13:24 -0400 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 On 18-Jul-07, at 02:45 , R=E9mi Denis-Courmont wrote: > On Tuesday 17 July 2007 21:24:30 you wrote: >>>> * defined length limits on all free-form fields >>> >>> That's really appreciable! But but, the limit should most likely be >>> expressed >>> in bytes rather than in characters. Otherwise, it is pretty >>> ambiguous whether >>> the limit is in code points or bytes. >> >> I don't really see this. >> For the username, it says >> It MUST contain a >> UTF-8 encoded sequence of less than 128 characters. >> How is this ambiguous? > > To re-iterate the question, does "character" mean "code point" or =20 > "byte"? It > is totally ambiguous. > > To me, a UTF-8 encoded sequence of less than 128 characters is up to > (128-1)*6+1=3D763 bytes, counting the terminating nul (and that's a =20= > bit big, > IMHO). To most implementors it's going to be 127(+1) bytes. > > I would much rather have: > > It MUST contain a valid UTF-8 encoded sequence of less than 128 =20= > bytes. OK. I see your point now, and think your proposed wording is fine. - Philip= _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 12:26: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 1IBCMb-0008Jo-6F; Wed, 18 Jul 2007 12:26:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBCMW-0008F7-H3 for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:26:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCMW-0008Ew-2z; Wed, 18 Jul 2007 12:26:52 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBCMU-0005zP-QB; Wed, 18 Jul 2007 12:26:52 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBCMO-0007sj-2C; Wed, 18 Jul 2007 12:26:45 -0400 In-Reply-To: <239224.19734.qm@web33301.mail.mud.yahoo.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 12:26:55 -0400 To: Pyda Srisuresh X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Cc: behave@ietf.org, mmusic@ietf.org, sip@ietf.org, 'Henry Sinnreich' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Frank, Henry, Suresh: I agree that ICE is a complex spec. I also agree that it would be =20 very interesting to see more data on which situations result in a direct path between =20 endpoints, as opposed to a path via a TURN server. However, I don't understand the comment that "Hole Punching =20 Techniques" are an alternative. In my view, ICE _is_ a "Hole Punching Technique". Perhaps you are referring to the use of STUN alone??? The problem with using STUN alone is that there are cases where using =20= the reflexive address doesn't work, and there is no way with STUN alone to determine when =20 an endpoint should or should not use a reflexive address. But perhaps you are referring to something else? - Philip On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > Thanks to Henry and Frank for so eloquently articulating this. > > As both Henry and Frank mentioned, I fully support standardizing on =20= > HOLE > PUNCHING TECHNIQUE and leveraging the IETF=92s considerable influence =20= > to force > NAT vendors to migrate towards implementations that are friendly to =20= > Hole > Punching and the Application developers to design applications =20 > using the hole > punching techniques. That should be the FIRST order of priority. > > Yet, what is happening in BEHAVE WG is the other way around. Some =20 > people have > put their weight so heavily in favor of ICE that they asked to drop =20= > the work on > hole punching technique as WG item. THIS IS WRONG. I no longer see =20 > "NAT > Traveral application design guidelines" as BEHAVE WG milestone. > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING =20= > TECHNIQUES > to move forward as a WG item? > > regards, > suresh > > --- "Frank W. Miller" wrote: > >> >> >> Greetings, >> >> >> >> What I think Henry is advocating is a systematic approach to =20 >> making sure >> that the content of the ICE spec is right for its intended =20 >> purpose, i.e. a >> complete, general NAT traversal solution. NAT traversal has been =20 >> in my >> opinion one of the most difficult aspects of SIP implementation =20 >> and its very >> important that its eventual standardized solution be right. I =20 >> know I spent >> a lot of time implementing all the "tests" in the first 3489, only to >> discover that they were not that useful. There are two valid =20 >> technical >> concerns that are put forth in this email: >> >> >> >> 1) Viability of correct operation in practical =20 >> implementations. ICE can >> result in very complicated message transfers. >> >> 2) Performance. As pointed out in this email and in other =20 >> places, the >> additional latency associated with ICE operations can be significant. >> >> >> >> Henry also points out that there are competing approaches (e.g. Hole >> Punching) that can perform well in many situations and have better >> performance. IMHO, another approach by the IETF in general would =20 >> be to >> standardize on Hole Punching and leverage the IETF's considerable =20 >> influence >> to force NAT vendors to migrate towards implementations that are =20 >> friendly to >> Hole Punching. >> >> >> >> The bottom line is that I agree with Henry in that labeling ICE as an >> experimental draft is the right thing to do. It will allow those >> implementing ICE (including myself in all likelihood) to proceed =20 >> but signals >> to the users the correct status of the standard's contents. >> >> >> >> I also want to applaud loudly the underlying tone of Henry's =20 >> thread here. >> That is, in solving specific technical problems within the IETF =20 >> forum, >> focusing on empirical observation of working implementations =20 >> should be the >> MO that we all strive for when developing and proposing what may =20 >> become >> protocol standards. >> >> >> >> Thanks, >> >> FM >> >> >> >> >> >> _____ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, July 18, 2007 8:20 AM >> To: Magnus Westerlund >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Magnus, >> >> >> >> I sincerely appreciate your interest and this note! >> >> >> >>> I don't quite understand why you are requesting a status change =20 >>> of ICE >> >> >> >> However the arguments stated by the WG co-chairs and by you here are >> procedural in nature, whereas the facts are some cause for serious =20= >> concern, >> and I will just mention a few facts: >> >> >> >> RFC 3489 (STUN) was also presented as a NAT traversal solution =20 >> back in 2003, >> but now clearly admits that =20 >> "STUN is not a >> NAT traversal solution by itself. Rather, it is a tool to be used =20 >> in the >> context of a NAT traversal solution. This is an important change =20 >> from the >> previous version of this specification (RFC 3489), which presented =20= >> STUN as a >> complete solution." >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-=20 >> rfc3489bis-07.txt >> >> My guess is, in plain English, RFC 3489 turned out just NOT to be an >> acceptable solution as it was hoped to be. >> >> >> >> The excellent I-D shows the =20 >> ICE call >> flow with two endpoints behind two NAT (Fig. 22 on page 38) =20 >> require 66 >> messages just for the SIP INVITE! >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-=20 >> scenarios-07.txt >> >> What happens if the two endpoints are in different ISPs that have =20 >> NAT of >> their own in addition to the ones in Fig. 22? >> >> What happens if one would try ICE along a P2PSIP route with say =20 >> 5-8 hops? >> Would there be hundreds of messages? What is the likelihood for =20 >> failure? >> >> >> >> By contrast with such approaches based on hope and faith, the =20 >> BEHAVE WG has >> produced work based on real measurements and tools to do the =20 >> measurements, >> such as >> >> >> >> "NAT Classification Test Results" >> >> >> >> "Application Design Guidelines for Traversal through Network Address >> Translators" >> >> The measurements for hole punching are reported in >> >> "Peer-to-Peer Communication Across Network Address Translators" >> >> http://www.brynosaurus.com/pub/net/p2pnat/ >> >> >> >> I am also a believer in ICE and have actually urged Jonathan =20 >> Rosenberg to do >> this work and he has given his best. Now that we have ICE-17 =20 >> version, it is >> in the best interest of the industry and the IETF to make it an =20 >> experimental >> RFC, but not yet a standard so that: >> >> 1. Independent, compliant implementations will be developed, >> >> 2. Testing in events such as SIPit, >> >> 3. Reporting the results, such as reported for the "hole =20 >> punching" above. >> >> >> >> What happens if indeed hole punching proves to be the far more =20 >> effective >> approach? >> >> >> >> The industry can ill afford a new series of RFC[ICE]-bis and all =20 >> the years >> it takes to move from believing to measuring and proving. I am =20 >> sure IETF >> procedures were meant in this spirit (though I am not good in =20 >> producing the >> right quotes). >> >> >> >> Thanks again for your attention to this concern about ICE. >> >> Also my apology to all the anguish to the numerous contributors to =20= >> the ICE >> related I-Ds, but writing test tools and reporting measurements is =20= >> the right >> way to go. >> >> >> >> Henry >> >> >> >> >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, July 18, 2007 1:11 AM >> To: Henry Sinnreich >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Henry Sinnreich skrev: >> >>> Following some discussions and soul searching, the best approach for >> >>> ICE-17 for LC would be to _go ahead and make it an experimental =20 >>> RFC_. >> >>> >> >>> This would support the development of interoperable =20 >>> implementations, the >> >>> collection of deployment data and also hopefully open source code. >> >>> >> >>> Though I have full faith in ICE, following the practices that =20 >>> made the >> >>> IETF successful take precedent here, I believe. >> >>> >> >>> This is a change from the attached that I wrote on 7/16/2007. >> >>> >> >>> Note: We can only hope the proliferation of SBC in VoIP service =20 >>> provider >> >>> networks will not make these concerns and ICE for SIP a moot =20 >>> issue, but >> >>> this is another topic. >> >> >> >> Henry, >> >> >> >> I don't quite understand why you are requesting a status change of =20= >> ICE? >> >> To me it appears that ICE is almost finished spec. It has been >> >> implemented, used and feedback has been influencing the protocol. =20 >> It is >> >> definitly one of the better examples of current IETF work that =20 >> actually >> >> has running code. Sure, the implementations may not be fully =20 >> updated yet >> >> to the latest draft version. But I think it is safe to say that ICE >> >> works in the intended core cases. If there are some corner cases =20 >> where >> >> it fails, that may be. But that is not information we will have until >> >> really large scale deployement or someone makes very extensive tests. >> >> >> >> I think the IETF and the Internet has much more benefit from a =20 >> standards >> >> track solution than any of the risks existing with ICE of today. >> >> >> >> And to be clear, proposed standard is allowed to be published =20 >> without a >> >> single implementation exists. It might not be good practice, but =20 >> it is >> >> allowed by our process. And as I said before ICE has had enough >> >> implementation that I am very confortable in balloting YES for it =20 >> when >> >> it appears on the IESGs table. >> >> >> >> Cheers >> >> >> >> Magnus Westerlund >> >> >> >> IETF Transport Area Director & TSVWG Chair >> >> ---------------------------------------------------------------------=20= >> - >> >> Multimedia Technologies, Ericsson Research EAB/TVM/M >> >> ---------------------------------------------------------------------=20= >> - >> >> Ericsson AB | Phone +46 8 4048287 >> >> Torshamsgatan 23 | Fax +46 8 7575550 >> >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 14:13: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 1IBE27-0007VA-45; Wed, 18 Jul 2007 14:13:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBE25-0007QK-RE for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:13:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBE25-0007LV-9A for behave@ietf.org; Wed, 18 Jul 2007 14:13:53 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBE23-0001re-Ab for behave@ietf.org; Wed, 18 Jul 2007 14:13:53 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Wed, 18 Jul 2007 11:13:46 -0700 From: "David Barrett" To: "'Philip Matthews'" , "'Pyda Srisuresh'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 11:13:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfJWHiK1kJjj4/ZRl2bJXpSN42/3wABwWSw In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f Message-Id: Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I agree with Henry, Frank, Suresh, and the lurkers on this list who have concern that ICE hasn't demonstrated its claims in the real world, while others have achieved similar ends with great success using much simpler approaches. (Some examples: Skype, Hamachi, Red Swoosh/Akamai, etc.) For example, regarding the "hole punching" approach (by which I assume you mean "opening a hole and trying to keep it open" versus ICE's "open a hole 'on demand' for each connection"), it's been demonstrated to work at large scale with at least 90% direct peer connectivity across the internet, today, with a much simpler message flow and implementation. I find it concerning that ICE has taken a more costly, difficult route without confirming it's truly worth the additional incremental effort (or even a step backwards). I share the concern that ICE standardization has gotten far out ahead of the horse in inventing a new protocol from scratch rather than modeling off of the proven protocols that came before it, which historically has been the IETF strength. Given this choice to go a new route, I think it warrants a higher burden of evidence -- contrasted against known success rates of competing solutions -- before being formally endorsed by the IETF. I'm completely open to ICE being superior to all others. I have no doubt more effort has been put into it, and I'm eager to enjoy the fruits of everyone's labor. But I'd like to see the data that proves it, and I see no reason to charge ahead with standardization until data is firmly in hand. -david > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, July 18, 2007 9:27 AM > To: Pyda Srisuresh > Cc: behave@ietf.org; mmusic@ietf.org; sip@ietf.org; 'Henry Sinnreich' > Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > Frank, Henry, Suresh: > > I agree that ICE is a complex spec. I also agree that it would be > very interesting to see > more data on which situations result in a direct path between > endpoints, as opposed to > a path via a TURN server. > > However, I don't understand the comment that "Hole Punching > Techniques" are an alternative. > In my view, ICE _is_ a "Hole Punching Technique". > > Perhaps you are referring to the use of STUN alone??? > The problem with using STUN alone is that there are cases where using > the reflexive address > doesn't work, and there is no way with STUN alone to determine when > an endpoint should or > should not use a reflexive address. > > But perhaps you are referring to something else? > - Philip > > > On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > > > Thanks to Henry and Frank for so eloquently articulating this. > > > > As both Henry and Frank mentioned, I fully support standardizing on > > HOLE > > PUNCHING TECHNIQUE and leveraging the IETF's considerable influence > > to force > > NAT vendors to migrate towards implementations that are friendly to > > Hole > > Punching and the Application developers to design applications > > using the hole > > punching techniques. That should be the FIRST order of priority. > > > > Yet, what is happening in BEHAVE WG is the other way around. Some > > people have > > put their weight so heavily in favor of ICE that they asked to drop > > the work on > > hole punching technique as WG item. THIS IS WRONG. I no longer see > > "NAT > > Traveral application design guidelines" as BEHAVE WG milestone. > > > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING > > TECHNIQUES > > to move forward as a WG item? > > > > regards, > > suresh > > > > --- "Frank W. Miller" wrote: > > > >> > >> > >> Greetings, > >> > >> > >> > >> What I think Henry is advocating is a systematic approach to > >> making sure > >> that the content of the ICE spec is right for its intended > >> purpose, i.e. a > >> complete, general NAT traversal solution. NAT traversal has been > >> in my > >> opinion one of the most difficult aspects of SIP implementation > >> and its very > >> important that its eventual standardized solution be right. I > >> know I spent > >> a lot of time implementing all the "tests" in the first 3489, only to > >> discover that they were not that useful. There are two valid > >> technical > >> concerns that are put forth in this email: > >> > >> > >> > >> 1) Viability of correct operation in practical > >> implementations. ICE can > >> result in very complicated message transfers. > >> > >> 2) Performance. As pointed out in this email and in other > >> places, the > >> additional latency associated with ICE operations can be significant. > >> > >> > >> > >> Henry also points out that there are competing approaches (e.g. Hole > >> Punching) that can perform well in many situations and have better > >> performance. IMHO, another approach by the IETF in general would > >> be to > >> standardize on Hole Punching and leverage the IETF's considerable > >> influence > >> to force NAT vendors to migrate towards implementations that are > >> friendly to > >> Hole Punching. > >> > >> > >> > >> The bottom line is that I agree with Henry in that labeling ICE as an > >> experimental draft is the right thing to do. It will allow those > >> implementing ICE (including myself in all likelihood) to proceed > >> but signals > >> to the users the correct status of the standard's contents. > >> > >> > >> > >> I also want to applaud loudly the underlying tone of Henry's > >> thread here. > >> That is, in solving specific technical problems within the IETF > >> forum, > >> focusing on empirical observation of working implementations > >> should be the > >> MO that we all strive for when developing and proposing what may > >> become > >> protocol standards. > >> > >> > >> > >> Thanks, > >> > >> FM > >> > >> > >> > >> > >> > >> _____ > >> > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Wednesday, July 18, 2007 8:20 AM > >> To: Magnus Westerlund > >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org > >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Magnus, > >> > >> > >> > >> I sincerely appreciate your interest and this note! > >> > >> > >> > >>> I don't quite understand why you are requesting a status change > >>> of ICE > >> > >> > >> > >> However the arguments stated by the WG co-chairs and by you here are > >> procedural in nature, whereas the facts are some cause for serious > >> concern, > >> and I will just mention a few facts: > >> > >> > >> > >> RFC 3489 (STUN) was also presented as a NAT traversal solution > >> back in 2003, > >> but now clearly admits that > >> "STUN is not a > >> NAT traversal solution by itself. Rather, it is a tool to be used > >> in the > >> context of a NAT traversal solution. This is an important change > >> from the > >> previous version of this specification (RFC 3489), which presented > >> STUN as a > >> complete solution." > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-behave- > >> rfc3489bis-07.txt > >> > >> My guess is, in plain English, RFC 3489 turned out just NOT to be an > >> acceptable solution as it was hoped to be. > >> > >> > >> > >> The excellent I-D shows the > >> ICE call > >> flow with two endpoints behind two NAT (Fig. 22 on page 38) > >> require 66 > >> messages just for the SIP INVITE! > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat- > >> scenarios-07.txt > >> > >> What happens if the two endpoints are in different ISPs that have > >> NAT of > >> their own in addition to the ones in Fig. 22? > >> > >> What happens if one would try ICE along a P2PSIP route with say > >> 5-8 hops? > >> Would there be hundreds of messages? What is the likelihood for > >> failure? > >> > >> > >> > >> By contrast with such approaches based on hope and faith, the > >> BEHAVE WG has > >> produced work based on real measurements and tools to do the > >> measurements, > >> such as > >> > >> > >> > >> "NAT Classification Test Results" > >> > >> > >> > >> "Application Design Guidelines for Traversal through Network Address > >> Translators" > >> > >> The measurements for hole punching are reported in > >> > >> "Peer-to-Peer Communication Across Network Address Translators" > >> > >> http://www.brynosaurus.com/pub/net/p2pnat/ > >> > >> > >> > >> I am also a believer in ICE and have actually urged Jonathan > >> Rosenberg to do > >> this work and he has given his best. Now that we have ICE-17 > >> version, it is > >> in the best interest of the industry and the IETF to make it an > >> experimental > >> RFC, but not yet a standard so that: > >> > >> 1. Independent, compliant implementations will be developed, > >> > >> 2. Testing in events such as SIPit, > >> > >> 3. Reporting the results, such as reported for the "hole > >> punching" above. > >> > >> > >> > >> What happens if indeed hole punching proves to be the far more > >> effective > >> approach? > >> > >> > >> > >> The industry can ill afford a new series of RFC[ICE]-bis and all > >> the years > >> it takes to move from believing to measuring and proving. I am > >> sure IETF > >> procedures were meant in this spirit (though I am not good in > >> producing the > >> right quotes). > >> > >> > >> > >> Thanks again for your attention to this concern about ICE. > >> > >> Also my apology to all the anguish to the numerous contributors to > >> the ICE > >> related I-Ds, but writing test tools and reporting measurements is > >> the right > >> way to go. > >> > >> > >> > >> Henry > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Wednesday, July 18, 2007 1:11 AM > >> To: Henry Sinnreich > >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org > >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Henry Sinnreich skrev: > >> > >>> Following some discussions and soul searching, the best approach for > >> > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >> > >>> > >> > >>> This would support the development of interoperable > >>> implementations, the > >> > >>> collection of deployment data and also hopefully open source code. > >> > >>> > >> > >>> Though I have full faith in ICE, following the practices that > >>> made the > >> > >>> IETF successful take precedent here, I believe. > >> > >>> > >> > >>> This is a change from the attached that I wrote on 7/16/2007. > >> > >>> > >> > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >> > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >> > >>> this is another topic. > >> > >> > >> > >> Henry, > >> > >> > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? > >> > >> To me it appears that ICE is almost finished spec. It has been > >> > >> implemented, used and feedback has been influencing the protocol. > >> It is > >> > >> definitly one of the better examples of current IETF work that > >> actually > >> > >> has running code. Sure, the implementations may not be fully > >> updated yet > >> > >> to the latest draft version. But I think it is safe to say that ICE > >> > >> works in the intended core cases. If there are some corner cases > >> where > >> > >> it fails, that may be. But that is not information we will have until > >> > >> really large scale deployement or someone makes very extensive tests. > >> > >> > >> > >> I think the IETF and the Internet has much more benefit from a > >> standards > >> > >> track solution than any of the risks existing with ICE of today. > >> > >> > >> > >> And to be clear, proposed standard is allowed to be published > >> without a > >> > >> single implementation exists. It might not be good practice, but > >> it is > >> > >> allowed by our process. And as I said before ICE has had enough > >> > >> implementation that I am very confortable in balloting YES for it > >> when > >> > >> it appears on the IESGs table. > >> > >> > >> > >> 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 > >> > > > > > > > > > > > > _______________________________________________ > > 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 Wed Jul 18 14:19:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBE78-00008l-8g; Wed, 18 Jul 2007 14:19:06 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBE76-00007b-3K for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:19:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBE74-00006Q-QW; Wed, 18 Jul 2007 14:19:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBE73-00027p-J0; Wed, 18 Jul 2007 14:19:02 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2007 11:19:00 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM70nUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,551,1175497200"; d="scan'208"; a="184397965:sNHT27953127" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6IIJ0Hn023569; Wed, 18 Jul 2007 11:19:00 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6IIIxSb020950; Wed, 18 Jul 2007 18:19:00 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'Magnus Westerlund'" Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 11:18:59 -0700 Message-ID: <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4270; t=1184782740; x=1185646740; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=20data=20before=2 0LC=20for=20RFC |Sender:=20; bh=2FWmfcMe0lUELpsCxRsiCfzJ5DQboIhP+QFWUpycxao=; b=rc1LY+x6P63Ju+iYeB0a+kHKDV/Y+Btd9EZzd2kDBor6bTDjwsRx93b1hhYdCs4eIaI/Hf2+ ebSY7CI6aMrC17UqVJYClcarL0C74Jc613LxV5f5lHEJVzAZKDCRj9hkCeKUIbwxT2ks9lojAl D4JQuevyEdpgVJsBJA5HYl43s=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > The excellent I-D shows > the ICE call flow with two endpoints behind two NAT (Fig. 22 > on page 38) require 66 messages just for the SIP INVITE! > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce > narios-07.txt That figure does not show 66 messages. That figure is clearly showing how the STUN messages are NATted, which leads to an incorrect conclusion around the number of messages. Specifically, for example, it shows this message exchange which might be counted as "four messages"; yet, there are only two messages (the allocate request and the allocate response), which are NATted: L NAT STUN Server | | | |(1) Alloc Req | | |Src=L-PRIV-1 | | |Dest=STUN-PUB-1 | | |--------------->| | | | | | |(2) Alloc Req | | |Src=L-NAT-PUB-1 | | |Des=STUN-PUB-1 | | |--------------->| | | | | |(3) Alloc Resp | | |<---------------| | |Src=STUN-PUB-1 | | |Dest=L-NAT-PUB-1| | |Map=L-NAT-PUB-1 | | |Rel=STUN-PUB-2 | | | | |(4) Alloc Resp | | |<---------------| | |Src=STUN-PUB-1 | | |Dest=L-PRIV-1 | | |Map=L-NAT-PUB-1 | | |Rel=STUN-PUB-2 | | | | | If we added another NAT on that path, the number of messages on the network does not double. The number of messages on the network stays the same -- the messages merely have their IP and UDP headers rewritten by the NATs. That NAT function does not increase the number of messages on the network. Similarly, another message shown in that same figure is also one message; however, it's shown as two messages: L NAT STUN NAT R Server |(9) SIP INVITE | | | | |------------------------------------------------->| | | | | |(10) SIP INVITE | | | | |--------------->| As you know, there aren't two messages -- it's one message that is NATted. If message 9 and 10 were shown as clearly as messages 1-4, messages 9-10 would be shown as four messages (one from L to its NAT, another from NAT to NAT, and the forth (shown) from NAT to R). But this is just one SIP message, which is NATted. It is inaccurate to count it as two separate messages or as four separate messages, because it is only one packet that is NATted. Counting a STUN packet, or a DNS packet, as a separate message each time it traverses a NAT is similarly inaccurate. By my count, figure 22 exchanges 24 STUN/ICE messages and 6 SIP messages. > What happens if the two endpoints are in different ISPs that > have NAT of their own in addition to the ones in Fig. 22? The same 24 STUN/ICE messages would be exchanged, and the same 6 SIP messages would be exchanged. > What happens if one would try ICE along a P2PSIP route with > say 5-8 hops? The SIP signaling messages would traverse those 5-8 additional hops between the P2PSIP nodes participating in the SIP proxy overlay. The STUN/ICE messages are sent peer-to-peer, and would remain the same 24 messages if you're doing the same Figure 22 flow. > Would there be hundreds of messages? No. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 14:44: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 1IBEVG-0002ge-5d; Wed, 18 Jul 2007 14:44:02 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBEVE-0002fe-OG for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:44:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEVE-0002fN-CT; Wed, 18 Jul 2007 14:44:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBEVD-0001Wj-TG; Wed, 18 Jul 2007 14:44:00 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2007 11:43:59 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANb7nUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,551,1175497200"; d="scan'208"; a="184411557:sNHT26564256" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6IIhx6T004698; Wed, 18 Jul 2007 11:43:59 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6IIhYSx015490; Wed, 18 Jul 2007 18:43:56 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 14:43:56 -0400 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 18 Jul 2007 18:43:56 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 18 Jul 2007 14:43:54 -0400 Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC From: Melinda Shore To: David Barrett , "'Philip Matthews'" , Pyda Srisuresh Message-ID: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJWHiK1kJjj4/ZRl2bJXpSN42/3wABwWSwAAMGS0Q= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 18:43:56.0472 (UTC) FILETIME=[98BF8380:01C7C96B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1322; t=1184784239; x=1185648239; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=FGomruZHVVV5PGhYSPpx0WH2XrxXMCEh87GwWWzX504=; b=JVxkldbK6hIqokxk3r5WFxbTWEhtPpWjKvUyf4h4jm7VH4A4/Onj3dIuoP0LWRML+pBapGCy 2rhwWCZg3ldHSFEzFTQtd4PxUJpDkdwmOsLIv+UOyavuh3GjHAHXzN5ChmksG/DDNquHswxYhM vCBMBGvshBwwOXrKks5QFr9bM=; Authentication-Results: sj-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@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 7/18/07 2:13 PM, "David Barrett" wrote: > For example, regarding the "hole punching" approach (by which I assume you > mean "opening a hole and trying to keep it open" versus ICE's "open a hole > 'on demand' for each connection"), it's been demonstrated to work at large > scale with at least 90% direct peer connectivity across the internet, today, > with a much simpler message flow and implementation. ICE makes me want to pound red-hot nails into my eye sockets. That said, 90% really isn't nearly good enough for residential deployments. For cheap-o residential equipment, the margins are so thin that a support call or two is sufficient to wipe out the profit on that sale. Part of the reason that ICE is the mess it is is that the group has been iteratively fixing the various failures by adding more tests and probes and messages and whatnot. There are certainly a lot of other ways to achieve reliability but regardless of which one you choose, reliability really does have to be a priority. Ancillary to that is that when you fail you should fail in a way that can be diagnosed with reasonable ease and transparency (auditability is good!), and I think we all know what happens when traditional NAT hole-punching fails - stuff just doesn't work. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 14:45:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEWJ-0003qi-Pp; Wed, 18 Jul 2007 14:45:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBEWJ-0003qJ-6d for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:45:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEWI-0003pz-Qi for behave@ietf.org; Wed, 18 Jul 2007 14:45:06 -0400 Received: from web33313.mail.mud.yahoo.com ([68.142.206.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBEWH-0001Ym-HH for behave@ietf.org; Wed, 18 Jul 2007 14:45:06 -0400 Received: (qmail 9268 invoked by uid 60001); 18 Jul 2007 18:38:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=3+2cY+yXyBkHGpWc8u4Ua2zsPKSOdRzfNvNuiznkVa3DC6IfYvIoKsXt1wClPSAI+9SyZWVrJOJN00uPyw5NpCe8LAnfssngyupTwL8rtaggH7gFuv2zciNnRWVoYL08Vm+FKBXad7heWxN1F4qRy15wdQrZn693v09YyaMp33c=; X-YMail-OSG: c8eMOgYVM1l2jEeRQ0Q9aMvg9aLtIhJfLV72DzMLBYEGYh5Z4gMv2ZMtWXXY9Dq3TCDRnTflv9.V.dcTa0PXhJPjG.xcZZ4rbBjsPYgXZzMj5h2UBhc- Received: from [209.172.74.45] by web33313.mail.mud.yahoo.com via HTTP; Wed, 18 Jul 2007 11:38:24 PDT Date: Wed, 18 Jul 2007 11:38:24 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: Philip Matthews In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <857678.8925.qm@web33313.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: behave@ietf.org, mmusic@ietf.org, sip@ietf.org, 'Henry Sinnreich' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: > Frank, Henry, Suresh: > > I agree that ICE is a complex spec. I also agree that it would be > very interesting to see > more data on which situations result in a direct path between > endpoints, as opposed to > a path via a TURN server. > > However, I don't understand the comment that "Hole Punching > Techniques" are an alternative. > In my view, ICE _is_ a "Hole Punching Technique". > > Perhaps you are referring to the use of STUN alone??? > The problem with using STUN alone is that there are cases where using > the reflexive address > doesn't work, and there is no way with STUN alone to determine when > an endpoint should or > should not use a reflexive address. > [suresh] Right, ICE does use the HOLE PUNCHING technique and the BCP guidelines described in draft-ford-behave-app draft, even though ICE draft does NOT acknowledge or reference the above draft or prior work that introduced HOLE PUNCHING TECHNIQUE. ICE is also using HOLE PUNCHING in a limited way within the constraints of STUN and SIP. Hence, the croner case scenarios you site. ICE is NOT HOLE PUNCHING in its native form. In the BEHAVE WG meeting(last IETF), several people talked of ICE as the new application traversal approach blessed by IETF, and proposed dropping the original draft ford-behave-app draft that proposes HOLE PUNCHING TECHNIQUE. As a result, the application milestone is dropped from the WG charter and ford-behave-app is not adapted as work group item. This, to me, is pitting ICE against the basic HOLE PUNCHING TECHNIQUE. This is what I believe to be WRONG. regards, suresh > But perhaps you are referring to something else? > - Philip > > > On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > > > Thanks to Henry and Frank for so eloquently articulating this. > > > > As both Henry and Frank mentioned, I fully support standardizing on > > HOLE > > PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence > > to force > > NAT vendors to migrate towards implementations that are friendly to > > Hole > > Punching and the Application developers to design applications > > using the hole > > punching techniques. That should be the FIRST order of priority. > > > > Yet, what is happening in BEHAVE WG is the other way around. Some > > people have > > put their weight so heavily in favor of ICE that they asked to drop > > the work on > > hole punching technique as WG item. THIS IS WRONG. I no longer see > > "NAT > > Traveral application design guidelines" as BEHAVE WG milestone. > > > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING > > TECHNIQUES > > to move forward as a WG item? > > > > regards, > > suresh > > > > --- "Frank W. Miller" wrote: > > > >> > >> > >> Greetings, > >> > >> > >> > >> What I think Henry is advocating is a systematic approach to > >> making sure > >> that the content of the ICE spec is right for its intended > >> purpose, i.e. a > >> complete, general NAT traversal solution. NAT traversal has been > >> in my > >> opinion one of the most difficult aspects of SIP implementation > >> and its very > >> important that its eventual standardized solution be right. I > >> know I spent > >> a lot of time implementing all the "tests" in the first 3489, only to > >> discover that they were not that useful. There are two valid > >> technical > >> concerns that are put forth in this email: > >> > >> > >> > >> 1) Viability of correct operation in practical > >> implementations. ICE can > >> result in very complicated message transfers. > >> > >> 2) Performance. As pointed out in this email and in other > >> places, the > >> additional latency associated with ICE operations can be significant. > >> > >> > >> > >> Henry also points out that there are competing approaches (e.g. Hole > >> Punching) that can perform well in many situations and have better > >> performance. IMHO, another approach by the IETF in general would > >> be to > >> standardize on Hole Punching and leverage the IETF's considerable > >> influence > >> to force NAT vendors to migrate towards implementations that are > >> friendly to > >> Hole Punching. > >> > >> > >> > >> The bottom line is that I agree with Henry in that labeling ICE as an > >> experimental draft is the right thing to do. It will allow those > >> implementing ICE (including myself in all likelihood) to proceed > >> but signals > >> to the users the correct status of the standard's contents. > >> > >> > >> > >> I also want to applaud loudly the underlying tone of Henry's > >> thread here. > >> That is, in solving specific technical problems within the IETF > >> forum, > >> focusing on empirical observation of working implementations > >> should be the > >> MO that we all strive for when developing and proposing what may > >> become > >> protocol standards. > >> > >> > >> > >> Thanks, > >> > >> FM > >> > >> > >> > >> > >> > >> _____ > >> > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Wednesday, July 18, 2007 8:20 AM > >> To: Magnus Westerlund > >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org > >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Magnus, > >> > >> > >> > >> I sincerely appreciate your interest and this note! > >> > >> > >> > >>> I don't quite understand why you are requesting a status change > >>> of ICE > >> > >> > >> > >> However the arguments stated by the WG co-chairs and by you here are > >> procedural in nature, whereas the facts are some cause for serious > >> concern, > >> and I will just mention a few facts: > >> > >> > >> > >> RFC 3489 (STUN) was also presented as a NAT traversal solution > >> back in 2003, > >> but now clearly admits that > >> "STUN is not a > >> NAT traversal solution by itself. Rather, it is a tool to be used > >> in the > >> context of a NAT traversal solution. This is an important change > >> from the > >> previous version of this specification (RFC 3489), which presented > >> STUN as a > >> complete solution." > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-behave- > >> rfc3489bis-07.txt > >> > >> My guess is, in plain English, RFC 3489 turned out just NOT to be an > >> acceptable solution as it was hoped to be. > >> > >> > >> > >> The excellent I-D shows the > >> ICE call > >> flow with two endpoints behind two NAT (Fig. 22 on page 38) > >> require 66 > >> messages just for the SIP INVITE! > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat- > >> scenarios-07.txt > >> > >> What happens if the two endpoints are in different ISPs that have > >> NAT of > >> their own in addition to the ones in Fig. 22? > >> > >> What happens if one would try ICE along a P2PSIP route with say > >> 5-8 hops? > >> Would there be hundreds of messages? What is the likelihood for > >> failure? > >> > >> > >> > >> By contrast with such approaches based on hope and faith, the > >> BEHAVE WG has > >> produced work based on real measurements and tools to do the > >> measurements, > >> such as > >> > >> > >> > >> "NAT Classification Test Results" > >> > >> > >> > >> "Application Design Guidelines for Traversal through Network Address > >> Translators" > >> > >> The measurements for hole punching are reported in > >> > >> "Peer-to-Peer Communication Across Network Address Translators" > >> > >> http://www.brynosaurus.com/pub/net/p2pnat/ > >> > >> > >> > >> I am also a believer in ICE and have actually urged Jonathan > >> Rosenberg to do > >> this work and he has given his best. Now that we have ICE-17 > >> version, it is > >> in the best interest of the industry and the IETF to make it an > >> experimental > >> RFC, but not yet a standard so that: > >> > >> 1. Independent, compliant implementations will be developed, > >> > >> 2. Testing in events such as SIPit, > >> > >> 3. Reporting the results, such as reported for the "hole > >> punching" above. > >> > >> > >> > >> What happens if indeed hole punching proves to be the far more > >> effective > >> approach? > >> > >> > >> > >> The industry can ill afford a new series of RFC[ICE]-bis and all > >> the years > >> it takes to move from believing to measuring and proving. I am > >> sure IETF > >> procedures were meant in this spirit (though I am not good in > >> producing the > >> right quotes). > >> > >> > >> > >> Thanks again for your attention to this concern about ICE. > >> > >> Also my apology to all the anguish to the numerous contributors to > >> the ICE > >> related I-Ds, but writing test tools and reporting measurements is > >> the right > >> way to go. > >> > >> > >> > >> Henry > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Wednesday, July 18, 2007 1:11 AM > >> To: Henry Sinnreich > >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org > >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Henry Sinnreich skrev: > >> > >>> Following some discussions and soul searching, the best approach for > >> > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >> > >>> > >> > >>> This would support the development of interoperable > >>> implementations, the > >> > >>> collection of deployment data and also hopefully open source code. > >> > >>> > >> > >>> Though I have full faith in ICE, following the practices that > >>> made the > >> > >>> IETF successful take precedent here, I believe. > >> > >>> > >> > >>> This is a change from the attached that I wrote on 7/16/2007. > >> > >>> > >> > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >> > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >> > >>> this is another topic. > >> > >> > >> > >> Henry, > >> > >> > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? > >> > >> To me it appears that ICE is almost finished spec. It has been > >> > >> implemented, used and feedback has been influencing the protocol. > >> It is > >> > >> definitly one of the better examples of current IETF work that > >> actually > >> > >> has running code. Sure, the implementations may not be fully > >> updated yet > >> > >> to the latest draft version. But I think it is safe to say that ICE > >> > >> works in the intended core cases. If there are some corner cases > >> where > >> > >> it fails, that may be. But that is not information we will have until > >> > >> really large scale deployement or someone makes very extensive tests. > >> > >> > >> > >> I think the IETF and the Internet has much more benefit from a > >> standards > >> > >> track solution than any of the risks existing with ICE of today. > >> > >> > >> > >> And to be clear, proposed standard is allowed to be published > >> without a > >> > >> single implementation exists. It might not be good practice, but > >> it is > >> > >> allowed by our process. And as I said before ICE has had enough > >> > >> implementation that I am very confortable in balloting YES for it > >> when > >> > >> it appears on the IESGs table. > >> > >> > >> > >> 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 > >> > > > > > > > > > > > > _______________________________________________ > > 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 Jul 18 15:20:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBF4t-0006hY-Ma; Wed, 18 Jul 2007 15:20:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBF4s-0006h6-BN for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:20:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBF4r-0006gx-Vh; Wed, 18 Jul 2007 15:20:50 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBF4r-0003p9-3f; Wed, 18 Jul 2007 15:20:49 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:20:40 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJJJot025959; Wed, 18 Jul 2007 12:19:20 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IJKI0i013432; Wed, 18 Jul 2007 12:20:34 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:20:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 12:20:22 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> In-Reply-To: <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84A== References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> From: "Henry Sinnreich" To: "Dan Wing" , "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 19:20:26.0798 (UTC) FILETIME=[B248BCE0:01C7C970] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip@ietf.org, Philip Matthews , behave@ietf.org, mmusic@ietf.org, p2psip@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 Dan, What you say makes sense but there is a lingering suspicion that after admitting that RFC 3489 (STUN), RFC 4091, 4092 (ANAT), etc. just don't work is that such paper evaluations are in no way a replacement for proof and measurements. We still need an explanation why the right approach cannot be taken: * Publish open source code at Sourceforge.net or similar, * Publish a test tool as well, * Gather and publish the results, possibly involving SIPit or another, * Perfect the OS code and the protocol until it works OK. This has been done for "Hole Punching for P2P" in=20 http://www.brynosaurus.com/pub/net/p2pnat/=20 What if ICE proves to be no better than its predecessors?=20 So how can one compare something that has tools, measured and published results with something like ICE that we have to take on pure faith? My assumption is that hole punching is much more effective for P2PSIP and I have copied the P2PSIP WG on this. The ratio of messages is probably 5:1 or higher for ICE vs. hole punching and this is critical when routing a P2PSIP message over an overlay in 5-10 hops. Of course I cannot prove it since as yet ICE cannot be measured. Let's do ICE the right way, there is too much at stake here. Henry -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Wednesday, July 18, 2007 1:19 PM To: Henry Sinnreich; 'Magnus Westerlund' Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC > The excellent I-D shows=20 > the ICE call flow with two endpoints behind two NAT (Fig. 22=20 > on page 38) require 66 messages just for the SIP INVITE! >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce > narios-07.txt=20 That figure does not show 66 messages. That figure is clearly showing how the STUN messages are NATted, which leads to an incorrect conclusion around the number of=20 messages. Specifically, for example, it shows this message exchange which might be counted as "four messages"; yet, there are only two messages (the allocate request and the allocate response), which are NATted: L NAT STUN =20 Server | | | =20 |(1) Alloc Req | | =20 |Src=3DL-PRIV-1 | | =20 |Dest=3DSTUN-PUB-1 | | =20 |--------------->| | =20 | | | =20 | |(2) Alloc Req | =20 | |Src=3DL-NAT-PUB-1 | =20 | |Des=3DSTUN-PUB-1 | =20 | |--------------->| =20 | | | =20 | |(3) Alloc Resp | =20 | |<---------------| =20 | |Src=3DSTUN-PUB-1 | =20 | |Dest=3DL-NAT-PUB-1| =20 | |Map=3DL-NAT-PUB-1 | =20 | |Rel=3DSTUN-PUB-2 | =20 | | | =20 |(4) Alloc Resp | | =20 |<---------------| | =20 |Src=3DSTUN-PUB-1 | | =20 |Dest=3DL-PRIV-1 | | =20 |Map=3DL-NAT-PUB-1 | | =20 |Rel=3DSTUN-PUB-2 | | =20 | | | =20 If we added another NAT on that path, the number of messages on the network does not double. The number of messages on=20 the network stays the same -- the messages merely have their IP and UDP headers rewritten by the NATs. That NAT function does not increase the number of messages on the network. Similarly, another message shown in that same figure is also one message; however, it's shown as two messages: L NAT STUN NAT R Server |(9) SIP INVITE | | | | |------------------------------------------------->| | | | | |(10) SIP INVITE | | | | |--------------->| As you know, there aren't two messages -- it's one message that is NATted. If message 9 and 10 were shown as clearly as messages 1-4, messages 9-10 would be shown as four messages (one from L to its NAT, another=20 from NAT to NAT, and the forth (shown) from NAT to R). But this is just one SIP message, which is NATted. It is inaccurate to count it as two separate messages or as four separate messages, because it is only one packet that is NATted. Counting a STUN packet, or a DNS packet, as a separate message each time it traverses a=20 NAT is similarly inaccurate. By my count, figure 22 exchanges 24 STUN/ICE messages and 6=20 SIP messages. > What happens if the two endpoints are in different ISPs that=20 > have NAT of their own in addition to the ones in Fig. 22? The same 24 STUN/ICE messages would be exchanged, and the same 6 SIP messages would be exchanged. > What happens if one would try ICE along a P2PSIP route with=20 > say 5-8 hops? The SIP signaling messages would traverse those 5-8 additional=20 hops between the P2PSIP nodes participating in the SIP proxy overlay. The STUN/ICE messages are sent peer-to-peer, and=20 would remain the same 24 messages if you're doing the same=20 Figure 22 flow. =20 > Would there be hundreds of messages? No. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 15:32: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 1IBFFd-0000RG-FS; Wed, 18 Jul 2007 15:31:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBFFQ-0000Ki-97 for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFFO-0000KY-UK; Wed, 18 Jul 2007 15:31:43 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFFN-0002zx-EC; Wed, 18 Jul 2007 15:31:42 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:31:34 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJVWWs017431; Wed, 18 Jul 2007 12:31:32 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IJVT0e014943; Wed, 18 Jul 2007 12:31:31 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:31:30 -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: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 12:31:18 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJWHZz70STkhAQTUWLy398tzWtmAAGFg6w References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" , "Pyda Srisuresh" X-OriginalArrivalTime: 18 Jul 2007 19:31:30.0491 (UTC) FILETIME=[3DE040B0:01C7C972] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Cc: behave@ietf.org, mmusic@ietf.org, sip@ietf.org, p2psip@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 Phil, > In my view, ICE _is_ a "Hole Punching Technique". Yes, you absolutely right, though the devil is in the details. We cannot go here into a shoot-out between hole punching or other mentioned on the list vs. ICE, but there seems to be a huge difference in effectiveness and performance.=20 Of course I cannot prove it since there are no measurements published for ICE, only faith.=20 Just think of traversing all the NAT while going over 5-10 overlay network hops. Also many ISP are NATed and some are multiple NATed. We are supposed to provide a solution that works across the Internet. A provable (testing tools) and proven solution (measurements). I like ICE and hope to be proven wrong, but the risk is just too big for now. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, July 18, 2007 9:27 AM To: Pyda Srisuresh Cc: Frank W. Miller; Henry Sinnreich; 'Magnus Westerlund'; sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Frank, Henry, Suresh: I agree that ICE is a complex spec. I also agree that it would be =20 very interesting to see more data on which situations result in a direct path between =20 endpoints, as opposed to a path via a TURN server. However, I don't understand the comment that "Hole Punching =20 Techniques" are an alternative. In my view, ICE _is_ a "Hole Punching Technique". Perhaps you are referring to the use of STUN alone??? The problem with using STUN alone is that there are cases where using =20 the reflexive address doesn't work, and there is no way with STUN alone to determine when =20 an endpoint should or should not use a reflexive address. But perhaps you are referring to something else? - Philip On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > Thanks to Henry and Frank for so eloquently articulating this. > > As both Henry and Frank mentioned, I fully support standardizing on =20 > HOLE > PUNCHING TECHNIQUE and leveraging the IETF's considerable influence =20 > to force > NAT vendors to migrate towards implementations that are friendly to =20 > Hole > Punching and the Application developers to design applications =20 > using the hole > punching techniques. That should be the FIRST order of priority. > > Yet, what is happening in BEHAVE WG is the other way around. Some =20 > people have > put their weight so heavily in favor of ICE that they asked to drop =20 > the work on > hole punching technique as WG item. THIS IS WRONG. I no longer see =20 > "NAT > Traveral application design guidelines" as BEHAVE WG milestone. > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING =20 > TECHNIQUES > to move forward as a WG item? > > regards, > suresh > > --- "Frank W. Miller" wrote: > >> >> >> Greetings, >> >> >> >> What I think Henry is advocating is a systematic approach to =20 >> making sure >> that the content of the ICE spec is right for its intended =20 >> purpose, i.e. a >> complete, general NAT traversal solution. NAT traversal has been =20 >> in my >> opinion one of the most difficult aspects of SIP implementation =20 >> and its very >> important that its eventual standardized solution be right. I =20 >> know I spent >> a lot of time implementing all the "tests" in the first 3489, only to >> discover that they were not that useful. There are two valid =20 >> technical >> concerns that are put forth in this email: >> >> >> >> 1) Viability of correct operation in practical =20 >> implementations. ICE can >> result in very complicated message transfers. >> >> 2) Performance. As pointed out in this email and in other =20 >> places, the >> additional latency associated with ICE operations can be significant. >> >> >> >> Henry also points out that there are competing approaches (e.g. Hole >> Punching) that can perform well in many situations and have better >> performance. IMHO, another approach by the IETF in general would =20 >> be to >> standardize on Hole Punching and leverage the IETF's considerable =20 >> influence >> to force NAT vendors to migrate towards implementations that are =20 >> friendly to >> Hole Punching. >> >> >> >> The bottom line is that I agree with Henry in that labeling ICE as an >> experimental draft is the right thing to do. It will allow those >> implementing ICE (including myself in all likelihood) to proceed =20 >> but signals >> to the users the correct status of the standard's contents. >> >> >> >> I also want to applaud loudly the underlying tone of Henry's =20 >> thread here. >> That is, in solving specific technical problems within the IETF =20 >> forum, >> focusing on empirical observation of working implementations =20 >> should be the >> MO that we all strive for when developing and proposing what may =20 >> become >> protocol standards. >> >> >> >> Thanks, >> >> FM >> >> >> >> >> >> _____ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, July 18, 2007 8:20 AM >> To: Magnus Westerlund >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Magnus, >> >> >> >> I sincerely appreciate your interest and this note! >> >> >> >>> I don't quite understand why you are requesting a status change =20 >>> of ICE >> >> >> >> However the arguments stated by the WG co-chairs and by you here are >> procedural in nature, whereas the facts are some cause for serious =20 >> concern, >> and I will just mention a few facts: >> >> >> >> RFC 3489 (STUN) was also presented as a NAT traversal solution =20 >> back in 2003, >> but now clearly admits that =20 >> "STUN is not a >> NAT traversal solution by itself. Rather, it is a tool to be used =20 >> in the >> context of a NAT traversal solution. This is an important change =20 >> from the >> previous version of this specification (RFC 3489), which presented =20 >> STUN as a >> complete solution." >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-=20 >> rfc3489bis-07.txt >> >> My guess is, in plain English, RFC 3489 turned out just NOT to be an >> acceptable solution as it was hoped to be. >> >> >> >> The excellent I-D shows the =20 >> ICE call >> flow with two endpoints behind two NAT (Fig. 22 on page 38) =20 >> require 66 >> messages just for the SIP INVITE! >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-=20 >> scenarios-07.txt >> >> What happens if the two endpoints are in different ISPs that have =20 >> NAT of >> their own in addition to the ones in Fig. 22? >> >> What happens if one would try ICE along a P2PSIP route with say =20 >> 5-8 hops? >> Would there be hundreds of messages? What is the likelihood for =20 >> failure? >> >> >> >> By contrast with such approaches based on hope and faith, the =20 >> BEHAVE WG has >> produced work based on real measurements and tools to do the =20 >> measurements, >> such as >> >> >> >> "NAT Classification Test Results" >> >> >> >> "Application Design Guidelines for Traversal through Network Address >> Translators" >> >> The measurements for hole punching are reported in >> >> "Peer-to-Peer Communication Across Network Address Translators" >> >> http://www.brynosaurus.com/pub/net/p2pnat/ >> >> >> >> I am also a believer in ICE and have actually urged Jonathan =20 >> Rosenberg to do >> this work and he has given his best. Now that we have ICE-17 =20 >> version, it is >> in the best interest of the industry and the IETF to make it an =20 >> experimental >> RFC, but not yet a standard so that: >> >> 1. Independent, compliant implementations will be developed, >> >> 2. Testing in events such as SIPit, >> >> 3. Reporting the results, such as reported for the "hole =20 >> punching" above. >> >> >> >> What happens if indeed hole punching proves to be the far more =20 >> effective >> approach? >> >> >> >> The industry can ill afford a new series of RFC[ICE]-bis and all =20 >> the years >> it takes to move from believing to measuring and proving. I am =20 >> sure IETF >> procedures were meant in this spirit (though I am not good in =20 >> producing the >> right quotes). >> >> >> >> Thanks again for your attention to this concern about ICE. >> >> Also my apology to all the anguish to the numerous contributors to =20 >> the ICE >> related I-Ds, but writing test tools and reporting measurements is =20 >> the right >> way to go. >> >> >> >> Henry >> >> >> >> >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, July 18, 2007 1:11 AM >> To: Henry Sinnreich >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Henry Sinnreich skrev: >> >>> Following some discussions and soul searching, the best approach for >> >>> ICE-17 for LC would be to _go ahead and make it an experimental =20 >>> RFC_. >> >>> >> >>> This would support the development of interoperable =20 >>> implementations, the >> >>> collection of deployment data and also hopefully open source code. >> >>> >> >>> Though I have full faith in ICE, following the practices that =20 >>> made the >> >>> IETF successful take precedent here, I believe. >> >>> >> >>> This is a change from the attached that I wrote on 7/16/2007. >> >>> >> >>> Note: We can only hope the proliferation of SBC in VoIP service =20 >>> provider >> >>> networks will not make these concerns and ICE for SIP a moot =20 >>> issue, but >> >>> this is another topic. >> >> >> >> Henry, >> >> >> >> I don't quite understand why you are requesting a status change of =20 >> ICE? >> >> To me it appears that ICE is almost finished spec. It has been >> >> implemented, used and feedback has been influencing the protocol. =20 >> It is >> >> definitly one of the better examples of current IETF work that =20 >> actually >> >> has running code. Sure, the implementations may not be fully =20 >> updated yet >> >> to the latest draft version. But I think it is safe to say that ICE >> >> works in the intended core cases. If there are some corner cases =20 >> where >> >> it fails, that may be. But that is not information we will have until >> >> really large scale deployement or someone makes very extensive tests. >> >> >> >> I think the IETF and the Internet has much more benefit from a =20 >> standards >> >> track solution than any of the risks existing with ICE of today. >> >> >> >> And to be clear, proposed standard is allowed to be published =20 >> without a >> >> single implementation exists. It might not be good practice, but =20 >> it is >> >> allowed by our process. And as I said before ICE has had enough >> >> implementation that I am very confortable in balloting YES for it =20 >> when >> >> it appears on the IESGs table. >> >> >> >> 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 >> > > > > > > _______________________________________________ > 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 Jul 18 15:38: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 1IBFM0-00052E-8a; Wed, 18 Jul 2007 15:38:32 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBFLt-0004pz-Rs for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:38:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFLr-0004p2-Ep; Wed, 18 Jul 2007 15:38:23 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFLr-0003Ej-3E; Wed, 18 Jul 2007 15:38:23 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6IJcIa02521; Wed, 18 Jul 2007 19:38:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 14:38:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84AABKemA References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> From: "Francois Audet" To: "Henry Sinnreich" , "Dan Wing" , "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, p2psip@ietf.org, behave@ietf.org, Philip Matthews , mmusic@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 =20 > * Publish open source code at Sourceforge.net or similar, > * Publish a test tool as well, > * Gather and publish the results, possibly involving SIPit or another, > * Perfect the OS code and the protocol until it works OK. >=20 > This has been done for "Hole Punching for P2P" in=20 > http://www.brynosaurus.com/pub/net/p2pnat/=20 Heuh, no. This is just "exploratory concept" stuff, certainly not an interoperable protocol specification. And if the proponents of this alternative hole punching didn't=20 propose a draft at IETF when we starting working on this back in 2001, it seems to me that it's too late. > My assumption is that hole punching is much more effective=20 > for P2PSIP and I have copied the P2PSIP WG on this. The ratio=20 > of messages is probably 5:1 or higher for ICE vs. hole=20 > punching and this is critical when routing a P2PSIP message=20 > over an overlay in 5-10 hops. Of course I cannot prove it=20 > since as yet ICE cannot be measured. Well, your assumption may be wrong, especially in the absence of a specification for this alternative hole punching technique. The other thing I find funny in here is that the alternative=20 hole punching techique as described on the web site uses a centralize server common to BOTH ends to relay the address, while ICE does not (i.e., each end can use their own STUN server). In other words, the major difference between ICE and the alternative-hole- punching technique seems to be that alternative-hole-punching assumes both ends use the same STUN server, which makes the=20 rest of the exchange simpler (the "magic box" architectural concept is always handy). Ironically, this seems to me to be LESS usable in a global network where you wont't use centralize servers, especially for p2psip. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 15:43: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 1IBFQz-0005h8-RN; Wed, 18 Jul 2007 15:43:41 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBFQe-0005P3-5q for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFQc-0005Oj-CG; Wed, 18 Jul 2007 15:43:19 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFQb-0003Mr-Pi; Wed, 18 Jul 2007 15:43:18 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:43:13 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJfqot000197; Wed, 18 Jul 2007 12:41:53 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IJh60c016197; Wed, 18 Jul 2007 12:43:07 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:43:06 -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: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 12:42:57 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED891@namail5.corp.adobe.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84AABKemAAACP2dA= References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com><08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com><24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> From: "Henry Sinnreich" To: "Francois Audet" , "Dan Wing" , "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 19:43:06.0466 (UTC) FILETIME=[DCB59C20:01C7C973] X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, mmusic@ietf.org, behave@ietf.org, p2psip@ietf.org, 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 Francois, > Heuh, no. This is just "exploratory concept" stuff, certainly not an=20 > interoperable protocol specification. I am happy to report we are in total agreement. Henry -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, July 18, 2007 2:38 PM To: Henry Sinnreich; Dan Wing; Magnus Westerlund Cc: sip@ietf.org; p2psip@ietf.org; behave@ietf.org; Philip Matthews; mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC =20 > * Publish open source code at Sourceforge.net or similar, > * Publish a test tool as well, > * Gather and publish the results, possibly involving SIPit or another, > * Perfect the OS code and the protocol until it works OK. >=20 > This has been done for "Hole Punching for P2P" in=20 > http://www.brynosaurus.com/pub/net/p2pnat/=20 Heuh, no. This is just "exploratory concept" stuff, certainly not an interoperable protocol specification. And if the proponents of this alternative hole punching didn't=20 propose a draft at IETF when we starting working on this back in 2001, it seems to me that it's too late. > My assumption is that hole punching is much more effective=20 > for P2PSIP and I have copied the P2PSIP WG on this. The ratio=20 > of messages is probably 5:1 or higher for ICE vs. hole=20 > punching and this is critical when routing a P2PSIP message=20 > over an overlay in 5-10 hops. Of course I cannot prove it=20 > since as yet ICE cannot be measured. Well, your assumption may be wrong, especially in the absence of a specification for this alternative hole punching technique. The other thing I find funny in here is that the alternative=20 hole punching techique as described on the web site uses a centralize server common to BOTH ends to relay the address, while ICE does not (i.e., each end can use their own STUN server). In other words, the major difference between ICE and the alternative-hole- punching technique seems to be that alternative-hole-punching assumes both ends use the same STUN server, which makes the=20 rest of the exchange simpler (the "magic box" architectural concept is always handy). Ironically, this seems to me to be LESS usable in a global network where you wont't use centralize servers, especially for p2psip. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 17:06: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 1IBGih-0000vW-P6; Wed, 18 Jul 2007 17:06:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBGi7-0000gL-Se for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 17:05:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGi7-0000g0-5W; Wed, 18 Jul 2007 17:05:27 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBGi6-0007eH-PC; Wed, 18 Jul 2007 17:05:27 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 99B4C75807D; Wed, 18 Jul 2007 16:05:25 -0500 (CDT) Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC From: "Frank W. Miller" To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 15:05:13 -0600 Message-Id: <1184792713.3347.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: behave@ietf.org, p2psip@ietf.org, sip@ietf.org, Henry Sinnreich , Dan Wing , Philip Matthews , mmusic@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 Wed, 2007-07-18 at 14:38 -0500, Francois Audet wrote: > The other thing I find funny in here is that the alternative > hole punching techique as described on the web site uses a > centralize server common to BOTH ends to relay the address, while > ICE does not (i.e., each end can use their own STUN server). > > In other words, the major difference between ICE and the > alternative-hole- > punching technique seems to be that alternative-hole-punching > assumes both ends use the same STUN server, which makes the > rest of the exchange simpler (the "magic box" architectural > concept is always handy). > > Ironically, this seems to me to be LESS usable in a global network > where you wont't use centralize servers, especially for p2psip. > This may be sufficient, but I don't think its necessary. Each UA punches the hole (and keeps it open, as David described) to whatever STUN server they like, all that's required is that each server have the same view of each client. That is somewhat less restrictive. In the common case of the open Internet, as long as the STUN servers used by each respective UA are in the "open", they don't have to be the same. After that, the "public" or "visible" IP address/port is put in the Contact headers. Regarding the 90% coverage, this is what I'm referring to when I say that it may be preferable to influence the NAT vendors to not do the things that put them in the 10% cases. I sort of thought that was what the NAT guidelines draft was for. In addition, if we are standardizing a protocol based on the 10% cases and imposing potentially huge costs on the 90% to do so, then our approach is incorrect. We should be designing for the 90% case and handling the 10% as exceptional behavior, i.e. a solution where you pay the big cost only in the case where you are actually in the 10%. FM _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 18:39: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 1IBIAs-0003bq-7V; Wed, 18 Jul 2007 18:39:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBIAn-0003Tt-Km for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 18:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIAm-0003Rx-Pm for behave@ietf.org; Wed, 18 Jul 2007 18:39:09 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBIAl-0000AA-Al for behave@ietf.org; Wed, 18 Jul 2007 18:39:08 -0400 Received: from lappy ([68.26.122.92]) by quinthar.com for ; Wed, 18 Jul 2007 15:38:59 -0700 From: "David Barrett" To: "'Melinda Shore'" , "'Philip Matthews'" , "'Pyda Srisuresh'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 15:38:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfJWHiK1kJjj4/ZRl2bJXpSN42/3wABwWSwAAMGS0QAB7yQkA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Message-Id: Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > > ICE makes me want to pound red-hot nails into my eye sockets. That said, > 90% really isn't nearly good enough for residential deployments. Incidentally, 90% is where my stats come out today -- this doesn't include restricted-cone/symmetric and symmetric/symmetric penetration, which has been prototyped but not added to the production system yet. The hope is this will get us much close to the 99% range, but it remains to be seen by how much. Furthermore, I'd wager that for most applications (such as VoIP), even routing 1 in 10 calls through a central relay isn't going to break the bank. (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) to act as "free" relays for their peers.) Thus while NAT penetration using what I guess we're calling the "hole punching technique" has been demonstrated to work at 90%+ on a very large scale (hundreds of thousands of clients tested) we should expect that it's possible to get even better still. If ICE can show how it'd do better, that'd be great. But we can't tolerate ICE being any worse than that, and thus before rushing ahead with standardizing an unproven ICE, we should just take the time to prove it. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 19:52: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 1IBJK3-0004nC-AP; Wed, 18 Jul 2007 19:52:47 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBC91-0003DE-AV for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:12:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBC90-0003D0-FT; Wed, 18 Jul 2007 12:12:55 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBC8y-0006mc-Qd; Wed, 18 Jul 2007 12:12:54 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.101]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IBC8x-0005M0-FG; Wed, 18 Jul 2007 11:12:51 -0500 In-Reply-To: <469DCB03.9040300@ericsson.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 11:12:27 -0500 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-Mailman-Approved-At: Wed, 18 Jul 2007 19:52:45 -0400 Cc: sip@ietf.org, Henry Sinnreich , behave@ietf.org, mmusic@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 Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > Henry Sinnreich skrev: >> Following some discussions and soul searching, the best approach for >> ICE-17 for LC would be to _go ahead and make it an experimental RFC_. >> This would support the development of interoperable >> implementations, the >> collection of deployment data and also hopefully open source code. >> Though I have full faith in ICE, following the practices that made >> the >> IETF successful take precedent here, I believe. >> This is a change from the attached that I wrote on 7/16/2007. >> Note: We can only hope the proliferation of SBC in VoIP service >> provider >> networks will not make these concerns and ICE for SIP a moot >> issue, but >> this is another topic. > > Henry, > > I don't quite understand why you are requesting a status change of > ICE? To me it appears that ICE is almost finished spec. It has been > implemented, used and feedback has been influencing the protocol. > It is definitly one of the better examples of current IETF work > that actually has running code. Sure, the implementations may not > be fully updated yet to the latest draft version. But I think it is > safe to say that ICE works in the intended core cases. If there are > some corner cases where it fails, that may be. But that is not > information we will have until really large scale deployement or > someone makes very extensive tests. Henry has, I believe, been very consistent in urging the IETF to have more "running code" experience on every specification (not just ICE) than our process requires. He has, IIRC, also advocated changing the process to require running code before publishing an RFC. He's even suggested at times that one should have running code before submitting a protocol draft. Another point to consider -- I've known Henry to bark at a tree with no squirrel in it occasionally, but most of the time he's pretty reliable, more so than most technology predictors. If he's worried about ICE, it's probably because he's been talking to people who are trying to implement it and they're telling him it is difficult or that they're having performance or reliability issues. I imagine that there are plenty of internal development teams in various companies that are working on this and not necessarily bringing their results back to the IETF. After all, if everybody sees the emperor as fully clothed, they'd be embarrassed to proclaim otherwise. Of course, I wish all of these developers were tied into the IETF, but then I'm sure I don't want to see every ice-implementor's question on the SIP list. That is why we have a sip-implementors mailing list, right? Personally, I think ICE is the best solution we have. We KNOW of cases where hole-punching doesn't work, and I think ICE will produce usable results in most of those cases. But that's just my personal opinion from reading the specs. I haven't implemented ICE, and I haven't used anybody else's implementation. Sure, it's complex, but that's because the underlying problem is complex -- there are just too many different behaviors out there in "NAT and firewall land". Of course, I could be wrong, too. It's happened before, once or twice ;-). Just how sure are we that we're right about this? Are we designing a "spruce goose" or a practical system? Only experience will tell us. But some good flight reports from the prototypes could go a long way towards reassuring us of the design's utility. So far we've had a couple of people report hearsay evidence -- that somebody else has an ICE implementation and it works. Any of you folks have personal experience you can share? Have there been prototypes exercised at the interop events? -- Dean _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 21:19:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKfg-00007E-Ti; Wed, 18 Jul 2007 21:19:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBKff-00006s-QO for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 21:19:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKff-00006j-Fv; Wed, 18 Jul 2007 21:19:11 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBKff-00074j-1F; Wed, 18 Jul 2007 21:19:11 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBKfe-0001iS-22; Wed, 18 Jul 2007 21:19:10 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.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: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 21:19:21 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: behave@ietf.org, mmusic@ietf.org, sip@ietf.org, p2psip@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 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > Phil, > >> In my view, ICE _is_ a "Hole Punching Technique". > > Yes, you absolutely right, though the devil is in the details. > > We cannot go here into a shoot-out between hole punching or other > mentioned on the list vs. ICE, but there seems to be a huge difference > in effectiveness and performance. What precise algorithm are you talking about when you say this? As far as I am concerned, ICE is simply a well-documented hole punching algorithm. It differs from others that I have seen written up in the following ways: - ICE has the concept of peer reflexive addresses, which other hole- punching techniques that I have seen do not; - ICE has the concept of controlling/controlled endpoint, which gives the controller additional flexibility in choosing a path; - ICE does NOT have the concept of port prediction, which some other techniques do (e.g., Saikat's TCP work). Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 21: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 1IBLGh-0005MQ-Dr; Wed, 18 Jul 2007 21:57:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBLGf-0005LV-GU for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 21:57:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLGe-0005LB-OZ; Wed, 18 Jul 2007 21:57:24 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBLGe-0008V8-CK; Wed, 18 Jul 2007 21:57:24 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBLGc-0007uL-2v; Wed, 18 Jul 2007 21:57:23 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 21:57:34 -0400 To: Henry Sinnreich , Magnus Westerlund , Behave WG , IETF MMUSIC WG , sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 18-Jul-07, at 21:19 , Philip Matthews wrote: > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > >> Phil, >> >>> In my view, ICE _is_ a "Hole Punching Technique". >> >> Yes, you absolutely right, though the devil is in the details. >> >> We cannot go here into a shoot-out between hole punching or other >> mentioned on the list vs. ICE, but there seems to be a huge >> difference >> in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; > - ICE has the concept of controlling/controlled endpoint, which > gives the controller additional flexibility in choosing a path; > - ICE does NOT have the concept of port prediction, which some > other techniques do (e.g., Saikat's TCP work). I should add that ICE also handles: - the case of multi-homed peers, - peers that want to exchange multiple media streams, - media streams which are composed of multiple components (e.g. RTP and RTCP). These are cases that a solution for SIP needs to handle, but I have not seen discussed in other proposals. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 22:56: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 1IBMBp-0004IM-Ff; Wed, 18 Jul 2007 22:56:29 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBMBn-0004HU-B8 for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 22:56:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMBm-0004HA-Kp; Wed, 18 Jul 2007 22:56:26 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBMBm-00089X-6y; Wed, 18 Jul 2007 22:56:26 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 2E7CD75804E; Wed, 18 Jul 2007 21:56:25 -0500 (CDT) Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC From: "Frank W. Miller" To: Philip Matthews In-Reply-To: References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 20:56:09 -0600 Message-Id: <1184813769.3347.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Henry Sinnreich , p2psip@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 Wed, 2007-07-18 at 21:19 -0400, Philip Matthews wrote: > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > > > Phil, > > > >> In my view, ICE _is_ a "Hole Punching Technique". > > > > Yes, you absolutely right, though the devil is in the details. > > > > We cannot go here into a shoot-out between hole punching or other > > mentioned on the list vs. ICE, but there seems to be a huge difference > > in effectiveness and performance. > > What precise algorithm are you talking about when you say this? Well, here's the algorithm I use with my UA (the most recent versions I might add): STUN UA Registrar Server | REGISTER | | |-5060------->| | | w/rport | | | | | | 200 OK | | |<5060--------| | | | | | | | | STUN BReq | | |-5060--------------------->| | STUN BReq | | |-5004--------------------->| | STUN BResp | | |<5060----------------------| | STUN BResp | | |<5004----------------------| | | | | . | | | . | | | 10sec | | | . | | | . | | | | | | STUN BReq | | |-5060--------------------->| | STUN BResp | | |<5060----------------------| | STUN BReq | | |-5004--------------------->| | STUN BResp | | |<5004----------------------| | | | | | | I pick up the rport addressing during the REGISTER transaction because of the way my multithreading is done and because its nice to see the same value coming from two different sources out on the Internet. The port numbers on the UA are local port numbers. STUN BReq is a STUN binding request and STUN BResp is a STUN binding response. Port 5004 is for a single RTP session but the same algorithm is usable for any and all UDP ports you need, e.g. additional session ports and RTCP. The difference in order in the first and second sequence is intentional, the implementation doesn't care when the responses show up. This algorithm lets the UA know what its "visible" IP address and port is all the time (assuming that rport and STUN are working) and keeps it the same assuming that the NAT doesn't change it unilaterally (which I have yet to see BTW). When signaling occurs, the "visible" IP address and port are used in the Contact headers for SIP and in the SDP for offers/answers for RTP. Its just about as simple as it gets and I know you're going to say that it doesn't work 100% of the time. I haven't measured how well its done in deployments I've done as yet. I guess I need to do something along those lines. The good news is, I haven't had anyone complain about it so I guess I've been lucky. So let me have it... ;) Thanks, FM _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jul 18 22:56:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMC5-0004f3-Vc; Wed, 18 Jul 2007 22:56:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBMC4-0004eW-UO for behave-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 22:56:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMC4-0004e6-I9; Wed, 18 Jul 2007 22:56:44 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBMC3-00089s-6g; Wed, 18 Jul 2007 22:56:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2007 19:56:42 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJ9vnkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,553,1175497200"; d="scan'208"; a="184645472:sNHT33227658" 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 l6J2ugHS028945; Wed, 18 Jul 2007 19:56:42 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l6J2ufA1012744; Thu, 19 Jul 2007 02:56:41 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 19:55:30 -0700 To: SIP , Behave WG , mmusic@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8440; t=1184813802; x=1185677802; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=x+KWwSoKmqIEePOlsgp20zWpePInK2ZzORIHZTzbieU=; b=QBtjhv25FY3TyBQl1jiHLQF6wwNpKdvOpybfov2JXLOf3YZyd8T8LPY+bM5Gc/2Kwlr8v/YL ppKVaktamhwEHc1R4Q/6zQEm9K4yQwozW1dZ5X5EfgYpHzqfhII1T24j; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 First I apologize for the cross post - this is a mmusic draft, I would appreciate replies on the mmusic list only. Few things I am looking for here .... 1) specific reasons why this work is less appropriate for standards track than other work that IETF puts on the standards track. Keep in mind the first step of standards track is Proposed Standards which requires basically no interoperability, then it could move to Draft Standard where interoperability is shown and finally Full Standard if it turns out to be a good idea. If you are going to post a reply to this point, make sure you have read RFC 2026. 2) I am interested in the specifics of problems that ICE fails to solve that the WG has not previous considered. There are lots of people that have implemented versions of it and think it is a good idea - if people are having some problems with it, I'd love to hear about details of things that are wrong. That it has a lot of messages in some use cases has been known for a long time. It used to have far more messages - engineering was done to consider what was a reasonable amount for call set up times and a new design was done to bring the message to a level most people invovled with the design felt was reasonable. If there are specific other than these that are wrong and not considered in the design, now would be a good time to get them on the table. 3) If people think that Skype for example has a simpler solution that works better than ICE. Feel free to describe exactly what it is. Several people invovled with the ICE design have looked in extreme detail at Skype and others and so far none of them have come back with what we should do different than ICE. 4) ICE can be used in a mode where it only provided the reflexive candidate. People were pretty clear that this was far inferior to the modes where there are other candidates. If someone would like to provide exactly how hole punching works better than this very limited ICE technique, I'd be glad to hear the details. This has certainly been an topic that any could have brought up over the last several years. If someone has specifics, I suggest they get out a full proposal really soon. I am very doubtful that hole punching solution is fundamentally different than the type of hole punching ICE does. 5) Some people have suggested that if all NATs were behave complaint, then we would not need ICE. I strongly disagree. I think the only part of ICE we would not need is the TURN relays which are more or less an optional part. Again, specifics on what can be removed are welcome. ICE is far more complicated that anyone wants - the problem is, no one has come up with a proposal that looks like it comes anywhere close to meeting the requirements and if simpler. The design space has been extensively explored by many people. The raw data to understand what will work on what NATs have been painfully tested and documented in publications such as: http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt https://www.guha.cc/saikat/stunt-results.php? (Ford used to have a page too but it seems to be gone) I have a very open mind to considering better ways to do ICE - but I need specific suggestions or it is impossible for me to really think about if the suggestions represent a better path or not. I would love to see more open source ICE code (there is lots already) - I feel that this is an area where ICE is likely just table stakes and owning an proprietary ICE stack will not turn out to be a competitive advantage. Having open source implementations where the development cost was shared and everyone could get working products to market faster would be an advantage to companies. Clearly I expect the bulk of ICE implementations to not be open source but I still would be keen on doing what I can to contribute to an open source version as personally I feel that is in the interest of end users, my employer, and the IETF as a SDO. Cullen On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: > > On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > >> Henry Sinnreich skrev: >>> Following some discussions and soul searching, the best approach for >>> ICE-17 for LC would be to _go ahead and make it an experimental >>> RFC_. >>> This would support the development of interoperable >>> implementations, the >>> collection of deployment data and also hopefully open source code. >>> Though I have full faith in ICE, following the practices that >>> made the >>> IETF successful take precedent here, I believe. >>> This is a change from the attached that I wrote on 7/16/2007. >>> Note: We can only hope the proliferation of SBC in VoIP service >>> provider >>> networks will not make these concerns and ICE for SIP a moot >>> issue, but >>> this is another topic. >> >> Henry, >> >> I don't quite understand why you are requesting a status change of >> ICE? To me it appears that ICE is almost finished spec. It has >> been implemented, used and feedback has been influencing the >> protocol. It is definitly one of the better examples of current >> IETF work that actually has running code. Sure, the >> implementations may not be fully updated yet to the latest draft >> version. But I think it is safe to say that ICE works in the >> intended core cases. If there are some corner cases where it >> fails, that may be. But that is not information we will have until >> really large scale deployement or someone makes very extensive tests. > > Henry has, I believe, been very consistent in urging the IETF to > have more "running code" experience on every specification (not > just ICE) than our process requires. He has, IIRC, also advocated > changing the process to require running code before publishing an > RFC. He's even suggested at times that one should have running code > before submitting a protocol draft. > > Another point to consider -- I've known Henry to bark at a tree > with no squirrel in it occasionally, but most of the time he's > pretty reliable, more so than most technology predictors. If he's > worried about ICE, it's probably because he's been talking to > people who are trying to implement it and they're telling him it is > difficult or that they're having performance or reliability issues. > I imagine that there are plenty of internal development teams in > various companies that are working on this and not necessarily > bringing their results back to the IETF. After all, if everybody > sees the emperor as fully clothed, they'd be embarrassed to > proclaim otherwise. Of course, I wish all of these developers were > tied into the IETF, but then I'm sure I don't want to see every ice- > implementor's question on the SIP list. That is why we have a sip- > implementors mailing list, right? > > Personally, I think ICE is the best solution we have. We KNOW of > cases where hole-punching doesn't work, and I think ICE will > produce usable results in most of those cases. But that's just my > personal opinion from reading the specs. I haven't implemented ICE, > and I haven't used anybody else's implementation. Sure, it's > complex, but that's because the underlying problem is complex -- > there are just too many different behaviors out there in "NAT and > firewall land". Of course, I could be wrong, too. It's happened > before, once or twice ;-). Just how sure are we that we're right > about this? > > Are we designing a "spruce goose" or a practical system? Only > experience will tell us. But some good flight reports from the > prototypes could go a long way towards reassuring us of the > design's utility. > > So far we've had a couple of people report hearsay evidence -- that > somebody else has an ICE implementation and it works. Any of you > folks have personal experience you can share? Have there been > prototypes exercised at the interop events? > > -- > Dean > > > > > _______________________________________________ > 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 Jul 19 04:39:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBRXY-0007yx-5s; Thu, 19 Jul 2007 04:39:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBRXW-0007wW-PF for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 04:39:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBRXT-0007f9-3a for behave@ietf.org; Thu, 19 Jul 2007 04:39:11 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBRXS-0006ut-An for behave@ietf.org; Thu, 19 Jul 2007 04:39:11 -0400 Received: by py-out-1112.google.com with SMTP id f31so1550883pyh for ; Thu, 19 Jul 2007 01:39:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FjQMJqivfPsIAazJq0tGoRzH2E7dfvTaePPYYmweg9OpdOHac0wSMJLjyHaMDghK1oAgC3dM6NXuXEUcYm5fCTYPjwAI3El4ybPphJBvOtkg10zBLPqSjTwS5xEE57fPXFsre0PaVs54+H63t/myErUVF0qD7zUb5iGmDk5R+xk= 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=CmvL1W0aN746q2VJKvZYgWy5b450M+55KEQp7MfGSayxWHP1B9BvMJyxqbmrKFUNocg7nlpudZaH6rOxs6g0AMnQNAr5OhOsL4jV2ezBk1wv5wK4yXLYD//qVgnyMNSZbw+Mm4Q4KWWwAXrjV3E+yEg7mi/vTokVLTlMKQj5N7g= Received: by 10.35.82.16 with SMTP id j16mr4113335pyl.1184834350009; Thu, 19 Jul 2007 01:39:10 -0700 (PDT) Received: by 10.35.57.10 with HTTP; Thu, 19 Jul 2007 01:39:09 -0700 (PDT) Message-ID: Date: Thu, 19 Jul 2007 14:09:09 +0530 From: "Mayank Dev Sondhi" To: "Marc Petit-Huguenin" Subject: Re: [BEHAVE] Redirect for STUN Relay In-Reply-To: <468D0B13.6080007@acm.org> MIME-Version: 1.0 References: <033458F56EC2A64E8D2D7B759FA3E7E718801D@sonusmail04.sonusnet.com> <200707050909.05231.remi.denis-courmont@nokia.com> <033458F56EC2A64E8D2D7B759FA3E7E718801F@sonusmail04.sonusnet.com> <468D0705.70609@cisco.com> <468D0B13.6080007@acm.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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="===============1016513031==" Errors-To: behave-bounces@ietf.org --===============1016513031== Content-Type: multipart/alternative; boundary="----=_Part_16326_21333038.1184834349926" ------=_Part_16326_21333038.1184834349926 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline +1 for me too, we use the 300 response for working WITH our load balancers, this is definitely useful. As for security issues, we rely on Message-Integrity to protect the address. Ping-ponging across servers is left to the client to handle appropriately(fixed number of retries before giving up) -Mayank On 7/5/07, Marc Petit-Huguenin wrote: > > Jonathan Rosenberg wrote: > > Actually, this is something which we were planning on removing in the > > revision coming up. There were comments during last call about the > > utility of the mechanism, security concerns, and so on. Also there > > didn't seem to be anyone who wanted it. > > OK, I missed the discussion, because I use the 300 response, and plan to > continue to use it. I also proposed a long time ago to replace the IP > address in the 300 response by a name so the SRV RR processing can be > reapplied, but without success. > > There are much better ways of > > doing load balacning, for example utilizing a front-end load balancing > > element that actually tracks capacity of back end relays, and then > > directs the request to the least loaded server. THis is standard > > practice for load balancing for many other protocols. > > This also force to buy expensive stuff that is not needed with the end > to end mechanisms. It's OK if people want to use B2BUA, SBC, load > balancers, NAT - their money, not mine - but Internet standards should > not force people to do this. > > So I am strongly opposed to remove the 300 response from STUN. > > > That kind of > > mechanism is also faster and more stable. Redirect mechanisms can resul= t > > in ping-ponging especially near capacity limits. > > > > -Jonathan R. > > > > Asveren, Tolga wrote: > >> O.K., sorry my bad. > >> > >> Thanks, > >> Tolga > >> > >>> -----Original Message----- > >>> From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] > >>> Sent: Thursday, July 05, 2007 2:09 AM > >>> To: behave@ietf.org; Asveren, Tolga > >>> Subject: Re: [BEHAVE] Redirect for STUN Relay > >>> > >>> On Thursday 05 July 2007 05:30:06 ext Asveren, Tolga wrote: > >>>> I was wondering whether it would make sense to have redirect type of > >>>> functionality for STUN Relay, e.g. referring another server in a > >>>> negative answer to an initial allocate request. > >>> This is *already* in the specification, and has been there for severa= l > >>> years. > >>> > >>> -- > >>> R=E9mi Denis-Courmont > > -- > 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 > ------=_Part_16326_21333038.1184834349926 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
+1 for me too, we use the 300 response for working WITH our load balan= cers, this is definitely useful. As for security issues, we rely on Message= -Integrity to protect the address. Ping-ponging across servers is left to t= he client to handle appropriately(fixed number of retries before giving up)
 
-Mayank

 
On 7/5/07, M= arc Petit-Huguenin <petithug@acm= .org> wrote:
Jonathan Rosenberg wrote:
>= ; Actually, this is something which we were planning on removing in the
> revision coming up. There were comments during last call about the
= > utility of the mechanism, security concerns, and so on. Also there
= > didn't seem to be anyone who wanted it.

OK, I missed the di= scussion, because I use the 300 response, and plan to
continue to use it.  I also proposed a long time ago to repla= ce the IP
address in the 300 response by a name so the SRV RR processing= can be
reapplied, but without success.

There are much better way= s of
> doing load balacning, for example utilizing a front-end load balancing=
> element that actually tracks capacity of back end relays, and then=
> directs the request to the least loaded server. THis is standard
> practice for load balancing for many other protocols.

This = also force to buy expensive stuff that is not needed with the end
to end= mechanisms.  It's OK if people want to use B2BUA, SBC, load<= br>balancers, NAT - their money, not mine - but Internet standards should
not force people to do this.

So I am strongly opposed to remove = the 300 response from STUN.

> That kind of
> mechanism is a= lso faster and more stable. Redirect mechanisms can result
> in ping-= ponging especially near capacity limits.
>
> -Jonathan R.
>
> Asveren, Tolga wrote:
>= > O.K., sorry my bad.
>>
>>   Thanks,
>= ;>   Tolga
>>
>>> -----Original Message--= ---
>>> From: R=E9mi Denis-Courmont [mailto: remi.denis-courmont@nokia.= com]
>>> Sent: Thursday, July 05, 2007 2:09 AM
>>&= gt; To: behave@ietf.org; Asveren, To= lga
>>> Subject: Re: [BEHAVE] Redirect for STUN Relay
>>&= gt;
>>> On Thursday 05 July 2007 05:30:06 ext Asveren, Tolga wr= ote:
>>>> I was wondering whether it would make sense to hav= e redirect type of
>>>> functionality for STUN Relay, e.g. referring another s= erver in a
>>>> negative answer to an initial allocate reque= st.
>>> This is *already* in the specification, and has been th= ere for several
>>> years.
>>>
>>> --
>>> = R=E9mi Denis-Courmont

--
Marc Petit-Huguenin   &nb= sp;       [     &nbs= p;            &= nbsp;           &nbs= p;  ]
Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ]
Work: marc@8x8.com     = ;       [     &= nbsp;           &nbs= p;            &= nbsp;  ]


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

------=_Part_16326_21333038.1184834349926-- --===============1016513031== 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 --===============1016513031==-- From behave-bounces@ietf.org Thu Jul 19 06:16: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 1IBT3L-0003S5-JV; Thu, 19 Jul 2007 06:16:11 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBT3I-0003KL-GN for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 06:16:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBT3H-0003FV-Df for behave@ietf.org; Thu, 19 Jul 2007 06:16:07 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBT3G-0002d8-3a for behave@ietf.org; Thu, 19 Jul 2007 06:16:07 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Thu, 19 Jul 2007 03:15:57 -0700 From: "David Barrett" To: "'Cullen Jennings'" , "'SIP'" , "'Behave WG'" , Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 03:15:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfJsHPx6frYreoETXCtB795NMQVMAANmm8Q X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Message-Id: 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 Hi Cullen, I think you bring up lot of really great and detailed questions. However, speaking for myself at least, answering those questions doesn't really address my concern. All I want to know is: Does ICE work, and how well? What "works" means is entirely open to debate. I've tossed out "high peer connectivity" and "low connection setup time" as the most important criteria, and I've put hard data behind those numbers as a stake in the ground for comparison, but I'm open to other metrics as well. But regardless of the metrics, I want somebody who uses it and loves it and bases their business upon its success to stand up and explain why it's great. And I want this person to provide real-world data, sampled on a wide scale, proving that ICE "works" -- by any definition. Basically, I want ICE firmly grounded in wide-scale testing and real-world data, and answering the questions below doesn't bring us any closer to that. Whether it's level 10 or level 12 doesn't produce new data. How its algorithms differ from competing ones doesn't show that they're any better or worse. Detailed proposals for change don't shed any light on whether those changes improve or worsen it, because its current state is completely unmeasured. The most powerful thing the IETF can do to standardize the world upon ICE is prove that it works better than any alternative. Because until that's proven, we just need to take it as a matter of faith. -david > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, July 18, 2007 7:56 PM > To: SIP; Behave WG; mmusic@ietf.org > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > > First I apologize for the cross post - this is a mmusic draft, I > would appreciate replies on the mmusic list only. > > Few things I am looking for here .... > > 1) specific reasons why this work is less appropriate for standards > track than other work that IETF puts on the standards track. Keep in > mind the first step of standards track is Proposed Standards which > requires basically no interoperability, then it could move to Draft > Standard where interoperability is shown and finally Full Standard if > it turns out to be a good idea. If you are going to post a reply to > this point, make sure you have read RFC 2026. > > 2) I am interested in the specifics of problems that ICE fails to > solve that the WG has not previous considered. There are lots of > people that have implemented versions of it and think it is a good > idea - if people are having some problems with it, I'd love to hear > about details of things that are wrong. That it has a lot of messages > in some use cases has been known for a long time. It used to have far > more messages - engineering was done to consider what was a > reasonable amount for call set up times and a new design was done to > bring the message to a level most people invovled with the design > felt was reasonable. If there are specific other than these that are > wrong and not considered in the design, now would be a good time to > get them on the table. > > 3) If people think that Skype for example has a simpler solution that > works better than ICE. Feel free to describe exactly what it is. > Several people invovled with the ICE design have looked in extreme > detail at Skype and others and so far none of them have come back > with what we should do different than ICE. > > 4) ICE can be used in a mode where it only provided the reflexive > candidate. People were pretty clear that this was far inferior to the > modes where there are other candidates. If someone would like to > provide exactly how hole punching works better than this very limited > ICE technique, I'd be glad to hear the details. This has certainly > been an topic that any could have brought up over the last several > years. If someone has specifics, I suggest they get out a full > proposal really soon. I am very doubtful that hole punching solution > is fundamentally different than the type of hole punching ICE does. > > 5) Some people have suggested that if all NATs were behave complaint, > then we would not need ICE. I strongly disagree. I think the only > part of ICE we would not need is the TURN relays which are more or > less an optional part. Again, specifics on what can be removed are > welcome. > > ICE is far more complicated that anyone wants - the problem is, no > one has come up with a proposal that looks like it comes anywhere > close to meeting the requirements and if simpler. The design space > has been extensively explored by many people. The raw data to > understand what will work on what NATs have been painfully tested and > documented in publications such as: > > http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf > > http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt > > https://www.guha.cc/saikat/stunt-results.php? > > (Ford used to have a page too but it seems to be gone) > > I have a very open mind to considering better ways to do ICE - but I > need specific suggestions or it is impossible for me to really think > about if the suggestions represent a better path or not. > > I would love to see more open source ICE code (there is lots already) > - I feel that this is an area where ICE is likely just table stakes > and owning an proprietary ICE stack will not turn out to be a > competitive advantage. Having open source implementations where the > development cost was shared and everyone could get working products > to market faster would be an advantage to companies. Clearly I expect > the bulk of ICE implementations to not be open source but I still > would be keen on doing what I can to contribute to an open source > version as personally I feel that is in the interest of end users, my > employer, and the IETF as a SDO. > > Cullen > > > > On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: > > > > > On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > > > >> Henry Sinnreich skrev: > >>> Following some discussions and soul searching, the best approach for > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >>> This would support the development of interoperable > >>> implementations, the > >>> collection of deployment data and also hopefully open source code. > >>> Though I have full faith in ICE, following the practices that > >>> made the > >>> IETF successful take precedent here, I believe. > >>> This is a change from the attached that I wrote on 7/16/2007. > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >>> this is another topic. > >> > >> Henry, > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? To me it appears that ICE is almost finished spec. It has > >> been implemented, used and feedback has been influencing the > >> protocol. It is definitly one of the better examples of current > >> IETF work that actually has running code. Sure, the > >> implementations may not be fully updated yet to the latest draft > >> version. But I think it is safe to say that ICE works in the > >> intended core cases. If there are some corner cases where it > >> fails, that may be. But that is not information we will have until > >> really large scale deployement or someone makes very extensive tests. > > > > Henry has, I believe, been very consistent in urging the IETF to > > have more "running code" experience on every specification (not > > just ICE) than our process requires. He has, IIRC, also advocated > > changing the process to require running code before publishing an > > RFC. He's even suggested at times that one should have running code > > before submitting a protocol draft. > > > > Another point to consider -- I've known Henry to bark at a tree > > with no squirrel in it occasionally, but most of the time he's > > pretty reliable, more so than most technology predictors. If he's > > worried about ICE, it's probably because he's been talking to > > people who are trying to implement it and they're telling him it is > > difficult or that they're having performance or reliability issues. > > I imagine that there are plenty of internal development teams in > > various companies that are working on this and not necessarily > > bringing their results back to the IETF. After all, if everybody > > sees the emperor as fully clothed, they'd be embarrassed to > > proclaim otherwise. Of course, I wish all of these developers were > > tied into the IETF, but then I'm sure I don't want to see every ice- > > implementor's question on the SIP list. That is why we have a sip- > > implementors mailing list, right? > > > > Personally, I think ICE is the best solution we have. We KNOW of > > cases where hole-punching doesn't work, and I think ICE will > > produce usable results in most of those cases. But that's just my > > personal opinion from reading the specs. I haven't implemented ICE, > > and I haven't used anybody else's implementation. Sure, it's > > complex, but that's because the underlying problem is complex -- > > there are just too many different behaviors out there in "NAT and > > firewall land". Of course, I could be wrong, too. It's happened > > before, once or twice ;-). Just how sure are we that we're right > > about this? > > > > Are we designing a "spruce goose" or a practical system? Only > > experience will tell us. But some good flight reports from the > > prototypes could go a long way towards reassuring us of the > > design's utility. > > > > So far we've had a couple of people report hearsay evidence -- that > > somebody else has an ICE implementation and it works. Any of you > > folks have personal experience you can share? Have there been > > prototypes exercised at the interop events? > > > > -- > > Dean > > > > > > > > > > _______________________________________________ > > 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 Jul 19 07:57: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 1IBUdP-0007Es-Ct; Thu, 19 Jul 2007 07:57:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBUdN-0007EU-3X for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 07:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBUdM-0007EB-GZ; Thu, 19 Jul 2007 07:57:28 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBUdL-0003WS-UH; Thu, 19 Jul 2007 07:57:28 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1IBUdP-0007Eb-Em; Thu, 19 Jul 2007 07:57:31 -0400 In-Reply-To: <1184813769.3347.32.camel@localhost.localdomain> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> <1184813769.3347.32.camel@localhost.localdomain> 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: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 07:57:36 -0400 To: "Frank W. Miller" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Behave WG , IETF MMUSIC WG , sip@ietf.org, Henry Sinnreich , P2PSIP Mailing List X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 18-Jul-07, at 22:56 , Frank W. Miller wrote: > > Its just about as simple as it gets and I know you're going to say > that > it doesn't work 100% of the time. I haven't measured how well its > done > in deployments I've done as yet. I guess I need to do something along > those lines. The good news is, I haven't had anyone complain about it > so I guess I've been lucky. So let me have it... ;) This is the original STUN algorithm. One situation where it fails is the following: STUN server | NAT | ------------------ | | UA1 UA2 If the NAT does not support hairpinning, then your algorithm will not work. [http://tools.ietf.org/html/draft-jennings-behave-test-results-04 shows that most NATs today do not support UDP hairpinning, and http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf reports that most do not support TCP hairpinning.] This situation can occur when the two UAs belong to the same company, or both are in the same hotel, or both use the same service provider and the service provider has a NAT in front of its entire network, etc. ICE does to things to solve this problem. First of all, UA1 and UA2 exchange their local addresses and ports as well as their STUN-learned addresses. They then test to see which path works. Second, they also exchange TURN addresses, which serve as a backup in case everything else fails. David Barrett's algorithm, if I understand it correctly, would work in this situation. (As far as I can tell, David's is a simplified version of ICE). - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 08:34:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVDJ-00043G-Ln; Thu, 19 Jul 2007 08:34:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBVDH-00042o-LC for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:34:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVDH-00042g-Bb for behave@ietf.org; Thu, 19 Jul 2007 08:34:35 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVDG-0004sY-3F for behave@ietf.org; Thu, 19 Jul 2007 08:34:35 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1078910uge for ; Thu, 19 Jul 2007 05:34:33 -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:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UNakZPUx27Cy/SqWupo45VOLE+HMOBJtAZO03MD6PdNVcLzBQoMMQ++7jk/snrfSHN+GJE16Sinpn+MZZCqfxF1woIH9K5Q57X8bwoDn8WXx5xmBhqhw6sb1lcgIy7l5mllyrPkp/Zv2bs+PAyRwnDeedNuYvz8fG25TNQcn8YI= 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:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FrBc6ERmVluMErLQglaWd5/7sNRarH0TaN2Zgci8z4yfPRw18fH913NcxpJSImLwSjGj5Ce9VKe35YcinNhTw0l6jIa4JhjmQqJRJ5Loda0FLno2LmXUQAWVvhfz5oMw4EoZDTWKCrGOThRn+sBbWUoV3Z6T4p/ySTGXOvOf6u8= Received: by 10.86.68.16 with SMTP id q16mr1892016fga.1184848473186; Thu, 19 Jul 2007 05:34:33 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTPS id j12sm4386186fkf.2007.07.19.05.34.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Jul 2007 05:34:32 -0700 (PDT) Message-ID: <469F5A56.9010908@gmail.com> Date: Thu, 19 Jul 2007 22:34:30 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> In-Reply-To: <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: SIP , Behave WG , mmusic@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 Cullen Jennings wrote: > I would love to see more open source ICE code (there is lots already) Could you point me to the _lots_ of open source ICE code? Is there any open source implementation which supports TURN? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 08:57:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVZe-0003yB-02; Thu, 19 Jul 2007 08:57:42 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBVZb-0003xx-KY for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:57:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVZb-0003xp-AO; Thu, 19 Jul 2007 08:57:39 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBVZa-0007ll-Qt; Thu, 19 Jul 2007 08:57:39 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6JCvI7u012825; Thu, 19 Jul 2007 15:57:33 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:57:21 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:57:21 +0300 Received: from hed050126.research.nokia.com ([172.21.50.126]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:57:21 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 15:57:19 +0300 User-Agent: KMail/1.9.6 References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> <469F5A56.9010908@gmail.com> In-Reply-To: <469F5A56.9010908@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707191557.20173.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 19 Jul 2007 12:57:21.0349 (UTC) FILETIME=[584D4F50:01C7CA04] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Thursday 19 July 2007 15:34:30 ext Evgeniy Khramtsov wrote: > Cullen Jennings wrote: > > I would love to see more open source ICE code (there is lots already) > > Could you point me to the _lots_ of open source ICE code? Is there any > open source implementation which supports TURN? I doubt this be much relevant, since hole punching does not support TURN or= =20 anything equivalent either. =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 Jul 19 09: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 1IBVh2-00054W-Ch; Thu, 19 Jul 2007 09:05:20 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBVh1-00054R-E6 for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 09:05:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVh1-00054J-4a for behave@ietf.org; Thu, 19 Jul 2007 09:05:19 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVh0-0005xO-PG for behave@ietf.org; Thu, 19 Jul 2007 09:05:19 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1IBVh0-00061R-L9; Thu, 19 Jul 2007 09:05:18 -0400 In-Reply-To: <049501c7c89d$d34da410$7d646b80@amer.cisco.com> References: <049501c7c89d$d34da410$7d646b80@amer.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] RE: ICE performance Date: Thu, 19 Jul 2007 09:05:30 -0400 To: Dan Wing , David Barrett X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Behave WG , Bryan Ford , Dan Kegel , Henry Sinnreich , henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 17-Jul-07, at 14:10 , Dan Wing wrote: > >>> In some cases [such as two endpoints behind 'symmetric' >>> NATs (RFC3489 >>> terminology) or non-Endpoint-Independent Mapping NATs (RFC4787 >>> terminology)] there is no reliable technique to get a >>> direct peer-to- >>> peer connection. The unreliable technique to establish a direct >>> peer-to-peer connection in that situation is to guess the >>> port number assigned by the remote NAT. >> >> Correct. Does ICE support this? > > No, ICE doesn't do that. Doing such hunting is only has a chance > of success if the NAT is quiescent and if the NAT has some > predictability in its UDP port assignment (assigns the next- > higher port, for example). > >> I haven't had great luck with it myself, >> but I haven't put a lot of energy into it yet. > > Some NAT traversal techniques (such as in some games) try to > guess ports, and exchange tokens (much like ICE's usernames) to > see if they're talking to the intended peer. > > I wouldn't recommend using that technique. I will just note that Saikat implemented port prediction in his TCP study and found it worked pretty well. http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf However, I think his setup was more of a test setup rather than a production setup. Perhaps Saikat can tell us more. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 09:16: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 1IBVs5-0004xz-Nb; Thu, 19 Jul 2007 09:16:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBVs4-0004xr-IS for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 09:16:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVs4-0004xj-92 for behave@ietf.org; Thu, 19 Jul 2007 09:16:44 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVs3-0006Ej-UD for behave@ietf.org; Thu, 19 Jul 2007 09:16:44 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1098475uge for ; Thu, 19 Jul 2007 06:16:43 -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:references:in-reply-to:content-type:content-transfer-encoding; b=iTnQ0Y5tWfKr4pYKF9kFi6hNx2T1baoAw1n8wobFAC5asJus7vpzeopd5JnlQa3PknrQfjxRzTeHkpc4Nfdt5LTTQ4jQp8DjbFLSaoqIwudRrG+hA8qSXXyD9GqlJUmSg1Qcow4VWlnJgx43UNgc1mfTsxc0hB4nqz2FQIldc9s= 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:references:in-reply-to:content-type:content-transfer-encoding; b=N8a80Ke6kS+MxH7loiwfd6KIfkkSVKUwiNpXbccgUc8G/Py5QKLbvne2clXzhfog6ZMsYuOf7FsWntu/U3mCULyL1D226gGIcs25kLjyNTKRhotcJGgZduj1CD9qo185YM5rLWvcWh/1kiisLPSILF7Vrngd6sjFBVF0wQgWX6U= Received: by 10.86.51.2 with SMTP id y2mr1933891fgy.1184851003261; Thu, 19 Jul 2007 06:16:43 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTPS id e32sm4440211fke.2007.07.19.06.16.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Jul 2007 06:16:42 -0700 (PDT) Message-ID: <469F643A.9070606@gmail.com> Date: Thu, 19 Jul 2007 23:16:42 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: behave@ietf.org Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> <469F5A56.9010908@gmail.com> <200707191557.20173.remi.denis-courmont@nokia.com> In-Reply-To: <200707191557.20173.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org RĂ©mi Denis-Courmont wrote: > > >I doubt this be much relevant, since hole punching does not support TURN or >anything equivalent either. > > > What do you mean? I am not talking about "hole punching". I'm talking about ICE. ICE makes use of TURN, so ICE implementations should support TURN :) Am I wrong? :) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 09:52: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 1IBWQc-0006tn-W9; Thu, 19 Jul 2007 09:52:26 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBWQb-0006tc-5e for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 09:52:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWQa-0006tT-Rj for behave@ietf.org; Thu, 19 Jul 2007 09:52:24 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBWQZ-0000rJ-5Z for behave@ietf.org; Thu, 19 Jul 2007 09:52:24 -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 l6JDpubY007917; Thu, 19 Jul 2007 16:52:20 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 16:52:17 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 16:52:17 +0300 Received: from hed050126.research.nokia.com ([172.21.50.126]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 16:52:16 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 16:52:15 +0300 User-Agent: KMail/1.9.6 References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <200707191557.20173.remi.denis-courmont@nokia.com> <469F643A.9070606@gmail.com> In-Reply-To: <469F643A.9070606@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707191652.15760.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 19 Jul 2007 13:52:17.0046 (UTC) FILETIME=[04B0C360:01C7CA0C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) 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 On Thursday 19 July 2007 16:16:42 ext Evgeniy Khramtsov wrote: > R=C3=A9mi Denis-Courmont wrote: > >I doubt this be much relevant, since hole punching does not support TURN > > or anything equivalent either. > > What do you mean? I am not talking about "hole punching". I'm talking > about ICE. ICE makes use of TURN, so ICE implementations should support > TURN :) Am I wrong? :) TURN is an *optional* add-on to ICE to support symmetric NATs and other=20 worst-cases scenario that hole punching (whether ICE or otherwise) cannot=20 solve. As such, support for TURN only improves the reliability of ICE way beyond w= hat=20 pure hole punching does. You can still use ICE without TURN, and get better= =20 results than what pure RFC3489-based hole punching would. =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 Jul 19 09:59: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 1IBWXS-00037X-Tk; Thu, 19 Jul 2007 09:59:30 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBWXR-00036m-Lg for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 09:59:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWXR-00036c-Ai; Thu, 19 Jul 2007 09:59:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBWXP-0007Qs-Lr; Thu, 19 Jul 2007 09:59:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Jul 2007 06:59:26 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAE4Kn0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="184927225:sNHT62504640" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6JDxQo6000569; Thu, 19 Jul 2007 06:59:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6JDxQTb015331; Thu, 19 Jul 2007 13:59:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 06:59:26 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 06:59:25 -0700 Message-ID: <469F6E43.5050709@cisco.com> Date: Thu, 19 Jul 2007 09:59:31 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: David Barrett Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 13:59:25.0674 (UTC) FILETIME=[042C34A0:01C7CA0D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20638; t=1184853566; x=1185717566; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=kegm+GYDfRgP2LF/vwfjfUl7bEXiE1E+NDEidfORIVA=; b=USy6VQ3LvedwHSAHFhE0QW2GAsw+xCh0sVEgMXnqe9pcHEsroQ+1t5d5fAVPg9a92UkPrHr5 31n0RSbagRMrrsOnr/hLBlZg4dmD05MOiu2xLgb2fVfxfsGDtHIZ4wnc29XQ3Gh/gIQXgmY4ND woDpsfpx3YS/NsA3Vv3V1RTL4=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Cc: 'SIP' , 'Behave WG' , mmusic@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 There are in fact deployments of ICE, more than one, based on previous versions of the draft. Most folks I talk to are waiting to IETF to finish this thing, so they can go upgrade their code and move to the final version. Delaying it, making it experiental, informational, or any other variation will serve no other purpose than to convince everyone that this work is not done, and so folks should continue to wait. If you want an industry's worth of feedback and data, lets go and finish this thing. That means PS. All of that said, ICE has, probably more than most other specs that have ever come out of RAI, have had the benefit of: a. extensive technical review, comments and feedbacks, including commentary from implementors (including one in my own company, and several others from outside of it) and deployers (Tim Moore from Microsoft) b. design based on years of experience with NATs and NAT traversal c. design based on real collected data on NAT behaviors and on techniques used in other applications d. consideration on incremental deployability and applicability across the entire range of SIP, from p2p to enterprise to large provider to closed application provider and so on e. multiple open source implementations (two have been pointed out already) f. an active design team including security experts that helped in the massive redesign in -10 to simplify things And as such, it would seem to me that, not only is there not a single shred of evidence that suggests this draft deserves anything less than PS, there is evidence only to demonstrate that it has quality far greater than most IETF protocols with that moniker. Other parts of this thread have been folks suggesting alternative techniques that are simpler or work better. Well, I look forward to their drafts. So far, no one has suggested a single thing which was not considered and/or incorporated into ICE in some way over the last four years. ICE was built for reliability - to cover lots of cases and achieve not just 90% effectiveness (not nearly good enough), but as effective as is possible within the limitations of hurting the Internet or violating security policies and other things we won't touch. Without a doubt you can design a custom protocol for any one single deployment scenario with some set of assumptions that works simpler with fewer messages. However, our objective was to design a NAT traversal solution for SIP that applied as broadly as SIP did. ICE has the benefit of resulting in simple flows in simple topologies, but the same logic produces more complex flows in more complex situations, but still works. That was a design decision we made years ago and it remains a sound one. Comments have also been made that, "well, you thought STUN would work and you were wrong". This too is bogus. The limitations of STUN were known at the time of its publication. It was our hope that enough of a market would find it acceptable to be useful. Quoting from RFC 3489: > STUN introduces brittleness into the system in several ways: > > o The discovery process assumes a certain classification of devices > based on their treatment of UDP. There could be other types of > NATs that are deployed that would not fit into one of these molds. > Therefore, future NATs may not be properly detected by STUN. STUN > clients (but not servers) would need to change to accommodate > that. > > o The binding acquisition usage of STUN does not work for all NAT > types. It will work for any application for full cone NATs only. > For restricted cone and port restricted cone NAT, it will work for > some applications depending on the application. Application > specific processing will generally be needed. For symmetric NATs, > the binding acquisition will not yield a usable address. The > tight dependency on the specific type of NAT makes the protocol > brittle. > > o STUN assumes that the server exists on the public Internet. If > the server is located in another private address realm, the user > may or may not be able to use its discovered address to > communicate with other users. There is no way to detect such a > condition. > > o The bindings allocated from the NAT need to be continuously > refreshed. Since the timeouts for these bindings is very > implementation specific, the refresh interval cannot easily be > determined. When the binding is not being actively used to > receive traffic, but to wait for an incoming message, the binding > refresh will needlessly consume network bandwidth. > > o The use of the STUN server as an additional network element > introduces another point of potential security attack. These > attacks are largely prevented by the security measures provided by > STUN, but not entirely. > > > > > > > > Rosenberg, et al. Standards Track [Page 40] > > RFC 3489 STUN March 2003 > > > o The use of the STUN server as an additional network element > introduces another point of failure. If the client cannot locate > a STUN server, or if the server should be unavailable due to > failure, the application cannot function. > > o The use of STUN to discover address bindings will result in an > increase in latency for applications. For example, a Voice over > IP application will see an increase of call setup delays equal to > at least one RTT to the STUN server. > > o The discovery of binding lifetimes is prone to error. It assumes > that the same lifetime will exist for all bindings. This may not > be true if the NAT uses dynamic binding lifetimes to handle > overload, or if the NAT itself reboots during the discovery > process. > > o STUN imposes some restrictions on the network topologies for > proper operation. If client A obtains an address from STUN server > X, and sends it to client B, B may not be able to send to A using > that IP address. The address will not work if any of the > following is true: > > - The STUN server is not in an address realm that is a common > ancestor (topologically) of both clients A and B. For example, > consider client A and B, both of which have residential NAT > devices. Both devices connect them to their cable operators, > but both clients have different providers. Each provider has a > NAT in front of their entire network, connecting it to the > public Internet. If the STUN server used by A is in A's cable > operator's network, an address obtained by it will not be > usable by B. The STUN server must be in the network which is a > common ancestor to both - in this case, the public Internet. > > - The STUN server is in an address realm that is a common > ancestor to both clients, but both clients are behind the same > NAT connecting to that address realm. For example, if the two > clients in the previous example had the same cable operator, > that cable operator had a single NAT connecting their network > to the public Internet, and the STUN server was on the public > Internet, the address obtained by A would not be usable by B. > That is because some NATs will not accept an internal packet > sent to a public IP address which is mapped back to an internal > address. To deal with this, additional protocol mechanisms or > configuration parameters need to be introduced which detect > this case. > > > > > > > Rosenberg, et al. Standards Track [Page 41] > > RFC 3489 STUN March 2003 > > > o Most significantly, STUN introduces potential security threats > which cannot be eliminated. This specification describes > heuristics that can be used to mitigate the problem, but it is > provably unsolvable given what STUN is trying to accomplish. > These security problems are described fully in Section 12. Well, the market didn't find it useful enough. And so we worked to improve. Nearly every one of these limitations has been eliminated by ICE. Go read the IAB considerations section, which discusses this. Binding lifetime discovery is pretty much the only remaining one; fortunately that is a minor one and ICE is just aggressive in that area to compensate. The STUN-control work Dan has been promoting is meant to add ontop of ICE to finally close that issue. So, in case its not abundantly clear, I think there is no merit to the calls for changing ICE to informational or experimental, and that these last minute claims of better solutions or simpler solutions are also without merit. ICE is as deserving, and indeed more so, of a PS moniker than most other documents that achieve that label. -Jonathan R. David Barrett wrote: > Hi Cullen, I think you bring up lot of really great and detailed questions. > > However, speaking for myself at least, answering those questions doesn't > really address my concern. All I want to know is: > > Does ICE work, and how well? > > What "works" means is entirely open to debate. I've tossed out "high peer > connectivity" and "low connection setup time" as the most important > criteria, and I've put hard data behind those numbers as a stake in the > ground for comparison, but I'm open to other metrics as well. > > But regardless of the metrics, I want somebody who uses it and loves it and > bases their business upon its success to stand up and explain why it's > great. And I want this person to provide real-world data, sampled on a wide > scale, proving that ICE "works" -- by any definition. > > Basically, I want ICE firmly grounded in wide-scale testing and real-world > data, and answering the questions below doesn't bring us any closer to that. > Whether it's level 10 or level 12 doesn't produce new data. How its > algorithms differ from competing ones doesn't show that they're any better > or worse. Detailed proposals for change don't shed any light on whether > those changes improve or worsen it, because its current state is completely > unmeasured. > > The most powerful thing the IETF can do to standardize the world upon ICE is > prove that it works better than any alternative. Because until that's > proven, we just need to take it as a matter of faith. > > -david > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 18, 2007 7:56 PM >> To: SIP; Behave WG; mmusic@ietf.org >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> First I apologize for the cross post - this is a mmusic draft, I >> would appreciate replies on the mmusic list only. >> >> Few things I am looking for here .... >> >> 1) specific reasons why this work is less appropriate for standards >> track than other work that IETF puts on the standards track. Keep in >> mind the first step of standards track is Proposed Standards which >> requires basically no interoperability, then it could move to Draft >> Standard where interoperability is shown and finally Full Standard if >> it turns out to be a good idea. If you are going to post a reply to >> this point, make sure you have read RFC 2026. >> >> 2) I am interested in the specifics of problems that ICE fails to >> solve that the WG has not previous considered. There are lots of >> people that have implemented versions of it and think it is a good >> idea - if people are having some problems with it, I'd love to hear >> about details of things that are wrong. That it has a lot of messages >> in some use cases has been known for a long time. It used to have far >> more messages - engineering was done to consider what was a >> reasonable amount for call set up times and a new design was done to >> bring the message to a level most people invovled with the design >> felt was reasonable. If there are specific other than these that are >> wrong and not considered in the design, now would be a good time to >> get them on the table. >> >> 3) If people think that Skype for example has a simpler solution that >> works better than ICE. Feel free to describe exactly what it is. >> Several people invovled with the ICE design have looked in extreme >> detail at Skype and others and so far none of them have come back >> with what we should do different than ICE. >> >> 4) ICE can be used in a mode where it only provided the reflexive >> candidate. People were pretty clear that this was far inferior to the >> modes where there are other candidates. If someone would like to >> provide exactly how hole punching works better than this very limited >> ICE technique, I'd be glad to hear the details. This has certainly >> been an topic that any could have brought up over the last several >> years. If someone has specifics, I suggest they get out a full >> proposal really soon. I am very doubtful that hole punching solution >> is fundamentally different than the type of hole punching ICE does. >> >> 5) Some people have suggested that if all NATs were behave complaint, >> then we would not need ICE. I strongly disagree. I think the only >> part of ICE we would not need is the TURN relays which are more or >> less an optional part. Again, specifics on what can be removed are >> welcome. >> >> ICE is far more complicated that anyone wants - the problem is, no >> one has come up with a proposal that looks like it comes anywhere >> close to meeting the requirements and if simpler. The design space >> has been extensively explored by many people. The raw data to >> understand what will work on what NATs have been painfully tested and >> documented in publications such as: >> >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf >> >> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt >> >> https://www.guha.cc/saikat/stunt-results.php? >> >> (Ford used to have a page too but it seems to be gone) >> >> I have a very open mind to considering better ways to do ICE - but I >> need specific suggestions or it is impossible for me to really think >> about if the suggestions represent a better path or not. >> >> I would love to see more open source ICE code (there is lots already) >> - I feel that this is an area where ICE is likely just table stakes >> and owning an proprietary ICE stack will not turn out to be a >> competitive advantage. Having open source implementations where the >> development cost was shared and everyone could get working products >> to market faster would be an advantage to companies. Clearly I expect >> the bulk of ICE implementations to not be open source but I still >> would be keen on doing what I can to contribute to an open source >> version as personally I feel that is in the interest of end users, my >> employer, and the IETF as a SDO. >> >> Cullen >> >> >> >> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: >> >>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: >>> >>>> Henry Sinnreich skrev: >>>>> Following some discussions and soul searching, the best approach for >>>>> ICE-17 for LC would be to _go ahead and make it an experimental >>>>> RFC_. >>>>> This would support the development of interoperable >>>>> implementations, the >>>>> collection of deployment data and also hopefully open source code. >>>>> Though I have full faith in ICE, following the practices that >>>>> made the >>>>> IETF successful take precedent here, I believe. >>>>> This is a change from the attached that I wrote on 7/16/2007. >>>>> Note: We can only hope the proliferation of SBC in VoIP service >>>>> provider >>>>> networks will not make these concerns and ICE for SIP a moot >>>>> issue, but >>>>> this is another topic. >>>> Henry, >>>> >>>> I don't quite understand why you are requesting a status change of >>>> ICE? To me it appears that ICE is almost finished spec. It has >>>> been implemented, used and feedback has been influencing the >>>> protocol. It is definitly one of the better examples of current >>>> IETF work that actually has running code. Sure, the >>>> implementations may not be fully updated yet to the latest draft >>>> version. But I think it is safe to say that ICE works in the >>>> intended core cases. If there are some corner cases where it >>>> fails, that may be. But that is not information we will have until >>>> really large scale deployement or someone makes very extensive tests. >>> Henry has, I believe, been very consistent in urging the IETF to >>> have more "running code" experience on every specification (not >>> just ICE) than our process requires. He has, IIRC, also advocated >>> changing the process to require running code before publishing an >>> RFC. He's even suggested at times that one should have running code >>> before submitting a protocol draft. >>> >>> Another point to consider -- I've known Henry to bark at a tree >>> with no squirrel in it occasionally, but most of the time he's >>> pretty reliable, more so than most technology predictors. If he's >>> worried about ICE, it's probably because he's been talking to >>> people who are trying to implement it and they're telling him it is >>> difficult or that they're having performance or reliability issues. >>> I imagine that there are plenty of internal development teams in >>> various companies that are working on this and not necessarily >>> bringing their results back to the IETF. After all, if everybody >>> sees the emperor as fully clothed, they'd be embarrassed to >>> proclaim otherwise. Of course, I wish all of these developers were >>> tied into the IETF, but then I'm sure I don't want to see every ice- >>> implementor's question on the SIP list. That is why we have a sip- >>> implementors mailing list, right? >>> >>> Personally, I think ICE is the best solution we have. We KNOW of >>> cases where hole-punching doesn't work, and I think ICE will >>> produce usable results in most of those cases. But that's just my >>> personal opinion from reading the specs. I haven't implemented ICE, >>> and I haven't used anybody else's implementation. Sure, it's >>> complex, but that's because the underlying problem is complex -- >>> there are just too many different behaviors out there in "NAT and >>> firewall land". Of course, I could be wrong, too. It's happened >>> before, once or twice ;-). Just how sure are we that we're right >>> about this? >>> >>> Are we designing a "spruce goose" or a practical system? Only >>> experience will tell us. But some good flight reports from the >>> prototypes could go a long way towards reassuring us of the >>> design's utility. >>> >>> So far we've had a couple of people report hearsay evidence -- that >>> somebody else has an ICE implementation and it works. Any of you >>> folks have personal experience you can share? Have there been >>> prototypes exercised at the interop events? >>> >>> -- >>> Dean >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 10:02: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 1IBWaA-0006Cp-Hm; Thu, 19 Jul 2007 10:02:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBWa8-0006Ck-LJ for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 10:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWa8-0006Cc-Bq for behave@ietf.org; Thu, 19 Jul 2007 10:02:16 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBWa6-0007XE-Ra for behave@ietf.org; Thu, 19 Jul 2007 10:02:16 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBWa7-0007CZ-0i; Thu, 19 Jul 2007 10:02:15 -0400 In-Reply-To: <200707181039.45588.remi.denis-courmont@nokia.com> References: <03bd01c7c896$a739c860$7d646b80@amer.cisco.com> <469D2B03.3040002@comunip.com.br> <200707181039.45588.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7A63210A-60EC-4198-BD90-87CA3C65C2D7@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] ICE performance Date: Thu, 19 Jul 2007 10:02:27 -0400 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: behave@ietf.org, baford@mit.edu, dank@kegel.com, 'Henry Sinnreich' , Dan Wing , henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 18-Jul-07, at 03:39 , R=E9mi Denis-Courmont wrote: > >> BTW, *the normal use of RFC 3489 detects this type of NAT as Port >> Restricted*! > > If you used ICE, you would not care. However, if you used ICE, it =20 > might or > might not work depending on the timing of each side's connectivity =20 > checks. > The problem here is, when sending connectivity checks, you punch a =20 > hole in > your NAT, but you may confuse the other side's NAT (particularly if =20= > it is an > ICMP-sending NAT). Can you describe, perhaps by providing a message sequence diagram, =20 how ICE might fail in this case? I don't understand the problem you are =20 referring to. - Philip= _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 10:16: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 1IBWoK-0001oC-Jx; Thu, 19 Jul 2007 10:16:56 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBWoH-0001o6-GD for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 10:16:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWoH-0001nx-6W for behave@ietf.org; Thu, 19 Jul 2007 10:16:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBWoG-0007up-Me for behave@ietf.org; Thu, 19 Jul 2007 10:16:53 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2007 07:16:52 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAP4On0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="167343752:sNHT58359591" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6JEGqEv021711; Thu, 19 Jul 2007 07:16:52 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6JEGhA0009386; Thu, 19 Jul 2007 14:16:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 07:16:42 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 07:16:42 -0700 Message-ID: <469F724F.9050201@cisco.com> Date: Thu, 19 Jul 2007 10:16:47 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] ICE performance References: <03bd01c7c896$a739c860$7d646b80@amer.cisco.com> <469D2B03.3040002@comunip.com.br> <200707181039.45588.remi.denis-courmont@nokia.com> <7A63210A-60EC-4198-BD90-87CA3C65C2D7@magma.ca> In-Reply-To: <7A63210A-60EC-4198-BD90-87CA3C65C2D7@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Jul 2007 14:16:42.0579 (UTC) FILETIME=[6E375A30:01C7CA0F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2032; t=1184854612; x=1185718612; c=relaxed/simple; s=sjdkim4002; 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]=20ICE=20performance |Sender:=20; bh=T8gpyvNd9SgzyGhELfjTnKo8jwYE3zL9fNjrkexHvUA=; b=T0xj+1cC0Vs5A1uD8rzMg+USW8vPgdLZLEcCECrEcfkveHs0TK4OESMDF+m8cEknnK+mSnij UvR5ls2a7hEwyLNkAloRDei2GQXMiEKk9LQ3PS2Y+1W1oXu4ydTWpjdf; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: behave@ietf.org, 'Henry Sinnreich' , dank@kegel.com, baford@mit.edu, Dan Wing , henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I think this is referring to the behavior of some NATs, which return ICMP port unreachable errors when receiving a packet on the outside from an unknown source. In earlier versions of ICE the ICMP unreachable would instruct ICE to consider the check to have failed. That was actually fixed in a recent ICE revision, so that if you receive a connectivity check but a check in the previous direction had previously failed, you retry. This allows ICE to get a direct path in this case. I'll note that, I'm sure we'll find other random NAT behaviors over time. THis is why ICE does a 'try lots of things' model, so that in the worst case it ends up with a relay but at least it works. THis way ICE correctness is not dependent on us guessing and handling all variations on NAT behavior. -Jonathan R. Philip Matthews wrote: > > On 18-Jul-07, at 03:39 , Rémi Denis-Courmont wrote: > >> >>> BTW, *the normal use of RFC 3489 detects this type of NAT as Port >>> Restricted*! >> >> If you used ICE, you would not care. However, if you used ICE, it >> might or >> might not work depending on the timing of each side's connectivity >> checks. >> The problem here is, when sending connectivity checks, you punch a >> hole in >> your NAT, but you may confuse the other side's NAT (particularly if it >> is an >> ICMP-sending NAT). > > Can you describe, perhaps by providing a message sequence diagram, how ICE > might fail in this case? I don't understand the problem you are > referring to. > > - Philip > > _______________________________________________ > 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 Thu Jul 19 11:19: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 1IBXmr-0001Js-Hc; Thu, 19 Jul 2007 11:19:29 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBXmo-0001C9-EE for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 11:19:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXmn-0001Bp-PI; Thu, 19 Jul 2007 11:19:25 -0400 Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBXmn-0003GY-FR; Thu, 19 Jul 2007 11:19:25 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id 14D4D1C8029; Thu, 19 Jul 2007 10:05:08 -0500 (CDT) From: "Frank W. Miller" To: "'Jonathan Rosenberg'" , "'David Barrett'" Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 09:19:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <469F6E43.5050709@cisco.com> Thread-index: AcfKDQH7ZSN1xI7SS1Wni46u9zV1DQACXjyw Message-Id: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] a. extensive technical review, comments and feedbacks, including commentary from implementors (including one in my own company, and several others from outside of it) and deployers (Tim Moore from Microsoft) FM: While I applaud the time and effort that the large vendors have obviously invested in this, this is a qualitative statement. Perhaps Cisco and/or Microsoft have empirical data they would be willing to share about robustness and performance? I don't think anyone here, including myself, is saying that ICE should not go forward or be used (its ability to handle hairpinning is of great interest for example), we are asking for evidence that we're not going to have another 3489 experience if we can avoid it. e. multiple open source implementations (two have been pointed out already) FM: I think I missed those, can they be repeated? The only one I'm aware of is pjnath and its first release was a little over two months ago and its based on -15. Thanks, FM _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 11:35: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 1IBY2L-0004XA-TD; Thu, 19 Jul 2007 11:35:29 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBY2J-0004WM-Vh for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 11:35:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY2J-0004W0-BF; Thu, 19 Jul 2007 11:35:27 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBY2I-0003tj-Pv; Thu, 19 Jul 2007 11:35:27 -0400 Received: from source ([192.150.11.134]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Jul 2007 08:35:14 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JFXqot020951; Thu, 19 Jul 2007 08:33:53 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6JFZ70c021529; Thu, 19 Jul 2007 08:35:07 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:35:07 -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: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Date: Thu, 19 Jul 2007 08:30:18 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Thread-Index: AcfJothpej38ca2VQqWJmM78llWMcwAdAQ6Q References: <239224.19734.qm@web33301.mail.mud.yahoo.com><3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca><24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> From: "Henry Sinnreich" To: "Philip Matthews" X-OriginalArrivalTime: 19 Jul 2007 15:35:07.0342 (UTC) FILETIME=[627936E0:01C7CA1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: behave@ietf.org, mmusic@ietf.org, sip@ietf.org, p2psip@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 Phil, You are right again, but as mentioned, concept papers (a true torrent over many years lately) and discussion lists cannot replace published measurement tools, measured results and tweaking the approach based on measurements; measuring the improvements, etc.=20 This is the reason why I am not going into debating points about the merits of ICE, but rather the best approach to make it successful and be able to prove it. ICE is not a protocol agreement like SIP, but a technology that faces the great physical complexity on the net, so the protocol discussion approach is no replacement for testing and tweaking. This probably explains why we are in this discussion about ICE in the first place. By the same token I-D process arguments and consensus are no replacement either for proof on the net.=20 Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, July 18, 2007 8:19 PM To: Henry Sinnreich Cc: Magnus Westerlund; behave@ietf.org; mmusic@ietf.org; sip@ietf.org; Pyda Srisuresh; Frank W. Miller; p2psip@ietf.org Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > Phil, > >> In my view, ICE _is_ a "Hole Punching Technique". > > Yes, you absolutely right, though the devil is in the details. > > We cannot go here into a shoot-out between hole punching or other > mentioned on the list vs. ICE, but there seems to be a huge difference > in effectiveness and performance. What precise algorithm are you talking about when you say this? As far as I am concerned, ICE is simply a well-documented hole =20 punching algorithm. It differs from others that I have seen written up in the following =20 ways: - ICE has the concept of peer reflexive addresses, which other hole-=20 punching techniques that I have seen do not; - ICE has the concept of controlling/controlled endpoint, which gives =20 the controller additional flexibility in choosing a path; - ICE does NOT have the concept of port prediction, which some other =20 techniques do (e.g., Saikat's TCP work). Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 11:38:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY5M-0006zN-MK; Thu, 19 Jul 2007 11:38:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBY5K-0006z1-QY for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 11:38:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY5K-0006ye-6x; Thu, 19 Jul 2007 11:38:34 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBY5J-0001sh-IN; Thu, 19 Jul 2007 11:38:34 -0400 Received: from orthrus.local ([172.17.1.56]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l6JFcQ6C064180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 10:38:26 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <469F8577.4080506@estacado.net> Date: Thu, 19 Jul 2007 10:38:31 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "Frank W. Miller" Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> In-Reply-To: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'SIP' , 'Behave WG' , mmusic@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 7/19/07 10:19 AM, Frank W. Miller wrote: > FM: While I applaud the time and effort that the large vendors have > obviously invested in this, this is a qualitative statement. Perhaps Cisco > and/or Microsoft have empirical data they would be willing to share about > robustness and performance? That's the kind of data you get between "proposed standard" and "draft standard" -- not *prior* to publication. I'm not sure why there's so much noise about setting the bar much, much higher for ICE than we do for other IETF proposals. To be clear: to get this kind of experience (especially as it pertains to interoperability), you need to have a stable (i.e., frozen) specification. Internet Drafts simply don't provide an appropriate basis for the kinds of proof that you and others are demanding. I think we would all benefit from a quick review of RFC 2026: > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. ... > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. /a _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 12:59: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 1IBZL7-0006t2-R4; Thu, 19 Jul 2007 12:58:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBZL7-0006sK-7r for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 12:58:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZL6-0006qj-To for behave@ietf.org; Thu, 19 Jul 2007 12:58:56 -0400 Received: from hm398-1.locaweb.com.br ([200.234.205.169] helo=hm398.locaweb.com.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBZL4-0003tJ-Ok for behave@ietf.org; Thu, 19 Jul 2007 12:58:56 -0400 Received: (qmail 6034 invoked from network); 19 Jul 2007 16:58:50 -0000 Received: from unknown (10.1.10.10) by hm398.locaweb.com.br with QMQP; 19 Jul 2007 16:58:50 -0000 Received: from unknown (HELO ?192.168.0.216?) (guibv@comunip.com.br@201.78.67.56) by hm10.locaweb.com.br with SMTP; 19 Jul 2007 16:59:01 -0000 Message-ID: <469F9858.3060609@comunip.com.br> Date: Thu, 19 Jul 2007 13:59:04 -0300 From: Guilherme Balena Versiani Organization: ComunIP User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] ICE performance References: <03bd01c7c896$a739c860$7d646b80@amer.cisco.com> <469D2B03.3040002@comunip.com.br> <200707181039.45588.remi.denis-courmont@nokia.com> <7A63210A-60EC-4198-BD90-87CA3C65C2D7@magma.ca> <469F724F.9050201@cisco.com> In-Reply-To: <469F724F.9050201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: behave@ietf.org, 'Henry Sinnreich' , dank@kegel.com, baford@mit.edu, Dan Wing , henrys@adobe.com, 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 Comments in-line. Jonathan Rosenberg wrote: > (...) In earlier versions of ICE the ICMP unreachable would instruct > ICE to consider the check to have failed. That was actually fixed in a > recent ICE revision, so that if you receive a connectivity check but a > check in the previous direction had previously failed, you retry. This > allows ICE to get a direct path in this case. I personally decided not to consider ICMP port unreachable as an error, as some "Port Restricted" NATs could respond ICMP error until a packet is directed to the peer. The "NAT ICMP issue", when it occurs, it persists very likely during the process of a ICE agent. Phillip Mathews wrote: > Can you describe, perhaps by providing a message sequence diagram, how > ICE > might fail in this case? I don't understand the problem you are > referring to. Describing Linux BUG ('X:x' is an IP address / port): A STUN Server NAT B | | |<---------------| | |<-----src:X:x------| | | | | | | | | | |-----dst:X:x-------------------------->| | |<--ICMP port unreach-------------------| | | | | | | | |<---------------| |<----src:X:y---------------------------| | | | | | | | | | At a first glance, this behavior would not impact the ICE communication between a host without NAT (open) versus another host behind this type of NAT (this scenario will issue a peer derived candidate). But if the host 'A' is behind a "Port Restricted NAT", the connection has high probability to not establish on peer-to-peer basis: the host 'B' needs to pass a packet through NAT before a packet from host 'A' comes in (this way, the NAT works as a normal "Port Restricted NAT"). The Binding Discovery process is described before can detect this type of NAT as Symmetric, and not Port Restricted (as described in RFC 3489 and draft-ietf-behave-nat-behavior-discovery). Regards, Guilherme Balena Versiani. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 13:23: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 1IBZj0-0001Z8-Qr; Thu, 19 Jul 2007 13:23:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBZiz-0001Z0-LZ for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZiz-0001Yr-Bj for behave@ietf.org; Thu, 19 Jul 2007 13:23:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBZiy-0004Ud-Qn for behave@ietf.org; Thu, 19 Jul 2007 13:23:37 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Jul 2007 10:23:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJc6n0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="185050230:sNHT28464291" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6JHNah7027655; Thu, 19 Jul 2007 10:23:36 -0700 Received: from dwingwxp ([128.107.115.252]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6JHNVSb005792; Thu, 19 Jul 2007 17:23:31 GMT From: "Dan Wing" To: "'Guilherme Balena Versiani'" , "'Jonathan Rosenberg'" Subject: RE: [BEHAVE] ICE performance Date: Thu, 19 Jul 2007 10:23:30 -0700 Message-ID: <0bca01c7ca29$89f1e5f0$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <469F9858.3060609@comunip.com.br> Thread-Index: AcfKJifhleOX8A6vQim2sPd2w7ERvgAASHcw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2581; t=1184865816; x=1185729816; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20ICE=20performance |Sender:=20; bh=z/KAaWuhh799ocLTL7UJoPZqRCneAmzOjoqbu86G9zg=; b=Tifi5G6NfUq2MYhhit3shVltfx6GzJ+ajSLOWKrrkX80Y3zgHFTel61Frk9NFV+iyErcoCC5 pcLn3sc0htFonQleHG5d50DUmfufWZR5AAgrnnIxumuugbFLAoHFZicM+GwU/M4xT6Pyu3dNiM 0d7IwPVSWysM6L9RzjA8XqZ/Q=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: behave@ietf.org, 'Henry Sinnreich' , dank@kegel.com, baford@mit.edu, henrys@adobe.com, '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 > Describing Linux BUG ('X:x' is an IP address / port): > > A STUN Server NAT B > | | |<---------------| > | |<-----src:X:x------| | > | | | | > | | | | > |-----dst:X:x-------------------------->| | > |<--ICMP port unreach-------------------| | > | | | | > | | |<---------------| > |<----src:X:y---------------------------| | > | | | | > | | | | > > At a first glance, this behavior would not impact the ICE > communication between a host without NAT (open) versus > another host behind this type of NAT (this scenario will > issue a peer derived candidate). But if the host 'A' is > behind a "Port Restricted NAT", the connection has high > probability to not establish on peer-to-peer basis: the host > 'B' needs to pass a packet through NAT before a packet from > host 'A' comes in (this way, the NAT works as a normal > "Port Restricted NAT"). Thanks for the write-up. B's NAT is behaving as a symmetric NAT because a host on the Internet (A) sent a UDP packet to that port on B's NAT. (Any well-timed UDP packet, sent maliciously or accidentally to that port on B's NAT would also cause B's NAT to become symmetric for that flow. Perhaps too obscure of an attack to worry about?) As you point out, ICE will not establish a peer-to-peer session in this case (the case where one peer is behind a symmetric NAT and the other peer is behind a port-restricted NAT). Instead, ICE will only be able to establish connectivity via a media relay. > The Binding > Discovery process is described before can detect this type of NAT as > Symmetric, and not Port Restricted (as described in RFC 3489 and > draft-ietf-behave-nat-behavior-discovery). Yesterday I forwarded your previous email to the authors of -ietf-behave-nat-behavior-discovery, and I think I CC'd you on that email. I expect they'll integrate that test into a subsequent revision of their document. (As has been pointed out, but I want to restate for others reading this thread: ICE does not perform any tests to determine what kind of NAT (symmetric, port-restricted, etc.) is in use.) -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 13:38:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZxj-0005rz-8o; Thu, 19 Jul 2007 13:38:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBZxd-0005ji-Gh for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:38:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZxb-0005jV-F5 for behave@ietf.org; Thu, 19 Jul 2007 13:38:45 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBZxa-0004u5-8X for behave@ietf.org; Thu, 19 Jul 2007 13:38:43 -0400 Received: (qmail 15794 invoked by uid 60001); 19 Jul 2007 17:38: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:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Q31OE9U5PaiNU50WPFXt08hk3aV7dVuJ7VwqOMSu3XEk1jW6xY93fkTEI3ojNazseXegCYe1YX8g4rFTn+MvJmk8QcbhOHMGj2qTdZVAS3uaQaazoAymuMNNDVWcmlivAmxvLTZPYa1fCieK2QwPXhQCc8yz27+yR/Jt6ponE64=; X-YMail-OSG: OoavG3AVM1l7DqQe672pWQ.yI1Y3WF0m1U8jwrcavRQ5lPFpOy6NB0UbhBB8IIEXizzQsg-- Received: from [209.172.74.45] by web33312.mail.mud.yahoo.com via HTTP; Thu, 19 Jul 2007 10:38:41 PDT Date: Thu, 19 Jul 2007 10:38:41 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: David Barrett , 'Melinda Shore' , 'Philip Matthews' MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <725173.15437.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@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 David, 90% success in connection rate is very impressive. Are you refering to UDP, TCP or both? As you say, fallback such as relay is essential for 100% connectivity. One cannot use hole punching without a good fallback scheme. regards, suresh --- David Barrett wrote: > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > > > ICE makes me want to pound red-hot nails into my eye sockets. That said, > > 90% really isn't nearly good enough for residential deployments. > > Incidentally, 90% is where my stats come out today -- this doesn't include > restricted-cone/symmetric and symmetric/symmetric penetration, which has > been prototyped but not added to the production system yet. The hope is > this will get us much close to the 99% range, but it remains to be seen by > how much. > > Furthermore, I'd wager that for most applications (such as VoIP), even > routing 1 in 10 calls through a central relay isn't going to break the bank. > (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) to > act as "free" relays for their peers.) > > Thus while NAT penetration using what I guess we're calling the "hole > punching technique" has been demonstrated to work at 90%+ on a very large > scale (hundreds of thousands of clients tested) we should expect that it's > possible to get even better still. If ICE can show how it'd do better, > that'd be great. But we can't tolerate ICE being any worse than that, and > thus before rushing ahead with standardizing an unproven ICE, we should just > take the time to prove it. > > -david > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 13:45: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 1IBa3v-0004eY-5z; Thu, 19 Jul 2007 13:45:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBa3s-0004d6-Cp for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:45:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBa3r-0004cs-UJ for behave@ietf.org; Thu, 19 Jul 2007 13:45:12 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBa3r-0007lw-BO for behave@ietf.org; Thu, 19 Jul 2007 13:45:11 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 10:45:01 -0700 From: "David Barrett" To: "'Philip Matthews'" , "'Frank W. Miller'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 10:44:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfJ/AEOlBMUriURROWxMoN7RNp/BQALk3Uw X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Message-Id: Cc: 'Behave WG' , 'IETF MMUSIC WG' , sip@ietf.org, 'Henry Sinnreich' , 'P2PSIP Mailing List' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > David Barrett's algorithm, if I understand it correctly, would work in > this situation. (As far as I can tell, David's is a simplified version > of ICE). That's correct. The major differences (so far as I know) between what I'm doing and what ICE does include: - Peer's needn't exchange SDP before attempting connection establishment (rather, the rendezvous server just tells both sides the others' LAN/NAT addresses and they try to connect immediately). - Paths are evaluated in parallel rather than sequentially (ie, I attempt to contact you direct via the LAN and indirectly via your NAT at the same time, and then pick the faster of the two) - There's no support for TURN servers as my application doesn't require them (though it would be extremely straightforward to add). - Clients attempt NAT classification as a *purely advisory* function to support debugging and feed into certain non-critical pairwise optimizations. (Said another way, even if the classification is totally wrong, it'll still work.) - Clients use adaptive keepalives to a STUN server to keep their NAT/FW "hole" open. By "adaptive" I mean I use probing to determine highest safe keepalive frequency of the NAT/FW. (Incidentally, there's no requirement that any two clients use the same STUN server, and indeed I intend to move to enable a "distributed STUN service" using the peers themselves.) Basically, I do the minimum necessary for my requirements, which I respect are much easier than SIP's. However, know that despite my system being much easier, it has been *extremely difficult and time consuming* to get working, despite dozens of iterations drawing upon a network of hundreds of thousands of machines on which to test. Thus I would suggest that if my solution took as long as it did, and went through as many variations as it did, the SIP/ICE implementers should be very wary of hardening anything too early before it hits the real world. Because the real world is really, really strange and unpredictable, I can guarantee you that. Phillip's asked me to put together a bit more precise overview of the system I use and I'll try to get to that soon. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 13:51: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 1IBaA8-0007Qq-CC; Thu, 19 Jul 2007 13:51:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBaA5-0007Q2-At for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:51:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaA4-0007Pf-NO; Thu, 19 Jul 2007 13:51:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBaA2-0005Qs-TN; Thu, 19 Jul 2007 13:51:36 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBaA3-0000Eq-0i; Thu, 19 Jul 2007 13:51:35 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com><3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca><24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9280291A-AB5A-4AC8-BD63-75AE5339B33D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Date: Thu, 19 Jul 2007 13:51:47 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: behave@ietf.org, mmusic@ietf.org, sip@ietf.org, p2psip@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I agree that it would be very nice to see more published data on when ICE succeeds (and specifically when it succeeds in finding a direct path). It would also be nice to see more open source implementations. It used to be that the Routing area would hold a draft in the "almost done" state until they had some implementation experience, and then publish as an RFC only once they had that data. Is this what you are looking for? - Philip On 19-Jul-07, at 11:30 , Henry Sinnreich wrote: > Phil, > > You are right again, but as mentioned, concept papers (a true torrent > over many years lately) and discussion lists cannot replace published > measurement tools, measured results and tweaking the approach based on > measurements; measuring the improvements, etc. > > This is the reason why I am not going into debating points about the > merits of ICE, but rather the best approach to make it successful > and be > able to prove it. > > ICE is not a protocol agreement like SIP, but a technology that faces > the great physical complexity on the net, so the protocol discussion > approach is no replacement for testing and tweaking. This probably > explains why we are in this discussion about ICE in the first place. > > By the same token I-D process arguments and consensus are no > replacement > either for proof on the net. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, July 18, 2007 8:19 PM > To: Henry Sinnreich > Cc: Magnus Westerlund; behave@ietf.org; mmusic@ietf.org; sip@ietf.org; > Pyda Srisuresh; Frank W. Miller; p2psip@ietf.org > Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data > before > LCfor RFC > > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > >> Phil, >> >>> In my view, ICE _is_ a "Hole Punching Technique". >> >> Yes, you absolutely right, though the devil is in the details. >> >> We cannot go here into a shoot-out between hole punching or other >> mentioned on the list vs. ICE, but there seems to be a huge >> difference >> in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; > - ICE has the concept of controlling/controlled endpoint, which gives > the controller additional flexibility in choosing a path; > - ICE does NOT have the concept of port prediction, which some other > techniques do (e.g., Saikat's TCP work). > > Philip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 13:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaFr-0008NC-B4; Thu, 19 Jul 2007 13:57:35 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBaFp-0008Mr-RL for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:57:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaFp-0008Ma-Gr for behave@ietf.org; Thu, 19 Jul 2007 13:57:33 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaFo-0008Dq-TT for behave@ietf.org; Thu, 19 Jul 2007 13:57:33 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 10:57:30 -0700 From: "David Barrett" To: "'Jonathan Rosenberg'" Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 10:57:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <469F6E43.5050709@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKDQrsCgBg9rNPRKqODM/+VLHMWwAH6iJg X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Message-Id: Cc: 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > ICE was built for reliability - to cover lots of cases and achieve not > just 90% effectiveness (not nearly good enough), but as effective as is > possible within the limitations of hurting the Internet or violating > security policies and other things we won't touch. Just to clarify, the 90% number (which I'm guessing comes from my published stats) is the success rate of any two peers being able to establish a direct connection without a relay service. If I were to add a relay service (which I don't need for my application, but would be trivial) for the remaining 10% I hope you agree that near 100% of peers would be able to talk. (I say "near" because nothing works at 100% in the real world, no matter how simple it appears on paper.) > a. extensive technical review, comments and feedbacks, including > commentary from implementors (including one in my own company, and > several others from outside of it) and deployers (Tim Moore from > Microsoft) Excellent! Do you or any of your implementor colleagues have any data showing how well the result works? Or if not, do you have an active system that you can instrument to get it? Or a test implementation that can be instrumented in the lab? Or any data at all showing how well ICE works? I understand we have data about the general NAT penetration techniques, years of experience, and active security teams. Does anybody have actual users, using this on a daily basis on a broad scale, proving that the product of all this hard work accomplishes its goals? -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 14:02: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 1IBaK5-0001Dj-LR; Thu, 19 Jul 2007 14:01:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBaK4-0001DT-AW for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:01:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaK4-0001DC-0r for behave@ietf.org; Thu, 19 Jul 2007 14:01:56 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBaK3-0005pU-Gv for behave@ietf.org; Thu, 19 Jul 2007 14:01:56 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:01:52 -0700 From: "David Barrett" To: "'Pyda Srisuresh'" , "'Melinda Shore'" , "'Philip Matthews'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 11:01:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <725173.15437.qm@web33312.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKLJfy3vmiOiN8RFO5qEAMFGqczAAAiOtQ X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Message-Id: Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@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 Just UDP so far, though I harbor ambitions of adding TCP to the mix so it'll try a bit of everything. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Thursday, July 19, 2007 10:39 AM > To: David Barrett; 'Melinda Shore'; 'Philip Matthews' > Cc: sip@ietf.org; 'Henry Sinnreich'; behave@ietf.org; mmusic@ietf.org > Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > David, > > 90% success in connection rate is very impressive. Are you refering to > UDP, TCP > or both? As you say, fallback such as relay is essential for 100% > connectivity. > One cannot use hole punching without a good fallback scheme. > > regards, > suresh > > --- David Barrett wrote: > > > > -----Original Message----- > > > From: Melinda Shore [mailto:mshore@cisco.com] > > > > > > ICE makes me want to pound red-hot nails into my eye sockets. That > said, > > > 90% really isn't nearly good enough for residential deployments. > > > > Incidentally, 90% is where my stats come out today -- this doesn't > include > > restricted-cone/symmetric and symmetric/symmetric penetration, which has > > been prototyped but not added to the production system yet. The hope is > > this will get us much close to the 99% range, but it remains to be seen > by > > how much. > > > > Furthermore, I'd wager that for most applications (such as VoIP), even > > routing 1 in 10 calls through a central relay isn't going to break the > bank. > > (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) > to > > act as "free" relays for their peers.) > > > > Thus while NAT penetration using what I guess we're calling the "hole > > punching technique" has been demonstrated to work at 90%+ on a very > large > > scale (hundreds of thousands of clients tested) we should expect that > it's > > possible to get even better still. If ICE can show how it'd do better, > > that'd be great. But we can't tolerate ICE being any worse than that, > and > > thus before rushing ahead with standardizing an unproven ICE, we should > just > > take the time to prove it. > > > > -david > > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 14:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaKR-00025h-GU; Thu, 19 Jul 2007 14:02:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBaKI-0001iq-Jj for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:02:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaKH-0001gf-Pm for behave@ietf.org; Thu, 19 Jul 2007 14:02:09 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaKF-0008Q6-DV for behave@ietf.org; Thu, 19 Jul 2007 14:02:09 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:01:53 -0700 From: "David Barrett" To: "'David R Oran'" Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 11:01:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4BD296F0-6FC7-4BDE-A783-A835F081FBE7@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKEH90TIWL7i1uTU+0yFCSG5eilwAHdIkw X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Message-Id: Cc: 'SIP' , 'Behave WG' , mmusic@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 Actually, I'm not trying to reopen the requirements debate. I just want = ICE measured against the requirements that were agreed upon. And I completely agree that perfect is the enemy of the good. The only = ally of the good is reality, and I want to enlist her on our side. -david > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Thursday, July 19, 2007 7:23 AM > To: David Barrett > Cc: 'Cullen Jennings'; 'SIP'; 'Behave WG'; mmusic@ietf.org > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for = RFC >=20 >=20 > On Jul 19, 2007, at 6:15 AM, David Barrett wrote: >=20 > > Hi Cullen, I think you bring up lot of really great and detailed > > questions. > > > > However, speaking for myself at least, answering those questions > > doesn't > > really address my concern. All I want to know is: > > > > Does ICE work, and how well? > > > > What "works" means is entirely open to debate. > It may have been in the past, but the debate I think is closed, > because the requirements captured the definition of "works". If you > want to re-open the requirements discussion, please be clear about = that. >=20 > > I've tossed out "high peer > > connectivity" and "low connection setup time" as the most important > > criteria, and I've put hard data behind those numbers as a stake in > > the > > ground for comparison, but I'm open to other metrics as well. > > > See the requirements. One not often mentioned but clearly a > requirement that ICE works very hard to meet is "use the most direct > path available". >=20 > > But regardless of the metrics, I want somebody who uses it and > > loves it and > > bases their business upon its success to stand up and explain why = it's > > great. > > And I want this person to provide real-world data, sampled on a wide > > scale, proving that ICE "works" -- by any definition. > > > This is in fact an extremely important exercise, and precisely the > activity which according to RFC2026 is what should be happening after > approval as proposed standard, and before advancement to draft > standard. >=20 > > Basically, I want ICE firmly grounded in wide-scale testing and > > real-world > > data, and answering the questions below doesn't bring us any closer > > to that. > > Whether it's level 10 or level 12 doesn't produce new data. How its > > algorithms differ from competing ones doesn't show that they're any > > better > > or worse. Detailed proposals for change don't shed any light on > > whether > > those changes improve or worsen it, because its current state is > > completely > > unmeasured. > > > Showing how the algorithms work better, or work in more cases that > are covered by the requirements does in fact show that it's better, > with respect to the requirements. Again, you're arguing indirectly > that we should re-open the requirements discussion, which I do not > think would be terribly productive, but would support if there is in > fact consensus to do so. >=20 > > The most powerful thing the IETF can do to standardize the world > > upon ICE is > > prove that it works better than any alternative. Because until = that's > > proven, we just need to take it as a matter of faith. > > > I do not think that is desirable. The perfect is the enemy of the > good. ICE does not have to be better than anything else. It just has > to be "good enough" and see wide adoption. >=20 > That's my 2=A2 (as an individual, not as an IAB member, in case = anybody > cares). >=20 > DaveO > > -david > > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Wednesday, July 18, 2007 7:56 PM > >> To: SIP; Behave WG; mmusic@ietf.org > >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC > >> for RFC > >> > >> > >> First I apologize for the cross post - this is a mmusic draft, I > >> would appreciate replies on the mmusic list only. > >> > >> Few things I am looking for here .... > >> > >> 1) specific reasons why this work is less appropriate for standards > >> track than other work that IETF puts on the standards track. Keep = in > >> mind the first step of standards track is Proposed Standards which > >> requires basically no interoperability, then it could move to Draft > >> Standard where interoperability is shown and finally Full Standard = if > >> it turns out to be a good idea. If you are going to post a reply = to > >> this point, make sure you have read RFC 2026. > >> > >> 2) I am interested in the specifics of problems that ICE fails to > >> solve that the WG has not previous considered. There are lots of > >> people that have implemented versions of it and think it is a good > >> idea - if people are having some problems with it, I'd love to hear > >> about details of things that are wrong. That it has a lot of = messages > >> in some use cases has been known for a long time. It used to have = far > >> more messages - engineering was done to consider what was a > >> reasonable amount for call set up times and a new design was done = to > >> bring the message to a level most people invovled with the design > >> felt was reasonable. If there are specific other than these that = are > >> wrong and not considered in the design, now would be a good time to > >> get them on the table. > >> > >> 3) If people think that Skype for example has a simpler solution = that > >> works better than ICE. Feel free to describe exactly what it is. > >> Several people invovled with the ICE design have looked in extreme > >> detail at Skype and others and so far none of them have come back > >> with what we should do different than ICE. > >> > >> 4) ICE can be used in a mode where it only provided the reflexive > >> candidate. People were pretty clear that this was far inferior to = the > >> modes where there are other candidates. If someone would like to > >> provide exactly how hole punching works better than this very = limited > >> ICE technique, I'd be glad to hear the details. This has certainly > >> been an topic that any could have brought up over the last several > >> years. If someone has specifics, I suggest they get out a full > >> proposal really soon. I am very doubtful that hole punching = solution > >> is fundamentally different than the type of hole punching ICE does. > >> > >> 5) Some people have suggested that if all NATs were behave = complaint, > >> then we would not need ICE. I strongly disagree. I think the only > >> part of ICE we would not need is the TURN relays which are more or > >> less an optional part. Again, specifics on what can be removed are > >> welcome. > >> > >> ICE is far more complicated that anyone wants - the problem is, no > >> one has come up with a proposal that looks like it comes anywhere > >> close to meeting the requirements and if simpler. The design space > >> has been extensively explored by many people. The raw data to > >> understand what will work on what NATs have been painfully tested = and > >> documented in publications such as: > >> > >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf > >> > >> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt > >> > >> https://www.guha.cc/saikat/stunt-results.php? > >> > >> (Ford used to have a page too but it seems to be gone) > >> > >> I have a very open mind to considering better ways to do ICE - but = I > >> need specific suggestions or it is impossible for me to really = think > >> about if the suggestions represent a better path or not. > >> > >> I would love to see more open source ICE code (there is lots = already) > >> - I feel that this is an area where ICE is likely just table stakes > >> and owning an proprietary ICE stack will not turn out to be a > >> competitive advantage. Having open source implementations where the > >> development cost was shared and everyone could get working products > >> to market faster would be an advantage to companies. Clearly I = expect > >> the bulk of ICE implementations to not be open source but I still > >> would be keen on doing what I can to contribute to an open source > >> version as personally I feel that is in the interest of end users, = my > >> employer, and the IETF as a SDO. > >> > >> Cullen > >> > >> > >> > >> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: > >> > >>> > >>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > >>> > >>>> Henry Sinnreich skrev: > >>>>> Following some discussions and soul searching, the best > >>>>> approach for > >>>>> ICE-17 for LC would be to _go ahead and make it an experimental > >>>>> RFC_. > >>>>> This would support the development of interoperable > >>>>> implementations, the > >>>>> collection of deployment data and also hopefully open source = code. > >>>>> Though I have full faith in ICE, following the practices that > >>>>> made the > >>>>> IETF successful take precedent here, I believe. > >>>>> This is a change from the attached that I wrote on 7/16/2007. > >>>>> Note: We can only hope the proliferation of SBC in VoIP service > >>>>> provider > >>>>> networks will not make these concerns and ICE for SIP a moot > >>>>> issue, but > >>>>> this is another topic. > >>>> > >>>> Henry, > >>>> > >>>> I don't quite understand why you are requesting a status change = of > >>>> ICE? To me it appears that ICE is almost finished spec. It has > >>>> been implemented, used and feedback has been influencing the > >>>> protocol. It is definitly one of the better examples of current > >>>> IETF work that actually has running code. Sure, the > >>>> implementations may not be fully updated yet to the latest draft > >>>> version. But I think it is safe to say that ICE works in the > >>>> intended core cases. If there are some corner cases where it > >>>> fails, that may be. But that is not information we will have = until > >>>> really large scale deployement or someone makes very extensive > >>>> tests. > >>> > >>> Henry has, I believe, been very consistent in urging the IETF to > >>> have more "running code" experience on every specification (not > >>> just ICE) than our process requires. He has, IIRC, also advocated > >>> changing the process to require running code before publishing an > >>> RFC. He's even suggested at times that one should have running = code > >>> before submitting a protocol draft. > >>> > >>> Another point to consider -- I've known Henry to bark at a tree > >>> with no squirrel in it occasionally, but most of the time he's > >>> pretty reliable, more so than most technology predictors. If he's > >>> worried about ICE, it's probably because he's been talking to > >>> people who are trying to implement it and they're telling him it = is > >>> difficult or that they're having performance or reliability = issues. > >>> I imagine that there are plenty of internal development teams in > >>> various companies that are working on this and not necessarily > >>> bringing their results back to the IETF. After all, if everybody > >>> sees the emperor as fully clothed, they'd be embarrassed to > >>> proclaim otherwise. Of course, I wish all of these developers were > >>> tied into the IETF, but then I'm sure I don't want to see every = ice- > >>> implementor's question on the SIP list. That is why we have a sip- > >>> implementors mailing list, right? > >>> > >>> Personally, I think ICE is the best solution we have. We KNOW of > >>> cases where hole-punching doesn't work, and I think ICE will > >>> produce usable results in most of those cases. But that's just my > >>> personal opinion from reading the specs. I haven't implemented = ICE, > >>> and I haven't used anybody else's implementation. Sure, it's > >>> complex, but that's because the underlying problem is complex -- > >>> there are just too many different behaviors out there in "NAT and > >>> firewall land". Of course, I could be wrong, too. It's happened > >>> before, once or twice ;-). Just how sure are we that we're right > >>> about this? > >>> > >>> Are we designing a "spruce goose" or a practical system? Only > >>> experience will tell us. But some good flight reports from the > >>> prototypes could go a long way towards reassuring us of the > >>> design's utility. > >>> > >>> So far we've had a couple of people report hearsay evidence -- = that > >>> somebody else has an ICE implementation and it works. Any of you > >>> folks have personal experience you can share? Have there been > >>> prototypes exercised at the interop events? > >>> > >>> -- > >>> Dean > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 14: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 1IBaN5-0004NH-6g; Thu, 19 Jul 2007 14:05:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBaN4-0004Ip-5X for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:05:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaN3-0004Gc-OY for behave@ietf.org; Thu, 19 Jul 2007 14:05:01 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBaN3-0008UK-8M for behave@ietf.org; Thu, 19 Jul 2007 14:05:01 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1IBaN0-0003KL-Js; Thu, 19 Jul 2007 14:04:58 -0400 In-Reply-To: <0bca01c7ca29$89f1e5f0$7d646b80@amer.cisco.com> References: <0bca01c7ca29$89f1e5f0$7d646b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28473C93-4B8A-40C3-A1D7-584F53312447@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] ICE performance Date: Thu, 19 Jul 2007 14:05:08 -0400 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: behave@ietf.org, 'Henry Sinnreich' , dank@kegel.com, baford@mit.edu, henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 19-Jul-07, at 13:23 , Dan Wing wrote: > >> Describing Linux BUG ('X:x' is an IP address / port): >> >> A STUN Server NAT B >> | | |<---------------| >> | |<-----src:X:x------| | >> | | | | >> | | | | >> |-----dst:X:x-------------------------->| | >> |<--ICMP port unreach-------------------| | >> | | | | >> | | |<---------------| >> |<----src:X:y---------------------------| | >> | | | | >> | | | | >> >> At a first glance, this behavior would not impact the ICE >> communication between a host without NAT (open) versus >> another host behind this type of NAT (this scenario will >> issue a peer derived candidate). But if the host 'A' is >> behind a "Port Restricted NAT", the connection has high >> probability to not establish on peer-to-peer basis: the host >> 'B' needs to pass a packet through NAT before a packet from >> host 'A' comes in (this way, the NAT works as a normal >> "Port Restricted NAT"). > > > Thanks for the write-up. B's NAT is behaving as a symmetric NAT > because a host on the Internet (A) sent a UDP packet to that > port on B's NAT. (Any well-timed UDP packet, sent maliciously > or accidentally to that port on B's NAT would also cause B's > NAT to become symmetric for that flow. Perhaps too obscure > of an attack to worry about?) > > As you point out, ICE will not establish a peer-to-peer session > in this case (the case where one peer is behind a symmetric NAT > and the other peer is behind a port-restricted NAT). Instead, > ICE will only be able to establish connectivity via a media > relay. In ICE-17, the receipt of the ICMP port unreach will cause the connectivity check from A to fail. [From section 7.1.2.1: Agents MAY support receipt of ICMP errors for connectivity checks. If the STUN transaction generates an ICMP error, the agent sets the state of the pair to Failed. If the STUN transaction generates a STUN error response that is unrecoverable (as defined in [I-D.ietf-behave-rfc3489bis]), or times out, the agent sets the state of the pair to Failed. However, the receipt of the subsequent Binding Request from B will cause the connectivity check to go back to the Waiting state and B will retry the check. [From section 7.2.1.4: * If the state of the pair is Failed, it is changed to Waiting and the agent MUST create a new connectivity check for that pair (representing a new STUN Binding Request transaction), by enqueueing the pair in the triggered check queue. So ICE will succeed (or should, I haven't done walked through the logic yet) in this case. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 14:08: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 1IBaQZ-0007QA-SO; Thu, 19 Jul 2007 14:08:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBaQW-0007K6-Di for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:08:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaQV-0007Jn-TG for behave@ietf.org; Thu, 19 Jul 2007 14:08:36 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBaQU-00060w-KR for behave@ietf.org; Thu, 19 Jul 2007 14:08:35 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:08:31 -0700 From: "David Barrett" To: "'Adam Roach'" , "'Frank W. Miller'" Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 11:08:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <469F8577.4080506@estacado.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKGuJrnaAzFrntQRqf5CHohBEUPQAFKB0g X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Message-Id: Cc: 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Adam Roach [mailto:adam@estacado.net] > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > To be clear: to get this kind of experience (especially as it pertains > to interoperability), you need to have a stable (i.e., frozen) > specification. Internet Drafts simply don't provide an appropriate basis > for the kinds of proof that you and others are demanding. It seems premature to freeze the specification before we've proven that what specified actually works. Indeed, the most successful real-world projects I've participated in worked in the exact opposite manner. -da _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 14:36: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 1IBarn-00018k-9F; Thu, 19 Jul 2007 14:36:47 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBarl-00017X-Ek for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBarl-00017L-4z for behave@ietf.org; Thu, 19 Jul 2007 14:36:45 -0400 Received: from web33304.mail.mud.yahoo.com ([68.142.206.119]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBark-0006uf-8Q for behave@ietf.org; Thu, 19 Jul 2007 14:36:45 -0400 Received: (qmail 88534 invoked by uid 60001); 19 Jul 2007 18:36:43 -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=bigYgUwI+cfV9L3tv5m93sHHFpmTZCtbqsSohA/prvWyYodznXDGIjyowcGpskBYIz9UxC7xlm1TpfPSngm0CyH59G5+ImcfuE+m+VGxJfg5US/CTXNCF2c9NwAHuKIJHuHx7bEKzKzuaak1si9og0gtFUmJjpAG1CBYUevbZR4=; X-YMail-OSG: QjmRvcwVM1lWWTrYcJAAjxuVPSWN8nP_s5NpjThwTRjFWiaIk_ocu.mBDGjIkj_X0D3lm4H.lw-- Received: from [209.172.74.45] by web33304.mail.mud.yahoo.com via HTTP; Thu, 19 Jul 2007 11:36:43 PDT Date: Thu, 19 Jul 2007 11:36:43 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: Magnus Westerlund In-Reply-To: <469F1CEA.1040101@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <383711.88528.qm@web33304.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: behave@ietf.org, 'Henry Sinnreich' , mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Magnus, The discussion thread started on the BEHAVE list. I believe, My comments are also relevant to BEHAVE list. SO, I am including BEHAVE list to this thread. Please see my comments inline below. Thanks. regards, suresh --- Magnus Westerlund wrote: > Dropping all lists but MMUSIC! > > Pyda Srisuresh skrev: > > Thanks to Henry and Frank for so eloquently articulating this. > > > > As both Henry and Frank mentioned, I fully support standardizing on HOLE > > PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence to > force > > NAT vendors to migrate towards implementations that are friendly to Hole > > Punching and the Application developers to design applications using the > hole > > punching techniques. That should be the FIRST order of priority. > > > > Yet, what is happening in BEHAVE WG is the other way around. Some people > have > > put their weight so heavily in favor of ICE that they asked to drop the > work on > > hole punching technique as WG item. THIS IS WRONG. I no longer see "NAT > > Traveral application design guidelines" as BEHAVE WG milestone. > > > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING > TECHNIQUES > > to move forward as a WG item? > > I would like to remind people about a few things. ICE was request to > become a MMUSIC WG item in Vienna, that is FOUR years ago! The people > present supported that. During these years ICE has been rebaked several > times. People have provided input about a number of things; traversal > cases that didn't work, different forms of complexity, signalling usage. > > During these 4 years anyone have had the possibility to influence the > process, including standing up saying that we should forget about the > maximum reliability for the sake of simplicity. But the consensus in > this discussion has remained that reliabilty is important. And I also > think the changes has shown that one has tried all the tricks that has > been thought of try to reduce the complexity of ICE. But as I think most > of you agree on, NAT traversal is problematic and simple solution > doesn't always work. We are today at state where we don't know know how > to make things simpler without sacrificing functionality. > > There also has been discussion about if there should be multiple > solutions etc. But, to my knowledge the consensus also there has been > that one solution is the way to go. > [suresh] I have not been part of the discussion pertaining to the merit of multiple solutions vs single soultions. This may have been discussed in the context of SIP and NAT traversal. So, I cant comment on this. But, let me reiterate that HOLE PUNCHING TECHNIQUES have been around longer than ICE. The techniques are generic and applicable to application traversal in general. Kegel's work on UDP is the first published work on UDP hole punching. USENIX paper by Bryan, Kegel and myself is the first work on TCP hole punching. ford-behave-app draft is the first draft that I know if that describes the BCP design practicies for P2P applications to traverse NATs. > So Suresh, you and everyone else as participants in the IETF is > responsible for what you call HOLE PUNCHING TECHNIQUES are not an WG > item. [suresh] Magnus - I dont know what you are talking about. How do you mean I am responsible for why the HOLE PUNCHING TECHNIQUE draft is not a WG item. The ford-behave-app draft has been around for many years since the inception of BEHAVE. Last I checked, The application milestone is no longer on BEHVAE charter. I certainly am not responsible for removign the milestone. > The IETF has run its consensus process and it is now close to > completing and producing a ready specification. It may or may not have > been looking different if you had provided the details about how such a > solution would look. And worked to get consensus that it was what the > IETF wanted. > > Complaining about the general design and tradeoffs after two WG last > calls and more than four years of development isn't productive. You all > contributed to the consensus process that has leads to this state. At > this point only serious bugs in the solution should be forcing any > backtracking. Revisiting our choices at this point is wasting time > unless there are very strong evidence that the choices made was wrong. > [suresh] Magnus - I have not been part of the consensus for ICE. However, I do know ICE adapts the HOLE PUNCHING TECHNIQUES and the BCP recommendations identified in ford-behave-app draft. Yet, neither of the ICE drafts (UDP or the TCP version) refer the ford-behave-app draft or prior work on HOLE PUNCHING as normative reference. This iS WRONG. I believe, the ICE drafts should refer the prior work (kegel work on UDP hole punching, USENIX paper for TCP hole punching and ford-behave-app draft for application traversal design) on which the ICE work is based. On the one hand, IETF (IESG) has been adamant about the standard level of the normative references for a proposes standard. Yet, it is ironic that when HOLE PUNCHING is normative to the design of ICE, the IETF is not allowing the HOLE PUNCHING work to be standardized. Why is the IETF not allowing HOLE PUNCHING TECHNIQUES and P2P application traversal identified in draft-ford-behave-app draft to move forward as a BCP WG item? regards, suresh > I do understand that Henry is arguing for that more experience should be > gathered. But, I am not personally agreeing that we need more to publish > this as an proposed standard. There has been implementations, there have > been tests, there is even deployement as I understand it for earlier > versions. I think this all indicate that the general principle does > work. And it is great that we are seeing implementations being updated > to follow the latest spec, that will help confirm that things do work. > But, to me the ICE specification is the most reviewed, worked on > specification that I personally has been involved in within the IETF. We > are approaching fast the point where more baking will not make any > improvements worth wathing for. If there are some minor error are found > down the road, we can update the RFC at that point. But I don't see that > adding more delay or make it jump through more hops will be beneficial > at all. It only increases the time to complete a specification I think > the market really want. > > > Cheers > > Magnus Westerlund > (Within his individual hat because this is not my WG) > > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 14:37: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 1IBas5-0001IO-Tg; Thu, 19 Jul 2007 14:37:05 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBas5-0001I5-A5 for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:37:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBas4-0001Hw-WA; Thu, 19 Jul 2007 14:37:05 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBas4-0001DR-KS; Thu, 19 Jul 2007 14:37:04 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBary-0005o8-2q; Thu, 19 Jul 2007 14:36:59 -0400 In-Reply-To: <469F8577.4080506@estacado.net> References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> <469F8577.4080506@estacado.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <906B914C-31A5-43E9-99B5-424899262C7B@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 14:37:17 -0400 To: Adam Roach X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: SIP , Behave WG , IETF MMUSIC 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 19-Jul-07, at 11:38 , Adam Roach wrote: > On 7/19/07 10:19 AM, Frank W. Miller wrote: >> FM: While I applaud the time and effort that the large vendors have >> obviously invested in this, this is a qualitative statement. >> Perhaps Cisco >> and/or Microsoft have empirical data they would be willing to >> share about >> robustness and performance? > > That's the kind of data you get between "proposed standard" and > "draft standard" -- not *prior* to publication. I'm not sure why > there's so much noise about setting the bar much, much higher for > ICE than we do for other IETF proposals. Just to play the other side of the fence ... In theory, RFCs advance from "proposed standard" to "draft standard" to "full standard". In practice, this rarely happens. In practice, once an RFC is published, it is either accepted and becomes a de-facto standard, or is ignored. Rarely is it revised and advanced along the standards track. And it is often difficult to discover which status (de-facto standard or ignored) a particular RFC actually has. Look at SIP, for example. It is still at "proposed standard" and will likely stay there for a long time. What Henry, David, and Frank want is some evidence that actually works (and thus will become the de-facto standard) before publishing the document as an RFC. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 16:59: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 1IBd64-0004on-Oi; Thu, 19 Jul 2007 16:59:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBd62-0004oe-V0 for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 16:59:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBd62-0004oW-Jc for behave@ietf.org; Thu, 19 Jul 2007 16:59:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBd61-00058N-OQ for behave@ietf.org; Thu, 19 Jul 2007 16:59:38 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Jul 2007 13:59:07 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAL9sn0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,558,1175497200"; d="scan'208"; a="505088809:sNHT73150611530" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6JKx69J008988; Thu, 19 Jul 2007 13:59:06 -0700 Received: from dwingwxp (dhcp-128-107-102-137.cisco.com [128.107.102.137]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6JKwuSb020678; Thu, 19 Jul 2007 20:58:57 GMT From: "Dan Wing" To: "'Philip Matthews'" Subject: RE: [BEHAVE] ICE performance Date: Thu, 19 Jul 2007 13:58:56 -0700 Message-ID: <009401c7ca47$a4d15720$fc736b80@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: <28473C93-4B8A-40C3-A1D7-584F53312447@magma.ca> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKL1kSr5iigImcSpajqLHn3rG4FAAF5nnQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3891; t=1184878746; x=1185742746; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20ICE=20performance |Sender:=20; bh=a+JsqwDeuQAnmOvpg+JPnrmpbPH4GW3og0OAA9YlMGE=; b=r5huzTkygrtzJkYhtiIBM0ATwdMj+0uaihXTvDI1g9zwuf0ju6AMmjDzgWjKkfuATlkSY7Ip FAdTFk6nqr+rs/0fUhJ3Yx57WD/9dhYwcZi6280RluAn595R+D3cG/D47P5X5yAGuQklY3ntfn bhFYR/goEiWq6NkneNznAt6kM=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: behave@ietf.org, 'Henry Sinnreich' , dank@kegel.com, baford@mit.edu, henrys@adobe.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > On 19-Jul-07, at 13:23 , Dan Wing wrote: > > > > >> Describing Linux BUG ('X:x' is an IP address / port): > >> > >> A STUN Server NAT B > >> | | |<---------------| > >> | |<-----src:X:x------| | > >> | | | | > >> | | | | > >> |-----dst:X:x-------------------------->| | > >> |<--ICMP port unreach-------------------| | > >> | | | | > >> | | |<---------------| > >> |<----src:X:y---------------------------| | > >> | | | | > >> | | | | > >> > >> At a first glance, this behavior would not impact the ICE > >> communication between a host without NAT (open) versus > >> another host behind this type of NAT (this scenario will > >> issue a peer derived candidate). But if the host 'A' is > >> behind a "Port Restricted NAT", the connection has high > >> probability to not establish on peer-to-peer basis: the host > >> 'B' needs to pass a packet through NAT before a packet from > >> host 'A' comes in (this way, the NAT works as a normal > >> "Port Restricted NAT"). > > > > > > Thanks for the write-up. B's NAT is behaving as a symmetric NAT > > because a host on the Internet (A) sent a UDP packet to that > > port on B's NAT. (Any well-timed UDP packet, sent maliciously > > or accidentally to that port on B's NAT would also cause B's > > NAT to become symmetric for that flow. Perhaps too obscure > > of an attack to worry about?) > > > > As you point out, ICE will not establish a peer-to-peer session > > in this case (the case where one peer is behind a symmetric NAT > > and the other peer is behind a port-restricted NAT). Instead, > > ICE will only be able to establish connectivity via a media > > relay. > > In ICE-17, the receipt of the ICMP port unreach will cause the > connectivity check from A to fail. [From section 7.1.2.1: > Agents MAY support receipt of ICMP errors for connectivity checks. > If the STUN transaction generates an ICMP error, the > agent sets the > state of the pair to Failed. If the STUN transaction generates a > STUN error response that is unrecoverable (as defined in > [I-D.ietf-behave-rfc3489bis]), or times out, the agent sets the > state > of the pair to Failed. > > However, the receipt of the subsequent Binding Request from B will > cause the connectivity > check to go back to the Waiting state and B will retry the check. > [From section 7.2.1.4: > > * If the state of the pair is Failed, it is changed to Waiting > and the agent MUST create a new connectivity check for that > pair (representing a new STUN Binding Request > transaction), by > enqueueing the pair in the triggered check queue. > > So ICE will succeed (or should, I haven't done walked through the > logic yet) in this case. Look carefully at Guilherme's diagram. That subsequent message from B comes from a different source UDP port (because when B's NAT received the ICMP, B's NAT effectively switched into 'symmetric' NAT behavior). Up to this point, I agree that ICE would set up peer-to-peer because of that subsequent message from B. However, in Guilherme's email, he indicated that A's NAT is a port-restrictive NAT. Because of that, B's subsequent Binding Request (which is from a different port than A had been told via the SDP offer/answer exchange) would be dropped by A's NAT. ICE, on this peer-to-peer path, would be unable to complete. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 17:14:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdKk-00014Q-7X; Thu, 19 Jul 2007 17:14:50 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBdKh-0000xk-Gx for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 17:14:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdKg-0000tc-Pm; Thu, 19 Jul 2007 17:14:46 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBdKg-0005RE-9s; Thu, 19 Jul 2007 17:14:46 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Jul 2007 14:14:38 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JLEQWs013301; Thu, 19 Jul 2007 14:14:27 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JLCUI9025470; Thu, 19 Jul 2007 14:12:30 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 14:14:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jul 2007 14:14:21 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEDCA6@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: ICE deployment data before LC for RFC Thread-Index: AcfKSR+4bsdL7cvpRK+b5k7AGN+GsQ== From: "Henry Sinnreich" To: , , , , X-OriginalArrivalTime: 19 Jul 2007 21:14:25.0847 (UTC) FILETIME=[C9168C70:01C7CA49] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 apology for the duplicate postings.=20 Having initiated this ample discussion about how to proceed with ICE-17, it seems the following have emerged: ICE-17 is an excellent document (bravo authors and contributors) and can hardly get better at present. The technical points discussed cannot change this fact either way. Ironically, the defense of ICE-17 on procedural grounds makes even less sense, since the culprit is not ICE-17, but the fact that present IETF procedures do not make a clear enough distinction that everyone can understand between I-D categories, such as: * Concept memos; see the torrent in the P2PSIP WG * Protocol standard agreements, such as for SIP * Technology solutions such as ICE-17 or hole punching for NAT traversal * I-Ds to support a business model (excuse me; I will not go there...) Sorry to repeat: Process and consensus in meetings have nothing to do with how good a technology may be. Only measurements and proof will do. How does the IETF support the proof for a technology? (Yes, I have seen all those quotes). Please remember that proving a technology also costs money. This is the reason why I trust more technologies coming out of funded R&D, especially from University research. Vendors of technology may be less likely to share such information. Question: Is a standards organization the best place to develop and promote new technology such as for NAT traversal? (all those p2p companies and Skype did not think so...) Also, be prepared, SBC traversal may come next. In conclusion, there is nothing wrong with the ICE-17 paper IMHO, but rather the IETF processes are either not satisfactory or not well understood by folks like me who avoid reading process documents longer than one web page :-)=20 I have taken therefore the liberty to copy as Adam Roach has suggested. Thanks,=20 Henry Sinnreich _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 19 20:11: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 1IBg5V-0007Do-08; Thu, 19 Jul 2007 20:11:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBg5T-00077g-Bl for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 20:11:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBg5S-00074r-Rg for behave@ietf.org; Thu, 19 Jul 2007 20:11:14 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBg5S-0000tV-9r for behave@ietf.org; Thu, 19 Jul 2007 20:11:14 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 19 Jul 2007 17:11:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADean0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,558,1175497200"; d="scan'208"; a="386967086:sNHT36515436" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6K0BDYK017851; Thu, 19 Jul 2007 17:11:13 -0700 Received: from dwingwxp ([128.107.115.252]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6K0BD6C016308; Fri, 20 Jul 2007 00:11:13 GMT From: "Dan Wing" To: "'Mayank Dev Sondhi'" , "'Marc Petit-Huguenin'" Subject: RE: [BEHAVE] Redirect for STUN Relay Date: Thu, 19 Jul 2007 17:11:12 -0700 Message-ID: <011201c7ca62$7b5740b0$fc736b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfJ4FF335DVsGelSLSU83g5p3EDXQAgf0zQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3637; t=1184890273; x=1185754273; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Redirect=20for=20STUN=20Relay |Sender:=20; bh=kwovknqKZ+I3o9GfzGKuVaV8r6aM4ArpJArPKqru8zk=; b=FljPFeyM5/lfJJSOx7rrSJOqxDlog0EVCfdTax5FgvOJ4h4Nl5TIMui/3py1li4Ewc6ZU7As Iq7uL9V82cIWJoyHCzDTq4goMI1jNjSLvyBzCc51ugH4clNo4+tXoQr4qlHfgxm+rja6zyjTp6 aZ9JSuF4zzOCNBwocxUmJKEHY=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 We kept 300 in rfc3489bis-07, http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-07#section-14.6 (but I don't think Marc's email was ever followed up. Sorry about = that.) -d > -----Original Message----- > From: Mayank Dev Sondhi [mailto:msondhi@gmail.com]=20 > Sent: Thursday, July 19, 2007 1:39 AM > To: Marc Petit-Huguenin > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Redirect for STUN Relay >=20 > +1 for me too, we use the 300 response for working WITH our=20 > load balancers, this is definitely useful. As for security=20 > issues, we rely on Message-Integrity to protect the address.=20 > Ping-ponging across servers is left to the client to handle=20 > appropriately(fixed number of retries before giving up)=20 > =20 > -Mayank >=20 > =20 > On 7/5/07, Marc Petit-Huguenin wrote:=20 >=20 > Jonathan Rosenberg wrote: > > Actually, this is something which we were planning on=20 > removing in the > > revision coming up. There were comments during last=20 > call about the > > utility of the mechanism, security concerns, and so=20 > on. Also there > > didn't seem to be anyone who wanted it. > =09 > OK, I missed the discussion, because I use the 300=20 > response, and plan to=20 > continue to use it. I also proposed a long time ago to=20 > replace the IP > address in the 300 response by a name so the SRV RR=20 > processing can be > reapplied, but without success. > =09 > There are much better ways of > > doing load balacning, for example utilizing a=20 > front-end load balancing > > element that actually tracks capacity of back end=20 > relays, and then > > directs the request to the least loaded server. THis=20 > is standard=20 > > practice for load balancing for many other protocols. > =09 > This also force to buy expensive stuff that is not=20 > needed with the end > to end mechanisms. It's OK if people want to use=20 > B2BUA, SBC, load > balancers, NAT - their money, not mine - but Internet=20 > standards should=20 > not force people to do this. > =09 > So I am strongly opposed to remove the 300 response from STUN. > =09 > > That kind of > > mechanism is also faster and more stable. Redirect=20 > mechanisms can result > > in ping-ponging especially near capacity limits.=20 > > > > -Jonathan R. > > > > Asveren, Tolga wrote: > >> O.K., sorry my bad. > >> > >> Thanks, > >> Tolga > >> > >>> -----Original Message----- > >>> From: R=E9mi Denis-Courmont [mailto:=20 > remi.denis-courmont@nokia.com] > >>> Sent: Thursday, July 05, 2007 2:09 AM > >>> To: behave@ietf.org; Asveren, Tolga=20 > >>> Subject: Re: [BEHAVE] Redirect for STUN Relay > >>> > >>> On Thursday 05 July 2007 05:30:06 ext Asveren, Tolga wrote: > >>>> I was wondering whether it would make sense to=20 > have redirect type of=20 > >>>> functionality for STUN Relay, e.g. referring=20 > another server in a > >>>> negative answer to an initial allocate request. > >>> This is *already* in the specification, and has=20 > been there for several=20 > >>> years. > >>> > >>> -- > >>> R=E9mi Denis-Courmont > =09 > -- > Marc Petit-Huguenin [ =20 > ] > Home: marc@petit-huguenin.org=20 > [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ =20 > ] > =09 > =09 > _______________________________________________=20 > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > =09 >=20 >=20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 20 10:55: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 1IBtt3-000188-N0; Fri, 20 Jul 2007 10:55:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBtt2-00017t-Fv for behave-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 10:55:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtt2-00017l-6T for behave@ietf.org; Fri, 20 Jul 2007 10:55:20 -0400 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBtt1-0000fe-QH for behave@ietf.org; Fri, 20 Jul 2007 10:55:20 -0400 Received: (qmail 42524 invoked by uid 60001); 20 Jul 2007 14:48:38 -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=bgOG0vEyxaJUH0jcE3EPAYoUALnk99g5hyCvgkoZR9UDDiSB4ppOhkAXvZuRxvqsetUKD7VaPx7+8VJjpOS6ctqXlE28pht271hlG7yQfowt360CE3eYB0RNJAxw5tPKt5GzzkbQWSH4WNr5c2jzOEFlx9/TLH41xOjF2XjpZME=; X-YMail-OSG: p_naqYoVM1k8h9.pNsw5qeWaWi.N2xoQnYRPbntHxDHAUnSmCZRDU.sd4z7zU7.G_fRTsU6BaQ-- Received: from [69.236.76.222] by web33306.mail.mud.yahoo.com via HTTP; Fri, 20 Jul 2007 07:48:38 PDT Date: Fri, 20 Jul 2007 07:48:38 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: Philip Matthews , Henry Sinnreich In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <615870.42407.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: behave@ietf.org, mmusic@ietf.org, sip@ietf.org, p2psip@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 --- Philip Matthews wrote: > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > > > Phil, > > > >> In my view, ICE _is_ a "Hole Punching Technique". > > > > Yes, you absolutely right, though the devil is in the details. > > > > We cannot go here into a shoot-out between hole punching or other > > mentioned on the list vs. ICE, but there seems to be a huge difference > > in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; [suresh] I dont know what you are talking about. AFAIK, Peer reflexive address is same as the public endpoint assigned to a node behind NAT. How can that be not part of HOLE-PUNCHING technique? > - ICE has the concept of controlling/controlled endpoint, which gives > the controller additional flexibility in choosing a path; [suresh] HOLE-PUNCHING technique is based on communication along a control path with external rendezvous server(s), which act as the key controller. The peering endpoints either make requests to punch holes or receiving requests to help in hole-punching by a peer. > - ICE does NOT have the concept of port prediction, which some other > techniques do (e.g., Saikat's TCP work). [suresh] Hole punchign technique is not complete by itself to setup connections. It needs a fallback scheme. Port prediction and relays can be effective fallback to hole punching. regards, suresh > > Philip > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 20 12:06: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 1IBv02-0000VO-9Q; Fri, 20 Jul 2007 12:06:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBaln-0003QR-T3 for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:30:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaln-0003Q7-9C; Thu, 19 Jul 2007 14:30:35 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBalm-0000zd-Sn; Thu, 19 Jul 2007 14:30:35 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6JIUSek015558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 13:30:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <469FADC9.3000006@nostrum.com> Date: Thu, 19 Jul 2007 13:30:33 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: David Barrett Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Fri, 20 Jul 2007 12:06:36 -0400 Cc: 'SIP' , 'Behave WG' , mmusic@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 7/19/07 1:08 PM, David Barrett wrote: >> -----Original Message----- >> From: Adam Roach [mailto:adam@estacado.net] >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> To be clear: to get this kind of experience (especially as it pertains >> to interoperability), you need to have a stable (i.e., frozen) >> specification. Internet Drafts simply don't provide an appropriate basis >> for the kinds of proof that you and others are demanding. >> > > It seems premature to freeze the specification before we've proven that what > specified actually works. Indeed, the most successful real-world projects > I've participated in worked in the exact opposite manner. > In that case, you're arguing with the IETF standards process, and have decided to beat on ICE as a proxy whipping boy for reasons that have no technical basis in ICE itself. The current process surrounding RFC publication is detailed in RFC 2026. Section 4.1 details the process you're misunderstanding. It's short. You should read it. If you're up to it, RFC 3774 and RFC 3844 also provide some useful background on the work that has been done in this area recently. Concerns about IETF RFC publication process in general -- and that's what you're arguing about here, not ICE itself -- are best addressed to the IETF-general mailing list and/or the IESG itself (as the conclusion of the problem WG was that issues surrounding the standards process were to be handed back to the IESG). /a _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 20 12:06: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 1IBv04-0000ZX-5x; Fri, 20 Jul 2007 12:06:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBqtY-0002ki-SQ for behave-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 07:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBqtV-0002kJ-Io; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBqtU-0004vw-2E; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49215) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IBqtQ-0003El-Cr; Fri, 20 Jul 2007 12:43:32 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <40048F36-6069-40A3-BF6E-42D458638709@csperkins.org> Content-Transfer-Encoding: quoted-printable From: Colin Perkins Date: Fri, 20 Jul 2007 12:43:30 +0100 To: MMUSIC WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Fri, 20 Jul 2007 12:06:36 -0400 Cc: Jean-Francois Mule , Joerg Ott Subject: [BEHAVE] Progressing 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 [This note is sent to MMUSIC, with bcc to BEHAVE, SIP, and P2PSIP =20 since the discussion has included those groups. Replies to MMUSIC =20 only please, as ICE is an MMUSIC working group draft] The MMUSIC chairs have reviewed the mailing list discussion =20 pertaining to ICE over the last few days. While we agree that further =20= implementation experience and publication of deployment results would =20= be valuable, as it is for any new protocol, we do not believe this =20 sufficient cause to revisit the consensus to request publication of =20 draft-ietf-mmusic-ice-17.txt as a Proposed Standard. The characteristics of Proposed Standard specifications are described =20= in RFC 2026 section 4.1.1 as follows: > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has =20 > received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. > > A Proposed Standard should have no known technical omissions with > respect to the requirements placed upon it. However, the IESG may > waive this requirement in order to allow a specification to advance > to the Proposed Standard state when it is considered to be =20 > useful and > necessary (and timely) even with known technical omissions. > > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. Our judgement is that ICE meets these requirements, and that there is =20= general working group consensus to request publication. Accordingly, =20 our intention is to proceed as we previously announced, and request =20 that ICE be published as a Proposed Standard RFC. Colin Perkins, J=F6rg Ott, and Jean-Fran=E7ois Mul=E9 MMUSIC chairs _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 20 12:06: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 1IBv01-0000Ue-Up; Fri, 20 Jul 2007 12:06:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBWu7-0004no-N1 for behave-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 10:22:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWu7-0004nf-Ap; Thu, 19 Jul 2007 10:22:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBWu5-0001cB-P4; Thu, 19 Jul 2007 10:22:55 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2007 07:22:53 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALMPn0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="167345601:sNHT37532907" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6JEMqNK031706; Thu, 19 Jul 2007 07:22:52 -0700 Received: from [10.32.245.154] (stealth-10-32-245-154.cisco.com [10.32.245.154]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6JEMo6C005087; Thu, 19 Jul 2007 14:22:50 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4BD296F0-6FC7-4BDE-A783-A835F081FBE7@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 10:22:40 -0400 To: "David Barrett" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12383; t=1184854972; x=1185718972; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=kqAskR4tW+DPt7PvKW86K+THsqhA+TM3eU/Pi58egKQ=; b=epeHg/r4RBUPTAeLA1lWvf0v1oPD3eMC7bZLizS+3AIfwH00Haa3Ql5fVLI5FOyTEf71XEyw WileZupc1krOR5mCO8GEMflbOq9B8jQECA+1ly2NLow3mUzDlUJS+6RQ; Authentication-Results: sj-dkim-4; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac X-Mailman-Approved-At: Fri, 20 Jul 2007 12:06:36 -0400 Cc: 'SIP' , 'Behave WG' , mmusic@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 Jul 19, 2007, at 6:15 AM, David Barrett wrote: > Hi Cullen, I think you bring up lot of really great and detailed =20 > questions. > > However, speaking for myself at least, answering those questions =20 > doesn't > really address my concern. All I want to know is: > > Does ICE work, and how well? > > What "works" means is entirely open to debate. It may have been in the past, but the debate I think is closed, =20 because the requirements captured the definition of "works". If you =20 want to re-open the requirements discussion, please be clear about that. > I've tossed out "high peer > connectivity" and "low connection setup time" as the most important > criteria, and I've put hard data behind those numbers as a stake in =20= > the > ground for comparison, but I'm open to other metrics as well. > See the requirements. One not often mentioned but clearly a =20 requirement that ICE works very hard to meet is "use the most direct =20 path available". > But regardless of the metrics, I want somebody who uses it and =20 > loves it and > bases their business upon its success to stand up and explain why it's > great. > And I want this person to provide real-world data, sampled on a wide > scale, proving that ICE "works" -- by any definition. > This is in fact an extremely important exercise, and precisely the =20 activity which according to RFC2026 is what should be happening after =20= approval as proposed standard, and before advancement to draft =20 standard. > Basically, I want ICE firmly grounded in wide-scale testing and =20 > real-world > data, and answering the questions below doesn't bring us any closer =20= > to that. > Whether it's level 10 or level 12 doesn't produce new data. How its > algorithms differ from competing ones doesn't show that they're any =20= > better > or worse. Detailed proposals for change don't shed any light on =20 > whether > those changes improve or worsen it, because its current state is =20 > completely > unmeasured. > Showing how the algorithms work better, or work in more cases that =20 are covered by the requirements does in fact show that it's better, =20 with respect to the requirements. Again, you're arguing indirectly =20 that we should re-open the requirements discussion, which I do not =20 think would be terribly productive, but would support if there is in =20 fact consensus to do so. > The most powerful thing the IETF can do to standardize the world =20 > upon ICE is > prove that it works better than any alternative. Because until that's > proven, we just need to take it as a matter of faith. > I do not think that is desirable. The perfect is the enemy of the =20 good. ICE does not have to be better than anything else. It just has =20 to be "good enough" and see wide adoption. That's my 2=A2 (as an individual, not as an IAB member, in case anybody =20= cares). DaveO > -david > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 18, 2007 7:56 PM >> To: SIP; Behave WG; mmusic@ietf.org >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC =20 >> for RFC >> >> >> First I apologize for the cross post - this is a mmusic draft, I >> would appreciate replies on the mmusic list only. >> >> Few things I am looking for here .... >> >> 1) specific reasons why this work is less appropriate for standards >> track than other work that IETF puts on the standards track. Keep in >> mind the first step of standards track is Proposed Standards which >> requires basically no interoperability, then it could move to Draft >> Standard where interoperability is shown and finally Full Standard if >> it turns out to be a good idea. If you are going to post a reply to >> this point, make sure you have read RFC 2026. >> >> 2) I am interested in the specifics of problems that ICE fails to >> solve that the WG has not previous considered. There are lots of >> people that have implemented versions of it and think it is a good >> idea - if people are having some problems with it, I'd love to hear >> about details of things that are wrong. That it has a lot of messages >> in some use cases has been known for a long time. It used to have far >> more messages - engineering was done to consider what was a >> reasonable amount for call set up times and a new design was done to >> bring the message to a level most people invovled with the design >> felt was reasonable. If there are specific other than these that are >> wrong and not considered in the design, now would be a good time to >> get them on the table. >> >> 3) If people think that Skype for example has a simpler solution that >> works better than ICE. Feel free to describe exactly what it is. >> Several people invovled with the ICE design have looked in extreme >> detail at Skype and others and so far none of them have come back >> with what we should do different than ICE. >> >> 4) ICE can be used in a mode where it only provided the reflexive >> candidate. People were pretty clear that this was far inferior to the >> modes where there are other candidates. If someone would like to >> provide exactly how hole punching works better than this very limited >> ICE technique, I'd be glad to hear the details. This has certainly >> been an topic that any could have brought up over the last several >> years. If someone has specifics, I suggest they get out a full >> proposal really soon. I am very doubtful that hole punching solution >> is fundamentally different than the type of hole punching ICE does. >> >> 5) Some people have suggested that if all NATs were behave complaint, >> then we would not need ICE. I strongly disagree. I think the only >> part of ICE we would not need is the TURN relays which are more or >> less an optional part. Again, specifics on what can be removed are >> welcome. >> >> ICE is far more complicated that anyone wants - the problem is, no >> one has come up with a proposal that looks like it comes anywhere >> close to meeting the requirements and if simpler. The design space >> has been extensively explored by many people. The raw data to >> understand what will work on what NATs have been painfully tested and >> documented in publications such as: >> >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf >> >> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt >> >> https://www.guha.cc/saikat/stunt-results.php? >> >> (Ford used to have a page too but it seems to be gone) >> >> I have a very open mind to considering better ways to do ICE - but I >> need specific suggestions or it is impossible for me to really think >> about if the suggestions represent a better path or not. >> >> I would love to see more open source ICE code (there is lots already) >> - I feel that this is an area where ICE is likely just table stakes >> and owning an proprietary ICE stack will not turn out to be a >> competitive advantage. Having open source implementations where the >> development cost was shared and everyone could get working products >> to market faster would be an advantage to companies. Clearly I expect >> the bulk of ICE implementations to not be open source but I still >> would be keen on doing what I can to contribute to an open source >> version as personally I feel that is in the interest of end users, my >> employer, and the IETF as a SDO. >> >> Cullen >> >> >> >> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: >> >>> >>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: >>> >>>> Henry Sinnreich skrev: >>>>> Following some discussions and soul searching, the best =20 >>>>> approach for >>>>> ICE-17 for LC would be to _go ahead and make it an experimental >>>>> RFC_. >>>>> This would support the development of interoperable >>>>> implementations, the >>>>> collection of deployment data and also hopefully open source code. >>>>> Though I have full faith in ICE, following the practices that >>>>> made the >>>>> IETF successful take precedent here, I believe. >>>>> This is a change from the attached that I wrote on 7/16/2007. >>>>> Note: We can only hope the proliferation of SBC in VoIP service >>>>> provider >>>>> networks will not make these concerns and ICE for SIP a moot >>>>> issue, but >>>>> this is another topic. >>>> >>>> Henry, >>>> >>>> I don't quite understand why you are requesting a status change of >>>> ICE? To me it appears that ICE is almost finished spec. It has >>>> been implemented, used and feedback has been influencing the >>>> protocol. It is definitly one of the better examples of current >>>> IETF work that actually has running code. Sure, the >>>> implementations may not be fully updated yet to the latest draft >>>> version. But I think it is safe to say that ICE works in the >>>> intended core cases. If there are some corner cases where it >>>> fails, that may be. But that is not information we will have until >>>> really large scale deployement or someone makes very extensive =20 >>>> tests. >>> >>> Henry has, I believe, been very consistent in urging the IETF to >>> have more "running code" experience on every specification (not >>> just ICE) than our process requires. He has, IIRC, also advocated >>> changing the process to require running code before publishing an >>> RFC. He's even suggested at times that one should have running code >>> before submitting a protocol draft. >>> >>> Another point to consider -- I've known Henry to bark at a tree >>> with no squirrel in it occasionally, but most of the time he's >>> pretty reliable, more so than most technology predictors. If he's >>> worried about ICE, it's probably because he's been talking to >>> people who are trying to implement it and they're telling him it is >>> difficult or that they're having performance or reliability issues. >>> I imagine that there are plenty of internal development teams in >>> various companies that are working on this and not necessarily >>> bringing their results back to the IETF. After all, if everybody >>> sees the emperor as fully clothed, they'd be embarrassed to >>> proclaim otherwise. Of course, I wish all of these developers were >>> tied into the IETF, but then I'm sure I don't want to see every ice- >>> implementor's question on the SIP list. That is why we have a sip- >>> implementors mailing list, right? >>> >>> Personally, I think ICE is the best solution we have. We KNOW of >>> cases where hole-punching doesn't work, and I think ICE will >>> produce usable results in most of those cases. But that's just my >>> personal opinion from reading the specs. I haven't implemented ICE, >>> and I haven't used anybody else's implementation. Sure, it's >>> complex, but that's because the underlying problem is complex -- >>> there are just too many different behaviors out there in "NAT and >>> firewall land". Of course, I could be wrong, too. It's happened >>> before, once or twice ;-). Just how sure are we that we're right >>> about this? >>> >>> Are we designing a "spruce goose" or a practical system? Only >>> experience will tell us. But some good flight reports from the >>> prototypes could go a long way towards reassuring us of the >>> design's utility. >>> >>> So far we've had a couple of people report hearsay evidence -- that >>> somebody else has an ICE implementation and it works. Any of you >>> folks have personal experience you can share? Have there been >>> prototypes exercised at the interop events? >>> >>> -- >>> Dean >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 20 13:46: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 1IBwYO-0005rL-Ne; Fri, 20 Jul 2007 13:46:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBwYM-0005lm-MO for behave-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 13:46:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwYM-0005id-7s for behave@ietf.org; Fri, 20 Jul 2007 13:46:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBwYL-0008EY-JX for behave@ietf.org; Fri, 20 Jul 2007 13:46:10 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 01B9220BFA for ; Fri, 20 Jul 2007 19:46:09 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-93-46a0f4e0f52e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E675A20051 for ; Fri, 20 Jul 2007 19:46:08 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 19:46:08 +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: Fri, 20 Jul 2007 19:46:08 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C7B7@esealmw113.eemea.ericsson.se> In-Reply-To: <011201c7ca62$7b5740b0$fc736b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question for clarification regarding new definition of STUN usage Thread-Index: AcfJ4FF335DVsGelSLSU83g5p3EDXQAgf0zQACHJeyA= References: <011201c7ca62$7b5740b0$fc736b80@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 20 Jul 2007 17:46:08.0591 (UTC) FILETIME=[DA8E5DF0:01C7CAF5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [BEHAVE] Question for clarification regarding new definition of STUN usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, Due to other tasks, I've been out of the 3489bis loop for a while, so my intention is NOT to question decissions that have been made - simply to give some questions for clarification based on those decissions. Now, if I remember correctly, we used to define "STUN usage" as some function that STUN was used to perform, for example keep-alive. Now, however, "STUN usage" is defined as an external mechanism (for example ICE) that uses STUN for different tasks, and that external mechanism must define how STUN is used to perform different task (which headers to use etc).=20 For example, it is not possible to say "this mechanism uses STUN for keep-alive, as defined in 3489bis", but "this mechanism uses STUN for keep-alive, and that is done using this header, that header blah blah blah". Now, the questions: 1. Since every mechanism which uses STUN must describe how it's done, does it mean that in theory that means mechanism X and mechanism Y could use STUN in different ways for performing an identical task (for example keep-alive)? (Of course, mechanism Y could always refer to mechanism X, but that's another issue) 2. Follow-up on previous question: if a non-IETF SDO defines a "STUN usage", I assume they would also, for the different STUN functions, need to describe which STUN headers are used etc (the can not say "this mechanism uses STUN for keep-alive, as defined in 3489bis" either)? For example, let say that SDO-XX wants to use STUN for example simply to retrieve the mapped address. There is no existing STUN usage that can be referred to (at least it's not ICE, and it's not Outbound), so SDO-XX would have to describe themselves which STUN headers to use etc. (NOTE: The purpose is not to discuss the details and usefullness of the example) Regards, Christer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 20 14:22: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 1IBx7R-0000qo-U5; Fri, 20 Jul 2007 14:22:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBx7Q-0000in-JP for behave-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 14:22:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx7Q-0000gH-8Z for behave@ietf.org; Fri, 20 Jul 2007 14:22:24 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBx7P-0004ia-H8 for behave@ietf.org; Fri, 20 Jul 2007 14:22:24 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6KIMJFs026753; Fri, 20 Jul 2007 14:22:19 -0400 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] STUN relay with push mode QoS reservation Date: Fri, 20 Jul 2007 14:22:19 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E71880AB@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188042@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN relay with push mode QoS reservation Thread-Index: AcfCZAO7A1/ZbloTTE2atfpP5sNV+wAALusAAiMJvVA= References: <033458F56EC2A64E8D2D7B759FA3E7E7188028@sonusmail04.sonusnet.com><113801c7c008$3745ef70$e171150a@amer.cisco.com><033458F56EC2A64E8D2D7B759FA3E7E718803D@sonusmail04.sonusnet.com><46928635.5080209@cisco.com><033458F56EC2A64E8D2D7B759FA3E7E718803F@sonusmail04.sonusnet.com><46929436.4000107@cisco.com> <033458F56EC2A64E8D2D7B759FA3E7E7188042@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "Jonathan Rosenberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 AFAICS and helps if NAT is between UA and access endpoint, e.g. a cable modem. Is there anything else, which would help for the following case: UA ------Access Endpoint--- Access Termination--NAT-----STUN ^ (enforces QoS) ^ Relay | | | | What is needed rel-addr for QoS reservation rel-port or for the following: UA---NAT----Access Endpoint--- Access Termination--NAT-----STUN ^ (enforces QoS) ^ Relay | | | | What is needed rel-addr for QoS reservation rel-port Thanks, Tolga > -----Original Message----- > From: Asveren, Tolga > Sent: Monday, July 09, 2007 4:10 PM > To: Jonathan Rosenberg > Cc: behave@ietf.org; Dan Wing > Subject: RE: [BEHAVE] STUN relay with push mode QoS reservation >=20 > > > > >>> and : convey transport addresses related > to > > > the > > >>> candidate, useful for diagnostics and other purposes. > > > > > >>> and MUST be present for server reflexive, peer > > >>> reflexive and relayed candidates. If a candidate is server > or > > >>> peer reflexive, and is equal to the > base > > > for > > >>> that server or peer reflexive candidate. If the candidate > is > > >>> relayed, and is equal to the mapped > > > address > > >>> in the Allocate Response that provided the client with that > > >>> relayed candidate (see Appendix B.3 for a discussion of its > > >>> purpose). If the candidate is a host candidate > and > > >>> MUST be omitted. > > >> > > >> This server reflexive related-address is exactly what you'd use in > > > push > > >> mode QoS. > > > [TOLGA]Yes, it is one of the addresses needed (the internal remote > > > transport address). AFAICS, the other address needed is internal > local > > > transport address of STUN relay. What I was wondering was how > internal > > > local transport address is signaled to the proxy. > > > > I'm not sure which address you mean. For packets forwarded from the > TURN > > server, towards the client, the destination address is the > > server-reflexive address towards the TURN server, laerned as above. > THe > > source address is the IP/port of the TURN server itself. Is it that > one > > you are talking about? That one is not signaled. I don't see why you > > need it though. > [TOLGA]Yes it was the address I was talking about but you are right that > it is actually not needed. We are dealing with a NAT whose mapping > depends on address/address port in this case. Just specifying the server > reflexive address for the QoS filtering rule should be enough to define > the flow unambiguously. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 20 14:58: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 1IBxg0-0004zd-8x; Fri, 20 Jul 2007 14:58:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IBxfz-0004zQ-BR for behave-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 14:58:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxfy-0004zD-Lf for behave@ietf.org; Fri, 20 Jul 2007 14:58:07 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBxfx-0005Yl-CK for behave@ietf.org; Fri, 20 Jul 2007 14:58:06 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBxfw-00007D-2Z; Fri, 20 Jul 2007 14:58:04 -0400 In-Reply-To: <7374777208BDC7449D5620EF942325670743C7B7@esealmw113.eemea.ericsson.se> References: <011201c7ca62$7b5740b0$fc736b80@amer.cisco.com> <7374777208BDC7449D5620EF942325670743C7B7@esealmw113.eemea.ericsson.se> 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] Question for clarification regarding new definition of STUN usage Date: Fri, 20 Jul 2007 14:58:15 -0400 To: Christer Holmberg (JO/LMF) X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 20-Jul-07, at 13:46 , Christer Holmberg (JO/LMF) wrote: > > Hi, > > Due to other tasks, I've been out of the 3489bis loop for a while, > so my > intention is NOT to question decissions that have been made - > simply to > give some questions for clarification based on those decissions. > > Now, if I remember correctly, we used to define "STUN usage" as some > function that STUN was used to perform, for example keep-alive. Now, > however, "STUN usage" is defined as an external mechanism (for example > ICE) that uses STUN for different tasks, and that external mechanism > must define how STUN is used to perform different task (which > headers to > use etc). > > For example, it is not possible to say "this mechanism uses STUN for > keep-alive, as defined in 3489bis", but "this mechanism uses STUN for > keep-alive, and that is done using this header, that header blah blah > blah". > > Now, the questions: > > 1. Since every mechanism which uses STUN must describe how it's done, > does it mean that in theory that means mechanism X and mechanism Y > could > use STUN in different ways for performing an identical task (for > example > keep-alive)? > > (Of course, mechanism Y could always refer to mechanism X, but that's > another issue) Your "mechanism" is what 3489bis-07 calls a "usage". A "mechanism" in 3489bis-07 is a reusable extension to the protocol. There are a number of "mechanisms" defined in 3489bis-07 that usages can use. So yes, if another usage of STUN were to come along, then it would have to define exactly how to use STUN. It could use the binding method and any mechanisms defined in 3489bis-07, but if it wants something new, it must define it. Regarding NAT Keepalives, one can use either Binding Request/Reply transactions or Binding Indications (Outbound uses the former, while ICE uses the latter). Most of the details for how to do this are defined in 34890bis-07. If a new usage comes along that wants to use STUN in this way, then there is not much it has to do. > > 2. Follow-up on previous question: if a non-IETF SDO defines a "STUN > usage", I assume they would also, for the different STUN functions, > need > to describe which STUN headers are used etc (the can not say "this > mechanism uses STUN for keep-alive, as defined in 3489bis" either)? > > For example, let say that SDO-XX wants to use STUN for example > simply to > retrieve the mapped address. There is no existing STUN usage that > can be > referred to (at least it's not ICE, and it's not Outbound), so SDO-XX > would have to describe themselves which STUN headers to use etc. Yes and no. The Binding method is defined in 3489bis-07, and this is most of what is needed. The main thing this new usage would have to do is consider the security implications of using STUN. If it is doing "classic STUN", then it would need to say why it is not worried about the security problems of using STUN in this way. Hope this helps. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 20 22:28: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 1IC4he-0003Nb-JB; Fri, 20 Jul 2007 22:28:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IC4hd-0003Mc-4j for behave-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 22:28:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC4hc-0003Jo-Mj for behave@ietf.org; Fri, 20 Jul 2007 22:28:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC4hb-0007qq-RH for behave@ietf.org; Fri, 20 Jul 2007 22:28:16 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2007 19:28:15 -0700 X-IronPort-AV: i="unknown"; a="185987825:sNHT0" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6L2SFSg008792; Fri, 20 Jul 2007 19:28:15 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6L2SA6C017737; Sat, 21 Jul 2007 02:28:10 GMT From: "Dan Wing" To: "'Asveren, Tolga'" Subject: RE: [BEHAVE] STUN relay with push mode QoS reservation Date: Fri, 20 Jul 2007 19:28:09 -0700 Message-ID: <00a801c7cb3e$ca605430$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E71880AB@sonusmail04.sonusnet.com> Thread-Index: AcfCZAO7A1/ZbloTTE2atfpP5sNV+wAALusAAiMJvVAAExgTEA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5479; t=1184984895; x=1185848895; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20STUN=20relay=20with=20push=20mode=20QoS=20 reservation |Sender:=20; bh=uYyNWOSfLTPfshpbmWepUUVodG6EX/GdmxU33b2DKG8=; b=sT3Hn/KMGGnnL51jJvJGIodhzZBjSyGIwD6AuHD4xW99/k9sF0MwyK2WdGdkOZxBuHVMNub8 jmRLfkkQnAgoxCBlIbHmuDwTyTMdz/FODptQ2RJzh4RDYaI90TRmBRlK5ApMEhM/aRnH44RJDg YBHQv9NCIkoTDJCbJZbhJsvx0=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Friday, July 20, 2007 11:22 AM > To: Jonathan Rosenberg; behave@ietf.org > Subject: RE: [BEHAVE] STUN relay with push mode QoS reservation > > > AFAICS and helps if NAT is between UA and access > endpoint, e.g. a cable modem. Is there anything else, which would help > for the following case: > > > UA ------Access Endpoint--- Access Termination--NAT-----STUN > ^ (enforces QoS) ^ Relay > | | > | | > What is needed rel-addr > for QoS reservation rel-port For that, I believe you want to indicate the 'base' in the SDP; there isn't a mechanism to do that in ICE-17. At least, in this situation, the UA does have all the information necessary. > or for the following: > > > UA---NAT----Access Endpoint--- Access Termination--NAT-----STUN > ^ (enforces QoS) ^ Relay > | | > | | > What is needed rel-addr > for QoS reservation rel-port ICE-17 doesn't have a way to indicate that, either. However, in this situation, there is a more difficult problem: how would the UA learn the IP address and UDP port being used by that first NAT (the NAT closest to the UA). The UA could could be learned via UPnP or Bonjour; however, if you throw another NAT into the diagram, that won't work, either: UA--NAT--NAT--Access Endpoint--- Access Termination--NAT---STUN 1 2 ^ (enforces QoS) ^ Relay | | | | What is needed rel-addr for QoS reservation rel-port In the diagram above, UPnP or Bonjour on NAT-1 will only help you learn the public address and UDP port on NAT-1; but you need to learn the public address and UDP port on NAT-2. UPnP and Bonjour don't help (as neither work across NATs). If the outer-most NAT (the one closest to the STUN relay in the figures above) were to support draft-wing-behave-nat-control-stun-usage, then the UA could query that outer-most NAT and learn the IP address and UDP port that you need to communicate. Alternatively, you could declare such nested NATs as 'too hard' and skip that problem, and just stick with the diagram you had in your email, and use UPnP or Bonjour to learn the public IP address and UDP port. -d > > Thanks, > Tolga > > > -----Original Message----- > > From: Asveren, Tolga > > Sent: Monday, July 09, 2007 4:10 PM > > To: Jonathan Rosenberg > > Cc: behave@ietf.org; Dan Wing > > Subject: RE: [BEHAVE] STUN relay with push mode QoS reservation > > > > > > > > >>> and : convey transport > addresses related > > to > > > > the > > > >>> candidate, useful for diagnostics and other purposes. > > > > > > > >>> and MUST be present for server > reflexive, peer > > > >>> reflexive and relayed candidates. If a candidate is > server > > or > > > >>> peer reflexive, and is > equal to the > > base > > > > for > > > >>> that server or peer reflexive candidate. If > the candidate > > is > > > >>> relayed, and is equal to > the mapped > > > > address > > > >>> in the Allocate Response that provided the client with > that > > > >>> relayed candidate (see Appendix B.3 for a discussion of > its > > > >>> purpose). If the candidate is a host candidate > > > and > > > >>> MUST be omitted. > > > >> > > > >> This server reflexive related-address is exactly what you'd use > in > > > > push > > > >> mode QoS. > > > > [TOLGA]Yes, it is one of the addresses needed (the > internal remote > > > > transport address). AFAICS, the other address needed is internal > > local > > > > transport address of STUN relay. What I was wondering was how > > internal > > > > local transport address is signaled to the proxy. > > > > > > I'm not sure which address you mean. For packets > forwarded from the > > TURN > > > server, towards the client, the destination address is the > > > server-reflexive address towards the TURN server, laerned > as above. > > THe > > > source address is the IP/port of the TURN server itself. > Is it that > > one > > > you are talking about? That one is not signaled. I don't > see why you > > > need it though. > > [TOLGA]Yes it was the address I was talking about but you are right > that > > it is actually not needed. We are dealing with a NAT whose mapping > > depends on address/address port in this case. Just specifying the > server > > reflexive address for the QoS filtering rule should be enough to > define > > the flow unambiguously. > > > _______________________________________________ > 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 Sat Jul 21 14:51: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 1ICK2q-0004TW-PT; Sat, 21 Jul 2007 14:51:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ICK2p-0004TD-86 for behave-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 14:51:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICK2o-0004T2-Su for behave@ietf.org; Sat, 21 Jul 2007 14:51:10 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICK2o-0000sq-4W for behave@ietf.org; Sat, 21 Jul 2007 14:51:10 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 90DCF206E7; Sat, 21 Jul 2007 20:51:09 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-13-46a2559d829b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6594C20550; Sat, 21 Jul 2007 20:51:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 20:51:08 +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 Subject: RE: [BEHAVE] Question for clarification regarding new definition of STUN usage Date: Sat, 21 Jul 2007 20:51:06 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C923@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Question for clarification regarding new definition of STUN usage Thread-Index: AcfK/+goH/+EMS21Qp+5J0fXn4Uf2gAiWGfg References: <011201c7ca62$7b5740b0$fc736b80@amer.cisco.com> <7374777208BDC7449D5620EF942325670743C7B7@esealmw113.eemea.ericsson.se> From: "Christer Holmberg (JO/LMF)" To: "Philip Matthews" X-OriginalArrivalTime: 21 Jul 2007 18:51:08.0839 (UTC) FILETIME=[19B2BB70:01C7CBC8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Philip, >>Due to other tasks, I've been out of the 3489bis loop for a while, so=20 >>my intention is NOT to question decissions that have been made -=20 >>simply to give some questions for clarification based on those=20 >>decissions. >> >>Now, if I remember correctly, we used to define "STUN usage" as some=20 >>function that STUN was used to perform, for example keep-alive. Now,=20 >>however, "STUN usage" is defined as an external mechanism (for example >>ICE) that uses STUN for different tasks, and that external mechanism=20 >>must define how STUN is used to perform different task (which headers=20 >>to use etc). >> >>For example, it is not possible to say "this mechanism uses STUN for=20 >>keep-alive, as defined in 3489bis", but "this mechanism uses STUN for=20 >>keep-alive, and that is done using this header, that header blah blah=20 >>blah". >> >>Now, the questions: >> >>1. Since every mechanism which uses STUN must describe how it's done,=20 >>does it mean that in theory that means mechanism X and mechanism Y=20 >>could use STUN in different ways for performing an identical task (for >>example keep-alive)? >> >>(Of course, mechanism Y could always refer to mechanism X, but that's=20 >>another issue) >=20 >Your "mechanism" is what 3489bis-07 calls a "usage". Yes. Y could be ICE and X something else. >A "mechanism" in 3489bis-07 is a reusable extension to the protocol. >There are a number of "mechanisms" defined in 3489bis-07 that=20 >usages can use. Yes. =20 >So yes, if another usage of STUN were to come along, then it=20 >would have to define exactly how to use STUN. It could use=20 >the binding method and any mechanisms defined in 3489bis-07,=20 >but if it wants something new, it must define it. > >=20 >Regarding NAT Keepalives, one can use either Binding=20 >Request/Reply transactions or Binding Indications (Outbound=20 >uses the former, while ICE uses the latter). >Most of the details for how to do this are defined in 34890bis-07. >If a new usage comes along that wants to use STUN in this=20 >way, then there is not much it has to do. In real life, probably not.=20 But, still, the new usage must still describe when the STUN messages are sent etc, as required in chapter 13. And, the 2nd paragraph of chapter 13, maybe it then would be good to say: "three STUN usages are defined in IETF".=20 =20 >>2. Follow-up on previous question: if a non-IETF SDO defines a "STUN=20 >>usage", I assume they would also, for the different STUN functions,=20 >>need to describe which STUN headers are used etc (the can not say=20 >>"this mechanism uses STUN for keep-alive, as defined in 3489bis"=20 >>either)? >> >>For example, let say that SDO-XX wants to use STUN for example simply=20 >>to retrieve the mapped address. There is no existing STUN usage that=20 >>can be referred to (at least it's not ICE, and it's not Outbound), so=20 >>SDO-XX would have to describe themselves which STUN headers to use=20 >>etc. >=20 >Yes and no. >The Binding method is defined in 3489bis-07, and this is most=20 >of what is needed. Correct, but the SDO would still need to describe when the STUN messages are sent, etc, as required in chapter 13. >The main thing this new usage would have to do is consider=20 >the security implications of using STUN. If it is doing=20 >"classic STUN", then it would need to say why it is not=20 >worried about the security problems of using STUN in this way. Well, it's difficult to say what other SDOs are going to do, but I guess we just have to trust them :) >Hope this helps. Yes. Thank you! In addition, a small editorial issue (I appologize if someone has already mentioned it): At the end of the 3rd paragraph chapter 1 I guess it should say "is a usage of STUN" - not "is a usage of ICE". Regards, Christer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jul 21 17:32: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 1ICMYx-0002Wv-6H; Sat, 21 Jul 2007 17:32:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ICMYw-0002Wq-Ac for behave-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 17:32:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICMYw-0002Wi-17 for behave@ietf.org; Sat, 21 Jul 2007 17:32:30 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICMYu-0000zs-OF for behave@ietf.org; Sat, 21 Jul 2007 17:32:29 -0400 Received: from [67.97.210.2] (helo=[172.28.170.96]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ICMYt-00048k-27; Sat, 21 Jul 2007 17:32:27 -0400 In-Reply-To: <7374777208BDC7449D5620EF942325670743C923@esealmw113.eemea.ericsson.se> References: <011201c7ca62$7b5740b0$fc736b80@amer.cisco.com> <7374777208BDC7449D5620EF942325670743C7B7@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C923@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A9C8699-46A3-4719-A511-621337D4D41F@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] Question for clarification regarding new definition of STUN usage Date: Sat, 21 Jul 2007 17:32:47 -0400 To: Christer Holmberg (JO/LMF) X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([172.28.170.96]) [67.97.210.2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 Thanks for the typos and suggested corrections. If one just wants to use STUN for a keep-alive mechanism, then the text should be pretty lightweight. Certainly, we are hoping for something very lightweight for Outbound. - Philip On 21-Jul-07, at 14:51 , Christer Holmberg (JO/LMF) wrote: > > Hi Philip, > >>> Due to other tasks, I've been out of the 3489bis loop for a >>> while, so >>> my intention is NOT to question decissions that have been made - >>> simply to give some questions for clarification based on those >>> decissions. >>> >>> Now, if I remember correctly, we used to define "STUN usage" as some >>> function that STUN was used to perform, for example keep-alive. Now, >>> however, "STUN usage" is defined as an external mechanism (for >>> example >>> ICE) that uses STUN for different tasks, and that external mechanism >>> must define how STUN is used to perform different task (which >>> headers >>> to use etc). >>> >>> For example, it is not possible to say "this mechanism uses STUN for >>> keep-alive, as defined in 3489bis", but "this mechanism uses STUN >>> for >>> keep-alive, and that is done using this header, that header blah >>> blah >>> blah". >>> >>> Now, the questions: >>> >>> 1. Since every mechanism which uses STUN must describe how it's >>> done, >>> does it mean that in theory that means mechanism X and mechanism Y >>> could use STUN in different ways for performing an identical task >>> (for > >>> example keep-alive)? >>> >>> (Of course, mechanism Y could always refer to mechanism X, but >>> that's >>> another issue) >> >> Your "mechanism" is what 3489bis-07 calls a "usage". > > Yes. Y could be ICE and X something else. > >> A "mechanism" in 3489bis-07 is a reusable extension to the protocol. >> There are a number of "mechanisms" defined in 3489bis-07 that >> usages can use. > > Yes. > >> So yes, if another usage of STUN were to come along, then it >> would have to define exactly how to use STUN. It could use >> the binding method and any mechanisms defined in 3489bis-07, >> but if it wants something new, it must define it. >> >> >> Regarding NAT Keepalives, one can use either Binding >> Request/Reply transactions or Binding Indications (Outbound >> uses the former, while ICE uses the latter). >> Most of the details for how to do this are defined in 34890bis-07. >> If a new usage comes along that wants to use STUN in this >> way, then there is not much it has to do. > > In real life, probably not. > > But, still, the new usage must still describe when the STUN > messages are > sent etc, as required in chapter 13. > > And, the 2nd paragraph of chapter 13, maybe it then would be good to > say: "three STUN usages are defined in IETF". > > >>> 2. Follow-up on previous question: if a non-IETF SDO defines a "STUN >>> usage", I assume they would also, for the different STUN functions, >>> need to describe which STUN headers are used etc (the can not say >>> "this mechanism uses STUN for keep-alive, as defined in 3489bis" >>> either)? >>> >>> For example, let say that SDO-XX wants to use STUN for example >>> simply >>> to retrieve the mapped address. There is no existing STUN usage that >>> can be referred to (at least it's not ICE, and it's not >>> Outbound), so >>> SDO-XX would have to describe themselves which STUN headers to use >>> etc. >> >> Yes and no. >> The Binding method is defined in 3489bis-07, and this is most >> of what is needed. > > Correct, but the SDO would still need to describe when the STUN > messages > are sent, etc, as required in chapter 13. > >> The main thing this new usage would have to do is consider >> the security implications of using STUN. If it is doing >> "classic STUN", then it would need to say why it is not >> worried about the security problems of using STUN in this way. > > Well, it's difficult to say what other SDOs are going to do, but I > guess > we just have to trust them :) > >> Hope this helps. > > Yes. Thank you! > > In addition, a small editorial issue (I appologize if someone has > already mentioned it): At the end of the 3rd paragraph chapter 1 I > guess > it should say "is a usage of STUN" - not "is a usage of ICE". > > Regards, > > Christer > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jul 22 02:57: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 1ICVNH-0001tM-Tj; Sun, 22 Jul 2007 02:57:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ICVNH-0001tE-7Q for behave-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 02:57:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICVND-0001su-Fw for behave@ietf.org; Sun, 22 Jul 2007 02:56:59 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICVNC-0006y9-J9 for behave@ietf.org; Sun, 22 Jul 2007 02:56:59 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 031CC203D1; Sun, 22 Jul 2007 08:56:53 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-46-46a2ffb4ee69 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DADB520068; Sun, 22 Jul 2007 08:56:52 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 08:56:52 +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 Subject: RE: [BEHAVE] Question for clarification regarding new definition of STUN usage Date: Sun, 22 Jul 2007 08:56:49 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C977@esealmw113.eemea.ericsson.se> In-Reply-To: <8A9C8699-46A3-4719-A511-621337D4D41F@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Question for clarification regarding new definition of STUN usage Thread-Index: AcfL3qVM79/PTwW5QoCb3BcjES9D/gATltIg References: <011201c7ca62$7b5740b0$fc736b80@amer.cisco.com> <7374777208BDC7449D5620EF942325670743C7B7@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C923@esealmw113.eemea.ericsson.se> <8A9C8699-46A3-4719-A511-621337D4D41F@magma.ca> From: "Christer Holmberg (JO/LMF)" To: "Philip Matthews" X-OriginalArrivalTime: 22 Jul 2007 06:56:52.0631 (UTC) FILETIME=[7BD21A70:01C7CC2D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi,=20 >Thanks for the typos and suggested corrections. >=20 >If one just wants to use STUN for a keep-alive mechanism,=20 >then the text should be pretty lightweight. Certainly, we are=20 >hoping for something very lightweight for Outbound. My personal assumption is that someone could want to use STUN simply to gather the mapped address, and possibly also use it for keep-alive. That is a much "lighter" usage than ICE (but of course it does not provide all the features that ICE does). Regards, Christer >=20 > - Philip >=20 > On 21-Jul-07, at 14:51 , Christer Holmberg (JO/LMF) wrote: >=20 > > > > Hi Philip, > > > >>> Due to other tasks, I've been out of the 3489bis loop for=20 > a while,=20 > >>> so my intention is NOT to question decissions that have=20 > been made -=20 > >>> simply to give some questions for clarification based on those=20 > >>> decissions. > >>> > >>> Now, if I remember correctly, we used to define "STUN=20 > usage" as some=20 > >>> function that STUN was used to perform, for example=20 > keep-alive. Now,=20 > >>> however, "STUN usage" is defined as an external mechanism (for=20 > >>> example > >>> ICE) that uses STUN for different tasks, and that=20 > external mechanism=20 > >>> must define how STUN is used to perform different task (which=20 > >>> headers to use etc). > >>> > >>> For example, it is not possible to say "this mechanism=20 > uses STUN for=20 > >>> keep-alive, as defined in 3489bis", but "this mechanism uses STUN=20 > >>> for keep-alive, and that is done using this header, that=20 > header blah=20 > >>> blah blah". > >>> > >>> Now, the questions: > >>> > >>> 1. Since every mechanism which uses STUN must describe how it's=20 > >>> done, does it mean that in theory that means mechanism X and=20 > >>> mechanism Y could use STUN in different ways for performing an=20 > >>> identical task (for > > > >>> example keep-alive)? > >>> > >>> (Of course, mechanism Y could always refer to mechanism X, but=20 > >>> that's another issue) > >> > >> Your "mechanism" is what 3489bis-07 calls a "usage". > > > > Yes. Y could be ICE and X something else. > > > >> A "mechanism" in 3489bis-07 is a reusable extension to the=20 > protocol. > >> There are a number of "mechanisms" defined in 3489bis-07=20 > that usages=20 > >> can use. > > > > Yes. > > > >> So yes, if another usage of STUN were to come along, then it would=20 > >> have to define exactly how to use STUN. It could use the binding=20 > >> method and any mechanisms defined in 3489bis-07, but if it wants=20 > >> something new, it must define it. > >> > >> > >> Regarding NAT Keepalives, one can use either Binding Request/Reply=20 > >> transactions or Binding Indications (Outbound uses the=20 > former, while=20 > >> ICE uses the latter). > >> Most of the details for how to do this are defined in 34890bis-07. > >> If a new usage comes along that wants to use STUN in this=20 > way, then=20 > >> there is not much it has to do. > > > > In real life, probably not. > > > > But, still, the new usage must still describe when the STUN=20 > messages=20 > > are sent etc, as required in chapter 13. > > > > And, the 2nd paragraph of chapter 13, maybe it then would be good to > > say: "three STUN usages are defined in IETF". > > > > > >>> 2. Follow-up on previous question: if a non-IETF SDO=20 > defines a "STUN=20 > >>> usage", I assume they would also, for the different STUN=20 > functions,=20 > >>> need to describe which STUN headers are used etc (the can not say=20 > >>> "this mechanism uses STUN for keep-alive, as defined in 3489bis" > >>> either)? > >>> > >>> For example, let say that SDO-XX wants to use STUN for example=20 > >>> simply to retrieve the mapped address. There is no existing STUN=20 > >>> usage that can be referred to (at least it's not ICE, and=20 > it's not=20 > >>> Outbound), so SDO-XX would have to describe themselves which STUN=20 > >>> headers to use etc. > >> > >> Yes and no. > >> The Binding method is defined in 3489bis-07, and this is=20 > most of what=20 > >> is needed. > > > > Correct, but the SDO would still need to describe when the STUN=20 > > messages are sent, etc, as required in chapter 13. > > > >> The main thing this new usage would have to do is consider the=20 > >> security implications of using STUN. If it is doing=20 > "classic STUN",=20 > >> then it would need to say why it is not worried about the security=20 > >> problems of using STUN in this way. > > > > Well, it's difficult to say what other SDOs are going to do, but I=20 > > guess we just have to trust them :) > > > >> Hope this helps. > > > > Yes. Thank you! > > > > In addition, a small editorial issue (I appologize if someone has=20 > > already mentioned it): At the end of the 3rd paragraph chapter 1 I=20 > > guess it should say "is a usage of STUN" - not "is a usage of ICE". > > > > Regards, > > > > Christer > > > > >=20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jul 22 07:37:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICZkX-0002iv-S2; Sun, 22 Jul 2007 07:37:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ICZkW-0002im-8u for behave-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 07:37:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICZkV-0002ie-QZ for behave@ietf.org; Sun, 22 Jul 2007 07:37:19 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICZkV-0000CK-55 for behave@ietf.org; Sun, 22 Jul 2007 07:37:19 -0400 Received: from [67.97.210.2] (helo=[172.28.168.108]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ICZkV-0000yZ-1Z; Sun, 22 Jul 2007 07:37:19 -0400 In-Reply-To: <7374777208BDC7449D5620EF942325670743C977@esealmw113.eemea.ericsson.se> References: <011201c7ca62$7b5740b0$fc736b80@amer.cisco.com> <7374777208BDC7449D5620EF942325670743C7B7@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C923@esealmw113.eemea.ericsson.se> <8A9C8699-46A3-4719-A511-621337D4D41F@magma.ca> <7374777208BDC7449D5620EF942325670743C977@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8049D792-84AC-4DDE-9DDA-2392CB9CCA8B@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] Question for clarification regarding new definition of STUN usage Date: Sun, 22 Jul 2007 06:36:54 -0500 To: Christer Holmberg (JO/LMF) X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([172.28.168.108]) [67.97.210.2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 22-Jul-07, at 01:56 , Christer Holmberg (JO/LMF) wrote: > My personal assumption is that someone could want to use STUN > simply to > gather the mapped address, and possibly also use it for keep-alive. > That > is a much "lighter" usage than ICE (but of course it does not provide > all the features that ICE does). There are a number of well-known problems that can occur when using STUN in that way. So 3489bis-07 discourages that use. Section 2 says: STUN was originally defined in RFC 3489 [RFC3489]. That specification, sometimes referred to as "classic STUN", represented itself as a complete solution to the NAT traversal problem. In that solution, a client would discover whether it was behind a NAT, determine its NAT type, discover its IP address and port on the public side of the outermost NAT, and then utilize that IP address and port within the body of protocols, such as the Session Initiation Protocol (SIP) [RFC3261]. However, experience since the publication of RFC 3489 has found that classic STUN simply does not work sufficiently well to be a deployable solution. The address and port learned through classic STUN are sometimes usable for communications with a peer, and sometimes not. Classic STUN provided no way to discover whether it would, in fact, work or not, and it provided no remedy in cases where it did not. Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there. Classic STUN also had security vulnerabilities which required an extremely complicated mechanism to address, and despite the complexity of the mechanism, were not fully remedied. So to use STUN "officially" in that manner, you need to consider these potential problems and describe why they are not a concern in your particular usage. This was one of the motivations for moving to this new definition of usage. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 23 15:56:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID40p-0000zX-08; Mon, 23 Jul 2007 15:56:11 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ID40m-0000tO-GA for behave-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 15:56:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID40m-0000t9-2B; Mon, 23 Jul 2007 15:56:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID40l-0000LV-JA; Mon, 23 Jul 2007 15:56:07 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 15:56:07 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACalpEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="126801974:sNHT29190148" 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 l6NJu6Zx023742; Mon, 23 Jul 2007 15:56:06 -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 l6NJtvWs017987; Mon, 23 Jul 2007 19:56:06 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, 23 Jul 2007 15:55:41 -0400 Received: from [10.86.242.144] ([10.86.242.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 15:55:41 -0400 Message-ID: <46A507C5.5060206@cisco.com> Date: Mon, 23 Jul 2007 15:55:49 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 19:55:41.0404 (UTC) FILETIME=[72C0C1C0:01C7CD63] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1840; t=1185220566; x=1186084566; 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:=20ICE=20tutorial=20in=20Chicago=20is=20CONFIRMED=20[DO=20NOT=20 REPLY]=20-=20lunch=20logistics=0A=20below |Sender:=20 |To:=20IETF=20SIP=20List=20, =20IETF=20Sipping=20List=20, =0A=20=20=20=20=20=20=20=20IETF=20MMUSIC=20WG=20, =20Behave=20WG=20, =0A=20=20=20=20=20=20=20=20P2PSI P=20WG=20, =20rai@ietf.org, =0A=20=20=20=20=20=20=20=20=22' avt@ietf.org'=22=20; bh=KpxqDxUhtprUSwrX98Ct3c1X0mBsvpY4gzyMN2aH5Go=; b=Ncyw7y256jwE7lC5Q5QuZfDCdjVn1oabrjGvlOL+VyhF0ZalmP15rKSMhRmaAGHHsSvG2PuK zZyuKd5iE8415bdWZIZuxeIGqTOje15E+zSKCePNlEj5RGkZbwjUABDm; 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: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [BEHAVE] ICE tutorial in Chicago is CONFIRMED [DO NOT REPLY] - lunch logistics below X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-17.txt) Slides: http://www.jdrosen.net/papers/ice-ietf-tutorial2.ppt WHEN: Tuesday, July 24, 2007, 1145-1245 lunch will be available to those who RSVPd previously sandwiches, chips, salad and drinks $20/head - please pay Jonathan R. after the tutorial WHERE: Red Lacquar MP3 streaming hopefully available at: http://videolab.uoregon.edu/events/ietf/ietf694.m3u WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Anyone may attend without RSVP, but lunch may not be there for you if you have not RSVPd previously. I've ordered a few extra !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 26 07:12: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 1IE1G9-000570-KA; Thu, 26 Jul 2007 07:11:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IE1G8-00056o-4M for behave-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 07:11:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1G7-00056f-Cm; Thu, 26 Jul 2007 07:11:55 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE1G6-0000wj-7h; Thu, 26 Jul 2007 07:11:55 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 26 Jul 2007 04:11:32 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6QBBOWs010290; Thu, 26 Jul 2007 04:11:29 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6QB9KI9000054; Thu, 26 Jul 2007 04:09:20 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 04:11:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Thu, 26 Jul 2007 04:09:54 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22B3257B@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Thread-Index: AcfPPzs1liu3JIq4Q8W3OVkLR1AeigANWmeA References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> From: "Henry Sinnreich" To: "Adam Fisk" , "Jiri Kuthan" X-OriginalArrivalTime: 26 Jul 2007 11:11:23.0362 (UTC) FILETIME=[B389BC20:01C7CF75] X-Spam-Score: 0.0 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Cc: behave@ietf.org, mmusic@ietf.org, Juha Heinanen , Jan Janak , P2PSIP 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="===============0751955262==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0751955262== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CF75.B153F385" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CF75.B153F385 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This insight may be very useful when designing a test tool for ICE.=20 As I have insisted, we need deployment testing for ICE and continued tweaking to make it real. I have no idea what the deployment testing may reveal and the attached is a welcome example. =20 Is anyone on these lists designing a test tool for NAT scenario discovery and for ICE? =20 Henry =20 ________________________________ From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk Sent: Wednesday, July 25, 2007 11:41 PM To: Jiri Kuthan Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC =20 I had a conversation earlier tonight at the NYC p2p meetup that led me to question my previous assumptions about ICE "working". Supposedly many routers start to do funny things when they see lots of ICE UDP packets flying by and trying lots of candidates.=20 This has me worried. We all know the frightening number of NAT configurations out there. Maybe I missed it, but is there a test matrix somewhere of NAT combinations and their success rates with ICE? If not, could we create one using one of the open source ICE implementations out there (mine's not quite ready)? I'd be happy to contribute my own router if we had a simple test program, maybe based on the work at Nokia.=20 I think performing those simple tests would set everyone's mind at ease. Otherwise, I am concerned that some NAT and firmware combinations would balk at what they see as packet floods. To a person, everyone I've talked to who has implemented this stuff in the "real world" has said the array of problems with specific NAT configurations is much more significant than they realized at first. I think this is the central problem -- the world we're deploying this in is much more chaotic than that of more RFCs, as the BEHAVE group is trying to address.=20 -Adam On 7/24/07, Adam Fisk wrote: I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17. I've implemented what will be open source implementations of STUN and TURN, both client and server. Here are the key points I've taken away from that experience:=20 1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing. 2) ICE is complex as hell and a pain in the ^#* to implement. I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.=20 3) ICE is solving a very tricky problem. I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group. I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it. I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler. In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation. I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write. Simplifications might just be in the description and not necessarily the algorithm.=20 I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback. I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it. That would be a huge hindrance to ICE's adoption and power.=20 -Adam =20 ------_=_NextPart_001_01C7CF75.B153F385 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

This insight may be very useful = when designing a test tool for ICE.

As I have insisted, we need = deployment testing for ICE and continued tweaking to make it = real.

I have no idea what the deployment = testing may reveal and the attached is a welcome = example.

 

Is anyone on these lists designing = a test tool for NAT scenario discovery and for = ICE?

 

Henry

 

From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk
Sent: Wednesday, July 25, = 2007 11:41 PM
To: Jiri Kuthan
Cc: Henry Sinnreich; = David Barrett; Jan Janak; Juha Heinanen; mmusic@ietf.org
Subject: Re: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for = RFC

 

I had a = conversation earlier tonight at the NYC p2p meetup that led me to question my = previous assumptions about ICE "working".  Supposedly many routers = start to do funny things when they see lots of ICE UDP packets flying by and = trying lots of candidates.

This has me worried.  We all know the frightening number of NAT configurations out there.  Maybe I missed it, but is there a test = matrix somewhere of NAT combinations and their success rates with ICE?  If = not, could we create one using one of the open source ICE implementations out = there (mine's not quite ready)?  I'd be happy to contribute my own router = if we had a simple test program, maybe based on the work at Nokia.

I think performing those simple tests would set everyone's mind at = ease.  Otherwise, I am concerned that some NAT and firmware combinations would = balk at what they see as packet floods.

To a person, everyone I've talked to who has implemented this stuff in = the "real world" has said the array of problems with specific NAT configurations is much more significant than they realized at = first.  I think this is the central problem -- the world we're deploying this in = is much more chaotic than that of more RFCs, as the BEHAVE group is trying to = address.

-Adam

On 7/24/07, Adam Fisk <a@lastbamboo.org> wrote:

I've followed = ICE development on the sidelines for years now, and I'm currently = implementing ICE 17.  I've implemented what will be open source implementations of = STUN and TURN, both client and server.  Here are the key points I've taken = away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to = the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I = was surprised at how hard it was, particularly for a draft that's so close = to becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the = "almost done" state like used to happen in the Routing group.  I = realize that's asking a lot given how much work has gone into it and how eager = everyone is to finalize it.  I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make = simpler.  In my implementation of ICE, I do think it could be done more simply, = but I don't have concrete suggestions right now because I'm still pulling my = hair out with the implementation.  I'm not talking about drastic changes = anywhere, but all the checklist fiddling sure takes a lot of patience to = write.  Simplifications might just be in the description and not necessarily the algorithm.

I think it's a hard enough and important enough problem that we owe it = to ourselves to be even more patient with an "almost done" state = that adds the final touches based on real-world feedback.  I don't doubt = for a second that ICE works, but it's so complex that I worry no one outside = huge companies will ever implement it.  That would be a huge hindrance = to ICE's adoption and power.

-Adam

 

------_=_NextPart_001_01C7CF75.B153F385-- --===============0751955262== 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 --===============0751955262==-- From behave-bounces@ietf.org Thu Jul 26 12:19: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 1IE63d-00075t-RL; Thu, 26 Jul 2007 12:19:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IE63c-00075K-TW for behave-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 12:19:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE63c-000759-H3; Thu, 26 Jul 2007 12:19:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE63b-0002lR-B9; Thu, 26 Jul 2007 12:19:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2007 12:19:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANxlqEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175486400"; d="scan'208"; a="127119221:sNHT26802332" 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 l6QGJIaP025436; Thu, 26 Jul 2007 12:19: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 l6QGIsWk003600; Thu, 26 Jul 2007 16:19: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); Thu, 26 Jul 2007 12:19:06 -0400 Received: from [10.86.241.65] ([10.86.241.65]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 12:19:06 -0400 Message-ID: <46A8C983.4060302@cisco.com> Date: Thu, 26 Jul 2007 12:19:15 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 16:19:06.0078 (UTC) FILETIME=[B02C9FE0:01C7CFA0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=740; t=1185466758; x=1186330758; 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:=20ICE=20tutorial=20in=20Chicago=20=20-=20PLEASE=20PAY=20IF=20YO U=20ATE=20LUNCH |Sender:=20 |To:=20IETF=20SIP=20List=20, =20IETF=20Sipping=20List=20, =0A=20=20=20=20=20=20=20=20IETF=20MMUSIC=20WG=20, =20Behave=20WG=20, =0A=20=20=20=20=20=20=20=20P2PSI P=20WG=20, =20rai@ietf.org, =0A=20=20=20=20=20=20=20=20=22' avt@ietf.org'=22=20; bh=Zrtno2xh1JufqqypXQrJG3eaM0QxnaFVcCRKizkJRlU=; b=EAbRlhLzYaOy4oHUNIotoEwBXwvoS8Zp1gyIR9U0ZLbsLNA0SW2PWFoOvExi7DXio14brEfh Ctw1A+j6KiaWFP+lwWplEuOmXoKwNKI3GCkheAO1e18guOsiXHEOunJT; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [BEHAVE] ICE tutorial in Chicago - PLEASE PAY IF YOU ATE LUNCH X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Lunch during the tutorial was paid out of my pocket, and I was expecting to get re-imbursed by everyone that took a sandwich. Though all of the food was taken by the end of the tutorial, I am several hundred dollars short. Please, if you took lunch and did not give me $20, give it to me before you leave, and if you have not, contact me privately and we can arrange for paper mail. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jul 26 14:15: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 1IE7rm-0000In-OR; Thu, 26 Jul 2007 14:15:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IE7rl-0000Ib-Ua for behave-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 14:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7rl-0000IQ-6K; Thu, 26 Jul 2007 14:15:13 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE7rj-0005fX-O8; Thu, 26 Jul 2007 14:15:13 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2007 11:15:10 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMWBqEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="189195896:sNHT91438155" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6QIFA3L015996; Thu, 26 Jul 2007 11:15:10 -0700 Received: from dwingwxp ([10.21.118.134]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6QIF16D025827; Thu, 26 Jul 2007 18:15:02 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'Adam Fisk'" , "'Jiri Kuthan'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Date: Thu, 26 Jul 2007 13:14:35 -0500 Message-ID: <05d701c7cfb0$e71ed620$3015590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22B3257B@namail5.corp.adobe.com> thread-index: AcfPPzs1liu3JIq4Q8W3OVkLR1AeigANWmeAAAqJ3lA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5139; t=1185473710; x=1186337710; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=2 0ICE=20deploymentdatabefore=20LCfor=20RFC |Sender:=20; bh=ykxSheCBcPAaJEACuzGg9KmUWyl5qLkfBJI6uD/fzmY=; b=WGquyMh/LgJgZG6ORZt/14XukZFS83KmCvPnKRLAs1BzXA2/mNktmo0+/vUwbzQn4eSZ5vzb TBK4Pp6XvH2j3rmDAogyO2IL0iU5tUFE4S91zxQam63awzQhB9iPntDX; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: 'Jan Janak' , 'Juha Heinanen' , behave@ietf.org, mmusic@ietf.org, 'P2PSIP 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: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, July 26, 2007 6:10 AM > To: Adam Fisk; Jiri Kuthan > Cc: behave@ietf.org; mmusic@ietf.org; Juha Heinanen; Jan > Janak; P2PSIP WG > Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE > deploymentdatabefore LCfor RFC > > This insight may be very useful when designing a test tool for ICE. > > As I have insisted, we need deployment testing for ICE and > continued tweaking to make it real. > > I have no idea what the deployment testing may reveal and the > attached is a welcome example. > > > > Is anyone on these lists designing a test tool for NAT > scenario discovery and for ICE? Awhile back Christian Huitema announced Microsoft's NAT testing tool, http://www1.ietf.org/mail-archive/web/behave/current/msg02117.html > > Microsoft just released a tool that may be interesting for > this list: > http://www.microsoft.com/windows/using/tools/igd/default.mspx > The tool applies various tests against routers to check > how they implement NAT, UPNP, or support of various TCP > options. It is based on Microsoft's "home networking" > requirements for XP and Vista. Arguably, a later version > could implement BEHAVE's requirement, when they are > published by the IETF. > > -- Christian Huitema > It requires a browser that supports Active X. -d > Henry > > > > ________________________________ > > From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On > Behalf Of Adam Fisk > Sent: Wednesday, July 25, 2007 11:41 PM > To: Jiri Kuthan > Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; > mmusic@ietf.org > Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE > deploymentdatabefore LC for RFC > > > > I had a conversation earlier tonight at the NYC p2p meetup > that led me to question my previous assumptions about ICE > "working". Supposedly many routers start to do funny things > when they see lots of ICE UDP packets flying by and trying > lots of candidates. > > This has me worried. We all know the frightening number of > NAT configurations out there. Maybe I missed it, but is > there a test matrix somewhere of NAT combinations and their > success rates with ICE? If not, could we create one using > one of the open source ICE implementations out there (mine's > not quite ready)? I'd be happy to contribute my own router > if we had a simple test program, maybe based on the work at Nokia. > > I think performing those simple tests would set everyone's > mind at ease. Otherwise, I am concerned that some NAT and > firmware combinations would balk at what they see as packet floods. > > To a person, everyone I've talked to who has implemented this > stuff in the "real world" has said the array of problems with > specific NAT configurations is much more significant than > they realized at first. I think this is the central problem > -- the world we're deploying this in is much more chaotic > than that of more RFCs, as the BEHAVE group is trying to address. > > -Adam > > On 7/24/07, Adam Fisk wrote: > > I've followed ICE development on the sidelines for years now, > and I'm currently implementing ICE 17. I've implemented what > will be open source implementations of STUN and TURN, both > client and server. Here are the key points I've taken away > from that experience: > > 1) The patience of Jonathan and everyone else in meticulously > getting to the current draft is astonishing. > 2) ICE is complex as hell and a pain in the ^#* to implement. > I was surprised at how hard it was, particularly for a draft > that's so close to becoming an RFC. > 3) ICE is solving a very tricky problem. > > I like Phillip's earlier suggestion that the draft stay in > the "almost done" state like used to happen in the Routing > group. I realize that's asking a lot given how much work has > gone into it and how eager everyone is to finalize it. I > think the problem is that standardizing NAT traversal is just > hard, and hard problems are difficult to make simpler. In my > implementation of ICE, I do think it could be done more > simply, but I don't have concrete suggestions right now > because I'm still pulling my hair out with the > implementation. I'm not talking about drastic changes > anywhere, but all the checklist fiddling sure takes a lot of > patience to write. Simplifications might just be in the > description and not necessarily the algorithm. > > I think it's a hard enough and important enough problem that > we owe it to ourselves to be even more patient with an > "almost done" state that adds the final touches based on > real-world feedback. I don't doubt for a second that ICE > works, but it's so complex that I worry no one outside huge > companies will ever implement it. That would be a huge > hindrance to ICE's adoption and power. > > -Adam > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jul 27 07:41: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 1IEOBs-0003Vt-3M; Fri, 27 Jul 2007 07:41:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IEOBq-0003Vm-T8 for behave-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 07:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEOBq-0003Ve-Ja for behave@ietf.org; Fri, 27 Jul 2007 07:41:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEOBp-0001rw-CK for behave@ietf.org; Fri, 27 Jul 2007 07:41:02 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2007 07:41:01 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPd1qUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,588,1175486400"; d="scan'208"; a="66321780:sNHT30767908" 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 l6RBf0IS000555; Fri, 27 Jul 2007 07:41:00 -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 l6RBf0WI003994; Fri, 27 Jul 2007 11:41:00 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); Fri, 27 Jul 2007 07:41:00 -0400 Received: from [10.82.241.28] ([10.82.241.28]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 07:41:00 -0400 Message-ID: <46A9D9D6.7080906@cisco.com> Date: Fri, 27 Jul 2007 07:41:10 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Magnus Westerlund References: <46961402.2070202@ericsson.com> In-Reply-To: <46961402.2070202@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2007 11:41:00.0108 (UTC) FILETIME=[00F968C0:01C7D043] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4536; t=1185536461; x=1186400461; 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=20Comments=20on=20draft-ietf-behave-rfc3489bis-07 |Sender:=20 |To:=20Magnus=20Westerlund=20; bh=fH7ggsBNcyOO6Uxg0a8Lnz8W5Sv4anauInCCS4fIHco=; b=AZ9CecUj2W6VHkb+DU4sI5L0ws9GHIOWisYKc5ezfdL41OUmpPmcuWZ0MdM81ZZE/FSp0qw3 m8hrky0UenFUrv7Z2A+5Q2B4OSUyCBfs+6I/JThbXFejexuSwnA9s5hX; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -2.8 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Behave WG Subject: [BEHAVE] Re: Comments on draft-ietf-behave-rfc3489bis-07 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Magnus Westerlund wrote: > Hi, > > I have reviewed the draft and have couple of comments. Mostly minor > nits, but there are a few that I would like to have answers on. But > otherwise I think the draft is quite easy to read. Great, thanks. > > 1. Section 7.2.1: I wonder if there shouldn't be a recommended minimal > RTO time. I think 100 ms is small enough for all implementations. > Configuring anything smaller seems to me to be inviting a to big risk to > miss any replies because the total time waited until failure is declared > is well within the time it could take for a request to traverse some > path if the client is misstaking what paths it actually is on. OK. I added that this is the minimum. > > 2. Section 7.2.2: I think there is some unclarity in regards to which > event one starts ones failure timer when using TCP. Please remember that > if it is the SYN that are lost in the connectivity establishment process > then there will be only a one retransmission every 3 seconds. Thus > during the 7.9 seconds there will be only 2 retransmissions. If one > counts from succesful connectivity establishment one needs some timeout > also for the connectivity step. In general TCP will manage fewer > retransmissions than UDP with a RTO of 100 ms. > > 3. Section 10.2.1.1: I think it is unclear how the server is going to > know that longterm credentials shall be used. Is there an assumption > here that any STUN server using long-term credentials will use them for > all requests? If that is the case that should be mentioned. > > 4. Does STUN work with deploying servers with anycast addresses? If no, > then maybe it needs to be documented? > > 5. Section 15: I think it might be worth to mention that an attacker can > use a STUN server to bounce messages of them towards a target. There are > no amplification, but it can be used by an attacker to disperse attacks > streams so that they appear to come from many different sources to > reduce. But it assumes that they can spoof the source address of the > packet reaching the server. Especially for usages when there are no > integrity checks the STUN server will have no identity of the attacker. > > > Nits > > N1. Section 14.4: I think there are two sentences in this paragraph that > are in contradiction: > > "The text used as input to HMAC is the STUN message, > including the header, up to and including the attribute preceding the > MESSAGE-INTEGRITY attribute." > > "Since the hash is computed over the entire STUN message, it includes > the length field from the STUN message header." > > As I see it the problem is the "entire" in the second sentence. > > N2. Section 15.1.1: > An attacker can try to modify STUN messages in transit, in order to > cause a failure in STUN operation. These attacks are prevented for > both requests and responses through the message integrity mechanism, > using either a short term or long term credential. > > I think this paragraph is correct. You can always cause failure in STUN > operation by modifying packets so the integrity fails or simple delete > the packet. I think the paragraph needs to be reworded so that it > doesn't ignore the fact. As I understand the goal of the paragraph is to > say that with message integrity an attacker can't modify the STUN > message to have STUN checks shutdown immeditely. > > N3. Section 15.2.3: "This attack is similar to attack III." I don't > think this sentence in inteded to reference the section it self is > present in, maybe "II" is the right? > > 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 > ---------------------------------------------------------------------- > -- 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 Jul 27 08:03: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 1IEOVX-0004W8-Mp; Fri, 27 Jul 2007 08:01:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IEOVW-0004Vo-LJ for behave-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 08:01:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEOVW-0004VZ-7v for behave@ietf.org; Fri, 27 Jul 2007 08:01:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEOVT-0002VE-OR for behave@ietf.org; Fri, 27 Jul 2007 08:01:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2007 08:01:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOJ6qUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,588,1175486400"; d="scan'208"; a="66323240:sNHT30348116" 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 l6RC1JXH007605; Fri, 27 Jul 2007 08:01:19 -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 l6RC1JWI010313; Fri, 27 Jul 2007 12:01: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); Fri, 27 Jul 2007 08:01:19 -0400 Received: from [10.82.241.28] ([10.82.241.28]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 08:01:18 -0400 Message-ID: <46A9DE99.4060209@cisco.com> Date: Fri, 27 Jul 2007 08:01:29 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Magnus Westerlund References: <46961402.2070202@ericsson.com> In-Reply-To: <46961402.2070202@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2007 12:01:18.0816 (UTC) FILETIME=[D7617E00:01C7D045] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4654; t=1185537679; x=1186401679; 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=20Comments=20on=20draft-ietf-behave-rfc3489bis-07 |Sender:=20 |To:=20Magnus=20Westerlund=20; bh=04kI9wpUtwI62cfiE1JfYdkChnT3q/P7FLN9B8Rcj0g=; b=BO0DEdeLuthacSr7Z42BXsN3p2PqBpldJj3wnU1nF+zYYb0WvxHcsDCy1qkiWjnQHiV3TXG9 4A4m1ahWw9K/bJmI+pX49JB1Z8iBadlZ+XxDCPiicdtDJjXFZe8MewqS; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.2 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Behave WG Subject: [BEHAVE] Re: Comments on draft-ietf-behave-rfc3489bis-07 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 for the previous post, hit send by accident. Magnus Westerlund wrote: > Hi, > > I have reviewed the draft and have couple of comments. Mostly minor > nits, but there are a few that I would like to have answers on. But > otherwise I think the draft is quite easy to read. Great, thanks. > > 1. Section 7.2.1: I wonder if there shouldn't be a recommended minimal > RTO time. I think 100 ms is small enough for all implementations. > Configuring anything smaller seems to me to be inviting a to big risk to > miss any replies because the total time waited until failure is declared > is well within the time it could take for a request to traverse some > path if the client is misstaking what paths it actually is on. OK. I added that this is the minimum. > > 2. Section 7.2.2: I think there is some unclarity in regards to which > event one starts ones failure timer when using TCP. Please remember that > if it is the SYN that are lost in the connectivity establishment process > then there will be only a one retransmission every 3 seconds. Thus > during the 7.9 seconds there will be only 2 retransmissions. If one > counts from succesful connectivity establishment one needs some timeout > also for the connectivity step. In general TCP will manage fewer > retransmissions than UDP with a RTO of 100 ms. I'd say its from the start of SYN. I agree this will cause fewer SYN retransmits. > > 3. Section 10.2.1.1: I think it is unclear how the server is going to > know that longterm credentials shall be used. Is there an assumption > here that any STUN server using long-term credentials will use them for > all requests? If that is the case that should be mentioned. Yes. Basically its a function of the usage. A STUN server on the public network supporting ICE would use no authentication. A TURN server would always use long term. I noted this in the introductory text of section 10. > > 4. Does STUN work with deploying servers with anycast addresses? If no, > then maybe it needs to be documented? For UDP, when there is no authentication, STUN works with anycast. I mentioned this in setion 7.2. > > 5. Section 15: I think it might be worth to mention that an attacker can > use a STUN server to bounce messages of them towards a target. There are > no amplification, but it can be used by an attacker to disperse attacks > streams so that they appear to come from many different sources to > reduce. But it assumes that they can spoof the source address of the > packet reaching the server. Especially for usages when there are no > integrity checks the STUN server will have no identity of the attacker. I mentioned this in section 15.1.2. > > > Nits > > N1. Section 14.4: I think there are two sentences in this paragraph that > are in contradiction: > > "The text used as input to HMAC is the STUN message, > including the header, up to and including the attribute preceding the > MESSAGE-INTEGRITY attribute." > > "Since the hash is computed over the entire STUN message, it includes > the length field from the STUN message header." > > As I see it the problem is the "entire" in the second sentence. Right. Fixed. > > N2. Section 15.1.1: > An attacker can try to modify STUN messages in transit, in order to > cause a failure in STUN operation. These attacks are prevented for > both requests and responses through the message integrity mechanism, > using either a short term or long term credential. > > I think this paragraph is correct. You can always cause failure in STUN > operation by modifying packets so the integrity fails or simple delete > the packet. I think the paragraph needs to be reworded so that it > doesn't ignore the fact. As I understand the goal of the paragraph is to > say that with message integrity an attacker can't modify the STUN > message to have STUN checks shutdown immeditely. OK, I mentioned that, and clarified that this is only for on-path attackers. > > N3. Section 15.2.3: "This attack is similar to attack III." I don't > think this sentence in inteded to reference the section it self is > present in, maybe "II" is the right? Yes, fixed. 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 Fri Jul 27 08:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEOhd-0006FC-QO; Fri, 27 Jul 2007 08:13:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IEOhd-0006F7-8c for behave-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 08:13:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEOhc-0006Ez-VJ for behave@ietf.org; Fri, 27 Jul 2007 08:13:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEOhc-0002S0-Fp for behave@ietf.org; Fri, 27 Jul 2007 08:13:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2007 08:13:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACp+qUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,588,1175486400"; d="scan'208"; a="66323925:sNHT29821242" 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 l6RCDqOJ011227; Fri, 27 Jul 2007 08:13:52 -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 l6RCDqWI013754; Fri, 27 Jul 2007 12:13:52 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, 27 Jul 2007 08:13:51 -0400 Received: from [10.82.241.28] ([10.82.241.28]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 08:13:51 -0400 Message-ID: <46A9E18A.9070301@cisco.com> Date: Fri, 27 Jul 2007 08:14:02 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt References: <46929F98.5020706@acm.org> In-Reply-To: <46929F98.5020706@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2007 12:13:51.0716 (UTC) FILETIME=[9824EA40:01C7D047] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2523; t=1185538432; x=1186402432; 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-07.txt |Sender:=20 |To:=20Marc=20Petit-Huguenin=20; bh=f1I84/RriccaQxs+d/36Br0X+87khSD5igEiWeNY1iQ=; b=MwkLsZkAXnX14o7oRIiw5XL2ZMvTlsETp86s5UJTZhM+DDPwDhccemqcsFDCn0z0rgU/kUIi Fw3WWAzgav+2TEEuATfrhJurdnaVsvfBIrp4cXvhKFMCWykYV5PQjWLP; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org a few more comments inline: Marc Petit-Huguenin wrote: > I read the new draft, and I am happy with the improvements. > > All nine comments in my review are fixed one way or another in this > draft. Many thanks to do not remove the 300 error code. > > Some comments: > > 1. Section 13: The second paragraph lists ICE, Outbound and NAT Behavior > discovery as STUN usages. Shouldn't STUN relay be added to this list? Per the other notes in this thread, no. > > 2. Section 13: On the list of definitions that an usage should provide, > it should be specified if a new method is idempotent (see section 7.3.1) I think Philip addressed this. > > 3. Section 16: "STUN can be used to perform this function using a > BindingRequest/BindingResponse transaction..." should be "using a > Binding request/response transaction...". fixed. > > > Four nits: > > 1. Section 10.2.2: "It is RECOMENDED that the REALM value by the domain > name.." should be "It is RECOMMENDED that the REALM value is the domain > name..." fixed > > 2. Section 7.2.2: "...must be run ontop of some kind.." Should be "on top" fixed > > 3. Section 12: "...and transaction ids were 128 bits long;" should be > "128 bits long." The semicolon is used elsewhere in this list so I think its right. > > 4. Section 12: "...used the MAPPED-ADDRESS attribute instead" should be > "attribute instead." I believe this is correct as written. Thanks, Jonathan R. > > 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-07.txt >> Pages : 46 >> Date : 2007-07-08 >> > -- 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 Jul 27 08:21: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 1IEOpM-0005LA-Dr; Fri, 27 Jul 2007 08:21:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IEOpJ-0005Kf-4k for behave-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 08:21:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEOpI-0005KU-RS for behave@ietf.org; Fri, 27 Jul 2007 08:21:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEOpH-0002e3-L6 for behave@ietf.org; Fri, 27 Jul 2007 08:21:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2007 08:21:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGB/qUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,588,1175486400"; d="scan'208"; a="66324390:sNHT29924864" 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 l6RCLlEl001024; Fri, 27 Jul 2007 08:21:47 -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 l6RCLYEl017248; Fri, 27 Jul 2007 12:21:47 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, 27 Jul 2007 08:21:44 -0400 Received: from [10.82.241.28] ([10.82.241.28]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 08:21:43 -0400 Message-ID: <46A9E362.108@cisco.com> Date: Fri, 27 Jul 2007 08:21:54 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] RFC3489bis-07 now available References: <46929E54.50301@cisco.com> <200707171542.19726.remi.denis-courmont@nokia.com> <200707180945.46590.remi.denis-courmont@nokia.com> <12539761-29C6-42B8-BDE9-4FBF3D8368EC@magma.ca> In-Reply-To: <12539761-29C6-42B8-BDE9-4FBF3D8368EC@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Jul 2007 12:21:43.0522 (UTC) FILETIME=[B15CCC20:01C7D048] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1769; t=1185538907; x=1186402907; 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]=20RFC3489bis-07=20now=20available |Sender:=20 |To:=20Philip=20Matthews=20; bh=GbA/6ZzexmREMgmA55UeYoNyLXebXZpsLxrLR3vqBU8=; b=CI7hZj6FwS/uZqNT50C6UGaeMdSaMA/teRiNNQmrtjvCHpgixkuFuCRPUz6JQm/zNdgEh8Pm IDBQZI6R16wqwPgckxs8Olv1q5uAtEQ90+o59wZXdhY+nmjl2WLafNXk; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 I'm OK to change to bytes, but wiould prefer 763. The intent really was 128 characters, to support long names that could have 128 characters. 128 bytes is like 20 characters which is not long enough. I'll clarify its 128 characters (which can be up to 763 bytes). -Jonathan R. Philip Matthews wrote: > > On 18-Jul-07, at 02:45 , Rémi Denis-Courmont wrote: > >> On Tuesday 17 July 2007 21:24:30 you wrote: >>>>> * defined length limits on all free-form fields >>>> >>>> That's really appreciable! But but, the limit should most likely be >>>> expressed >>>> in bytes rather than in characters. Otherwise, it is pretty >>>> ambiguous whether >>>> the limit is in code points or bytes. >>> >>> I don't really see this. >>> For the username, it says >>> It MUST contain a >>> UTF-8 encoded sequence of less than 128 characters. >>> How is this ambiguous? >> >> To re-iterate the question, does "character" mean "code point" or >> "byte"? It >> is totally ambiguous. >> >> To me, a UTF-8 encoded sequence of less than 128 characters is up to >> (128-1)*6+1=763 bytes, counting the terminating nul (and that's a bit >> big, >> IMHO). To most implementors it's going to be 127(+1) bytes. >> >> I would much rather have: >> >> It MUST contain a valid UTF-8 encoded sequence of less than 128 >> bytes. > > OK. I see your point now, and think your proposed wording is fine. > > - Philip -- 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 Jul 27 08:27:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEOuz-0000yV-Gn; Fri, 27 Jul 2007 08:27:41 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IEOuy-0000yL-Hy for behave-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 08:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEOuy-0000yC-8S for behave@ietf.org; Fri, 27 Jul 2007 08:27:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEOux-0002m3-UU for behave@ietf.org; Fri, 27 Jul 2007 08:27:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2007 08:27:39 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACeCqUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,588,1175486400"; d="scan'208"; a="66324701:sNHT28141154" 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 l6RCRd3V002642; Fri, 27 Jul 2007 08:27:39 -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 l6RCRdEZ018956; Fri, 27 Jul 2007 12:27:39 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); Fri, 27 Jul 2007 08:27:35 -0400 Received: from [10.82.241.28] ([10.82.241.28]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 08:27:35 -0400 Message-ID: <46A9E4C2.1070101@cisco.com> Date: Fri, 27 Jul 2007 08:27:46 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [BEHAVE] RFC3489bis-07 now available References: <46929E54.50301@cisco.com> <200707171607.41159.remi.denis-courmont@nokia.com> In-Reply-To: <200707171607.41159.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Jul 2007 12:27:35.0419 (UTC) FILETIME=[831C04B0:01C7D049] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1396; t=1185539259; x=1186403259; 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]=20RFC3489bis-07=20now=20available |Sender:=20 |To:=20=3D?ISO-8859-1?Q?R=3DE9mi_Denis-Courmont?=3D=0A=20; bh=Mt40scVBvDF043kBKOTEWO4pWy5DwKO8V2dtStneI+A=; b=dRt2yf3jZ/H4H01bDZV9rm09P+7RRHlSHESNaZNDzNpWJjn0mE8Ehf8D/yjZEfKuYMGRMZfP k/5fzJadG1U3SH4BHuFpT5iqCjrVHCQnGHGqWHqq+njH21+Ts7Nk4bi4; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Rémi Denis-Courmont wrote: > On Monday 09 July 2007 23:45:08 ext Jonathan Rosenberg wrote: >> * removal of several error codes that could only happen in >> implementation errors. > > Looks like 431 has been unduly removed. It is still used in section 10, but is > not defined anymore. Actually, this is because of the issue below. The 431 here should say 401 (note that 401 is used for long term in both cases). > > By the way, I am not the kind of security expert to determine whether this > applies to STUN: Many protocols and applications are now purposedly returning > the same error code whether the username or the password/shared-secret is > wrong. I suppose that's meant to harden against brute-forcing. > > Perhaps 431 should be returned instead of 401 when the username is wrong. In > any case, the client application will handle both cases the same way, since > it could be that the user mistyped his/her username so that it ends up being > that of someone else. > 401 is returned in both cases. 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 Fri Jul 27 08:55:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEPLL-0000Tk-Lx; Fri, 27 Jul 2007 08:54:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IEPLJ-0000TR-Iy for behave-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 08:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEPLJ-0000TJ-9U for behave@ietf.org; Fri, 27 Jul 2007 08:54:53 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEPLI-0003Jq-Rv for behave@ietf.org; Fri, 27 Jul 2007 08:54:53 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 433E13A02022; Fri, 27 Jul 2007 05:54:52 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 9E9963A02020; Fri, 27 Jul 2007 05:54:50 -0700 (PDT) Message-ID: <46A9EB19.4000909@acm.org> Date: Fri, 27 Jul 2007 05:54:49 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt References: <46929F98.5020706@acm.org> <46A9E18A.9070301@cisco.com> In-Reply-To: <46A9E18A.9070301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Rosenberg wrote: > a few more comments inline: > > Marc Petit-Huguenin wrote: [snip] >> >> 2. Section 13: On the list of definitions that an usage should provide, >> it should be specified if a new method is idempotent (see section 7.3.1) > > I think Philip addressed this. > I am not sure. Philip said that this was not added in this section because it would be redundant with 7.3.1. I then pointed out that other definitions in section 13 were also redundant, but I do not know which way the spec will be modified (or not). -- 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 Fri Jul 27 09:20:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEPkA-0003fb-4K; Fri, 27 Jul 2007 09:20:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IEPk9-0003fT-Cw for behave-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 09:20:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEPk9-0003fL-2I; Fri, 27 Jul 2007 09:20:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEPk8-00043i-Kk; Fri, 27 Jul 2007 09:20:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 839DB2AC96; Fri, 27 Jul 2007 13:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IEPjd-0000kw-Nf; Fri, 27 Jul 2007 09:20:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 27 Jul 2007 09:20:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-08.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-08.txt Pages : 46 Date : 2007-07-27 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-08.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-08.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-08.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-07-27091314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-27091314.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 Jul 27 10: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 1IEQj1-0000Sk-MY; Fri, 27 Jul 2007 10:23:28 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IEQj0-0000Se-Cb for behave-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 10:23:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQj0-0000SW-30 for behave@ietf.org; Fri, 27 Jul 2007 10:23:26 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQiz-0005L8-KD for behave@ietf.org; Fri, 27 Jul 2007 10:23:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2007 10:23:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABadqUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,589,1175486400"; d="scan'208"; a="66336277:sNHT29131682" 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 l6RENPan002810; Fri, 27 Jul 2007 10:23:25 -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 l6RENLWO000198; Fri, 27 Jul 2007 14:23:25 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, 27 Jul 2007 10:23:13 -0400 Received: from [10.86.241.231] ([10.86.241.231]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 10:23:13 -0400 Message-ID: <46A9FFDB.2080800@cisco.com> Date: Fri, 27 Jul 2007 10:23:23 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt References: <46929F98.5020706@acm.org> <46A9E18A.9070301@cisco.com> <46A9EB19.4000909@acm.org> In-Reply-To: <46A9EB19.4000909@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2007 14:23:13.0544 (UTC) FILETIME=[AA8DE080:01C7D059] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1081; t=1185546205; x=1186410205; 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-07.txt |Sender:=20 |To:=20Marc=20Petit-Huguenin=20; bh=RejEw9IhNfsceZUj7A1HgYRNukw227F5Z4PEEr7q6co=; b=nduGHugbjexaOlgzyy3CWR6rkrOjPpZXTWi4MHnZrazjSbb1gn/qNSxbvAEjG8gjxogKaCY7 Tn0rXV3mPHxbdJNIst0+AUA/CFCv3w+GrJeCmr7XsW0ocVN5XJDZ0HIX; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Marc Petit-Huguenin wrote: > Jonathan Rosenberg wrote: >> a few more comments inline: >> >> Marc Petit-Huguenin wrote: > > [snip] > >>> 2. Section 13: On the list of definitions that an usage should provide, >>> it should be specified if a new method is idempotent (see section 7.3.1) >> I think Philip addressed this. >> > > I am not sure. Philip said that this was not added in this section > because it would be redundant with 7.3.1. I then pointed out that other > definitions in section 13 were also redundant, but I do not know which > way the spec will be modified (or not). > Section 13 is a summarization though, so even though what is in there is mentioned elsewhere, it needs to be in 13 once more. -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 Jul 30 12:49: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 1IFYQb-0000CF-Or; Mon, 30 Jul 2007 12:49:05 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFYQa-0000CA-AJ for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 12:49:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYQa-0000Bv-0c for behave@ietf.org; Mon, 30 Jul 2007 12:49:04 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYQY-0002OG-PM for behave@ietf.org; Mon, 30 Jul 2007 12:49:03 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2007 09:49:02 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOKyrUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.19,199,1183359600"; d="scan'208"; a="389050976:sNHT25453098" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6UGn2qE010291; Mon, 30 Jul 2007 09:49:02 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6UGn14w019537; Mon, 30 Jul 2007 16:49:01 GMT From: "Dan Wing" To: Date: Mon, 30 Jul 2007 09:49:00 -0700 Message-ID: <018601c7d2c9$883e4430$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfSyYeJQ++5s6PCTkai7JQiBxdNTA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=749; t=1185814142; x=1186678142; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC,=20rfc3489bis |Sender:=20; bh=fz5nPYy+PDtA66nXYO2B5H9gqiMWRKbnxl3w2lSH6UQ=; b=GmGK1DgCDF66eSl0j8rTd6lTKX02o0QSAWbIf4mO8lF/yzZtXZMkTbmSiX/FmY+V7CD5jZPp jHAX+Cl39SRThn1AB/YiVa+Nh2cnizD7vuw+Ot3tOpU2r2n+dXEUmHZcN2UwDSbdgYMyoBZG4e KbHzgrwG4Wzt7QxX9FnwMeYGk=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: huitema@microsoft.com, "'Dan Wing \(dwing\)'" , 'Philip Matthews' , 'Rohan Mahy' Subject: [BEHAVE] WGLC, rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 email announces the start of the second two-week working group last call (WGLC) on draft-ietf-behave-rfc3489bis-08, "Session Traversal Utilities for (NAT) (STUN)", http://tools.ietf.org/id/draft-ietf-behave-rfc3489bis-08.txt. The WGLC ends on Monday, August 13. Please send your comments to the BEHAVE list or to the document authors (CC'd on this mail). Differences are available at http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-08 (using the "Diff1" and "Diff2" links). The authors presentation from last week's IETF-69 meeting is at http://www3.ietf.org/proceedings/07jul/slides/behave-3.ppt Status of all BEHAVE documents is at: http://www.employees.org/behave/document-status.html -Dan Wing, BEHAVE chair _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 12:52: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 1IFYTW-0000zT-JB; Mon, 30 Jul 2007 12:52:06 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFYTU-0000zN-Pl for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 12:52:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYTU-0000zF-GB for behave@ietf.org; Mon, 30 Jul 2007 12:52:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYTT-0002RH-7n for behave@ietf.org; Mon, 30 Jul 2007 12:52:04 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2007 09:52:03 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIe0rUarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.19,199,1183359600"; d="scan'208"; a="508417486:sNHT32033936" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6UGq21C007842; Mon, 30 Jul 2007 09:52:02 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6UGpv4w020293; Mon, 30 Jul 2007 16:51:57 GMT From: "Dan Wing" To: Date: Mon, 30 Jul 2007 09:51:57 -0700 Message-ID: <018701c7d2c9$f3a673a0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfSyfCC+nNfWU6sT9m66RQsbRNIcQ== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=657; t=1185814322; x=1186678322; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC,=20p2p-state |Sender:=20; bh=MyUg9XjUFO2bWM2YROqA5nVFirsrrJorSj9IYawWPE0=; b=NWLVjzsmZgbE/hauU7LN5ceEp8fPOMH7mCt1i4O9ciyv6jsvxqxzo4UZtoHiyYESqoptJZ5e 8b8G3n2b05Y71DTjd+iIzNKA8JST+MVlBBon/b9PT+zTOKA6OE2fHy7X; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'Bryan Ford' , dank@kegel.com Subject: [BEHAVE] WGLC, p2p-state X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 email announces the start of the second two-week working group last call (WGLC) on draft-ietf-behave-p2p-state-03, " State of Peer-to-Peer(P2P) Communication Across Network Address Translators (NATs)" http://tools.ietf.org/id/draft-ietf-behave-p2p-state-03.txt. The WGLC ends on Monday, August 13. Please send your comments to the BEHAVE list or to the document authors (CC'd on this mail). Differences are available at http://tools.ietf.org/html/draft-ietf-behave-p2p-state-03 (using the "Diff1" and "Diff2" links). Status of all BEHAVE documents is at: http://www.employees.org/behave/document-status.html -Dan Wing, BEHAVE chair _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 12:56: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 1IFYXq-0003bf-RJ; Mon, 30 Jul 2007 12:56:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFYXp-0003ba-75 for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 12:56:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYXo-0003bS-Tq for behave@ietf.org; Mon, 30 Jul 2007 12:56:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYXn-0002Wi-ME for behave@ietf.org; Mon, 30 Jul 2007 12:56:32 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 30 Jul 2007 09:56:15 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAL20rUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,199,1183359600"; d="scan'208"; a="168753094:sNHT543084831" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6UGuFNE026907; Mon, 30 Jul 2007 09:56:15 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6UGuETb011405; Mon, 30 Jul 2007 16:56:14 GMT From: "Dan Wing" To: Date: Mon, 30 Jul 2007 09:56:14 -0700 Message-ID: <018801c7d2ca$8a9250e0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfSyonIcPBlCO+cRbidXzpHbVrWHQ== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=621; t=1185814575; x=1186678575; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC,=20nat-icmp |Sender:=20; bh=ysFmNsK6vf2Wt8/WjR9NKvKWqSYQMRL7+oD8oODGt8Y=; b=j+yF6sKn0RXyuCrjJhrNfMfUrf08Hg8RkuWBiRu3lw0K6TFMn4iQVfS7Yqv3sQz86OtHxTYm DRtTRrWynXLeQsH1ugIhTAOAXbIIZoBFuWAP/QmMPQdpU/3/t5IL/M3y; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'Bryan Ford' Subject: [BEHAVE] WGLC, nat-icmp X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 email announces the start of the first two-week working group last call (WGLC) on draft-ietf-behave-nat-icmp-04.txt, "NAT Behavioral Requirements for ICMP protocol" http://tools.ietf.org/id/draft-ietf-behave-nat-icmp-04.txt. The WGLC ends on Monday, August 13. Please send your comments to the BEHAVE list or to the document authors (CC'd on this mail). Differences are available at http://tools.ietf.org/html/draft-ietf-behave-nat-icmp-04 (using the "Diff1" and "Diff2" links). Status of all BEHAVE documents is at: http://www.employees.org/behave/document-status.html -Dan Wing, BEHAVE chair _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 13:26:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZ18-0001DO-Lb; Mon, 30 Jul 2007 13:26:50 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFZ17-0001Ao-5d for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 13:26:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZ16-0001Ag-PZ for behave@ietf.org; Mon, 30 Jul 2007 13:26:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFZ16-0003aM-AH for behave@ietf.org; Mon, 30 Jul 2007 13:26:48 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2007 10:26:47 -0700 X-IronPort-AV: i="unknown"; a="191201906:sNHT0" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6UHQlYo021279; Mon, 30 Jul 2007 10:26:47 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6UHQcTb021066; Mon, 30 Jul 2007 17:26:38 GMT From: "Dan Wing" To: Date: Mon, 30 Jul 2007 10:26:38 -0700 Message-ID: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfSzskf9wxeXRhnSA2cSHWPBMz2Gw== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1549; t=1185816407; x=1186680407; 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:=20TURN=3A=20technical=20review=20by=20September=201 |Sender:=20; bh=jgmFQKCdtsY3OYhKG7puANBZVXn8y4VG5TUJSjPkqwA=; b=uiCvLr1w4hx9dG8VUQeaX2qFgwwETmmnJVB8jrgHkuBauVLP6O0w274HedFVvzJBd4DjSu/W Snpffw2DRt6xGg8O9GnArNgkgfJoBTF2njINorgRx/8iA5QNnhQU09iV; 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Rohan Mahy' , huitema@microsoft.com Subject: [BEHAVE] TURN: technical review by September 1 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Chicago at IETF-69 we explained the urgency around rfc3489bis = ("STUNbis") and TURN. ICE needs to be published at the same time as rfc3489bis and = TURN because ICE normatively references those documents. Rfc3489bis = underwent substantial revision between -06 and -08, and I just WGLC'd = rfc3489bis-08 a few minutes ago. However, TURN is not yet ready to be WGLC'd. We need technical review of draft-ietf-behave-turn-04 (http://tools.ietf.org/html/draft-ietf-behave-turn-04) especially by = server implementers and client implementers. Thanks to our technical reviewing volunteers, Francois Audet, R=E9mi Denis-Courmont, Alan Hawrlylshen, = Alfred E. Heggestad, Brian Hibbard, and Marc Petit-Huguenin. Additional technical reviewers are welcome! Technical reviews are due by September 1. During this technical review please concentrate on deficiencies with the protocol (previously we have = had questions raised around framing, operation, and the authorization = model), difficulties in implementation, and conceptual flow and ease of understanding the document itself. Please refrain from mentioning capitalization or spelling errors; these are expected to be corrected by = the authors during the creation of -05. Please send your technical review = to the TURN authors (CC'd on this message) or to the BEHAVE mailing list. =20 The first week of September a team will begin editing the document and = will submit TURN-05 the first of week October. I expect that TURN-05 will be WGLC'd. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 14:30: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 1IFa12-0006TJ-KA; Mon, 30 Jul 2007 14:30:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFa0x-0006T5-QL for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 14:30:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFa0x-0006S2-Dj for behave@ietf.org; Mon, 30 Jul 2007 14:30:43 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFa0w-0005bR-Lw for behave@ietf.org; Mon, 30 Jul 2007 14:30:43 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out3.apple.com (Postfix) with ESMTP id DEC1ED25949; Mon, 30 Jul 2007 11:30:41 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id CC64910079; Mon, 30 Jul 2007 11:30:41 -0700 (PDT) X-AuditID: 11807124-a4fb7bb0000007f3-09-46ae2e516a78 Received: from [17.206.23.199] (il0602a-dhcp71.apple.com [17.206.23.199]) by relay6.apple.com (Apple SCV relay) with ESMTP id B904510042; Mon, 30 Jul 2007 11:30:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20070723193610.70736233CB@coconut.itojun.org> <319C5A3B-939C-48BD-AF65-93E41F09406B@cisco.com> <200707241931.19400.rdenis@simphalempin.com> <884C56D2-F80F-43F4-91D9-B04A0DD7D484@cisco.com> <20070727180131.GA69215@Space.Net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44BC323E-454C-4B96-A0A5-2840B20137C5@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Mon, 30 Jul 2007 11:30:40 -0700 To: IPv6 Operations , Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [BEHAVE] Re: CPE equipments and stateful filters X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org [ Added BEHAVE working group. ] On Jul 27, 2007, at 19:44, Fred Baker wrote: > > [...] Alain's comment in the plenary Thursday evening that James > document and my comments on this list advocate NAT are, in the best > possible case, incorrect - nobody is talking about NAT in IPv6, > although I do believe that there will be places that network > operators choose to use that class of capability. In the worst > case, it constitutes a deliberate misstatement calculated to cause > confusion and troll for a flame war in this venue. I choose to > believe the former, although I ask myself the question. [...] I wasn't present for the plenary, so I don't know what M. Durand said, but let me clarify my position, which I believe is best characterized as a "warning that we have not quite succeeded in making NAT obsolete" with IPv6. The need to implement what I am now calling "application transparency helpers," which function like ALG modules in an IPv4/NAT firewall, but which only help control transport filtering state in response to application protocol content without actually coordinating any UNSAF function like an ALG does, is a vector by which NAT implementations may worm their way back into the IPv6 architecture. I'm currently looking at source code in OpenBSD PF that appears designed to use IPv6-NAT to redirect application flows to userland proxies for exactly this purpose. IPv6 support for an FTP "transparency helper" is on my list of things I expect to need, and using an IPv6 NAT to redirect FTP control flows in and out of my existing IPv4 FTP proxy looks like the obvious shortest path to working code. (Similar things will need to be done with all the other major application protocols.) If IPv6 NAT were truly obsolete, this wouldn't be the case, but it is. Hence, my warning. Coming away from IETF 69 in Chicago, I'm now convinced that IETF will not be revisiting its consensus that the public IPv6 internet is intended to be clients behind multiple layers of firewalls communicating mainly through mediation services in data centers. I'm certain my employers will have no trouble adapting to this reality. I'm no longer certain that IPv6 will ever be a suitable replacement for IPv4/NAT in residential settings, but I see reasons to be hopeful that all is not lost on that account. -- james woodyatt member of technical staff, communications engineering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 15:15:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFai4-0006LS-V5; Mon, 30 Jul 2007 15:15:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFai3-0006LN-Vi for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 15:15:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFai3-0006LF-Jr for behave@ietf.org; Mon, 30 Jul 2007 15:15:15 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFai3-0006qT-24 for behave@ietf.org; Mon, 30 Jul 2007 15:15:15 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 30 Jul 2007 12:15:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANzVrUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,199,1183359600"; d="scan'208"; a="11166589:sNHT13666236" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6UJFEFK020696; Mon, 30 Jul 2007 12:15:14 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6UJFB4w008548; Mon, 30 Jul 2007 19:15:11 GMT From: "Dan Wing" To: "'james woodyatt'" Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 12:15:11 -0700 Message-ID: <02ed01c7d2dd$f4b90500$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfS18iu7zQaGpM3SAq0SpPf/N4HzwABIYpQ In-Reply-To: <44BC323E-454C-4B96-A0A5-2840B20137C5@apple.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2314; t=1185822914; x=1186686914; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20CPE=20equipments=20and=20stateful= 20filters |Sender:=20; bh=cj2WyKQuvO1zrYj663QRTdR528mJ4BXac/3P3KiPpfo=; b=RlQtUKjPwBsSGZ8SDZTzQ9bxbIbfJwqWGJdRhveCKPHz7CjGHrh6klUz5ZOfSnXgIosHZs7n fMQM7bvxWG3MkywdMmaLY/Lraop0kcVh8yeJolnpmS+1IAifnggEWM8b; 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: 0a7aa2e6e558383d84476dc338324fab Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: james woodyatt [mailto:jhw@apple.com] > Sent: Monday, July 30, 2007 11:31 AM > To: IPv6 Operations; Behave WG > Subject: [BEHAVE] Re: CPE equipments and stateful filters ... > I'm currently looking at source code in OpenBSD PF that appears > designed to use IPv6-NAT to redirect application flows to userland > proxies for exactly this purpose. IPv6 support for an FTP > "transparency helper" is on my list of things I expect to need, and > using an IPv6 NAT to redirect FTP control flows in and out of my > existing IPv4 FTP proxy looks like the obvious shortest path to > working code. (Similar things will need to be done with all the > other major application protocols.) Application-aware ALGs are bad. Passive-mode FTP (using the "PASV" verb) has been supported on all modern FTP clients and FTP servers for a long time (going on a decade for most FTP clients and FTP servers). Passive-mode FTP causes the TCP data connection to be initiated by the FTP client (as is the TCP control connection), which eliminates the need for any ALG or ALG-like function in NATs and in firewalls. Is there a reason passive FTP can't simply be mandated for v6, so we can avoid FTP-aware ALGs? > If IPv6 NAT were truly obsolete, this wouldn't be the case, but it > is. Hence, my warning. > > Coming away from IETF 69 in Chicago, I'm now convinced that > IETF will > not be revisiting its consensus that the public IPv6 internet is > intended to be clients behind multiple layers of firewalls > communicating mainly through mediation services in data > centers. I'm certain my employers will have no trouble > adapting to this reality. > > I'm no longer certain that IPv6 will ever be a suitable replacement > for IPv4/NAT in residential settings, but I see reasons to be > hopeful that all is not lost on that account. I do hope you pursue a BoF in Vancouver to discuss the need for endpoints to communicate to firewalls in IPv6. -d > > -- > james woodyatt > member of technical staff, communications engineering > > > > > _______________________________________________ > 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 Jul 30 15:17:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFakd-000802-3R; Mon, 30 Jul 2007 15:17:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFakb-0007vy-4z for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 15:17:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFaka-0007vD-RO for behave@ietf.org; Mon, 30 Jul 2007 15:17:52 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFaka-0006lc-Em for behave@ietf.org; Mon, 30 Jul 2007 15:17:52 -0400 Received: from auguste.remlab.net (unknown [IPv6:2002:3e4e:969c:0:20d:60ff:fe38:6d16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by poy.chewa.net (Postfix) with ESMTP id 39F15967B5; Mon, 30 Jul 2007 21:17:51 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: james woodyatt Date: Mon, 30 Jul 2007 22:17:49 +0300 User-Agent: KMail/1.9.7 References: <20070723193610.70736233CB@coconut.itojun.org> <44BC323E-454C-4B96-A0A5-2840B20137C5@apple.com> In-Reply-To: <44BC323E-454C-4B96-A0A5-2840B20137C5@apple.com> MIME-Version: 1.0 Message-Id: <200707302217.49479@auguste.remlab.net> X-Spam-Score: 1.6 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IPv6 Operations , Behave WG Subject: [BEHAVE] Re: CPE equipments and stateful filters X-BeenThere: behave@ietf.org X-Mailman-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="===============1259745604==" Errors-To: behave-bounces@ietf.org --===============1259745604== Content-Type: multipart/signed; boundary="nextPart3929689.TrJvWWe4HL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart3929689.TrJvWWe4HL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le lundi 30 juillet 2007, james woodyatt a =E9crit : > I'm currently looking at source code in OpenBSD PF that appears > designed to use IPv6-NAT to redirect application flows to userland > proxies for exactly this purpose. IPv6 support for an FTP > "transparency helper" is on my list of things I expect to need, and > using an IPv6 NAT to redirect FTP control flows in and out of my > existing IPv4 FTP proxy looks like the obvious shortest path to > working code. (Similar things will need to be done with all the > other major application protocols.) As far as I know, EPSV is recommended against EPRT, so I fail to see a=20 problem for that *particular* protocol. I understand many legacy FTP=20 clients use PORT by default, but these cannot do IPv6 anyway. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ --nextPart3929689.TrJvWWe4HL 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) iEYEABECAAYFAkauOV0ACgkQw+xtvt1tEr25fwCfZJU3lu0qayQeT+jtt65OA5yP yI4AniHxZDuXDbVtU4cCKsTKuzsDriM5 =lTtf -----END PGP SIGNATURE----- --nextPart3929689.TrJvWWe4HL-- --===============1259745604== 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 --===============1259745604==-- From behave-bounces@ietf.org Mon Jul 30 15:51: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 1IFbH6-00011D-DZ; Mon, 30 Jul 2007 15:51:28 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFbH4-000116-9y for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 15:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbH4-00010y-0X for behave@ietf.org; Mon, 30 Jul 2007 15:51:26 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFbH2-0007a7-Pt for behave@ietf.org; Mon, 30 Jul 2007 15:51:25 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (Postfix) with ESMTP id 7A841D7A424; Mon, 30 Jul 2007 12:51:24 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 6903529C003; Mon, 30 Jul 2007 12:51:24 -0700 (PDT) X-AuditID: 11807123-a7f42bb000000b34-73-46ae413c6516 Received: from [17.206.23.199] (il0602a-dhcp71.apple.com [17.206.23.199]) by relay5.apple.com (Apple SCV relay) with ESMTP id 555CB30400E; Mon, 30 Jul 2007 12:51:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <02ed01c7d2dd$f4b90500$c5f0200a@amer.cisco.com> References: <02ed01c7d2dd$f4b90500$c5f0200a@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32279DF2-63AB-4EA4-AC82-11ECBE3D7765@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 12:51:23 -0700 To: IPv6 Operations , Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Jul 30, 2007, at 12:15, Dan Wing wrote: > > Application-aware ALGs are bad. They are better than nothing. > Passive-mode FTP (using the "PASV" verb) has been supported on > all modern FTP clients and FTP servers for a long time (going on a > decade for most FTP clients and FTP servers). Passive-mode FTP > causes the TCP data connection to be initiated by the FTP client (as > is the TCP control connection), which eliminates the need for any ALG > or ALG-like function in NATs and in firewalls. Is there a reason > passive FTP can't simply be mandated for v6, so we can avoid FTP-aware > ALGs? No. Passive-mode FTP is broken for exterior clients connecting to interior servers by stateful packet filters. Merely allowing the FTP control port through the filter to the interior server is insufficient. Requiring FTP clients and servers to use TCP simultaneous open for data connections could address this problem, but I've been using FTP as an example to illustrate the wider problem with applications in general. We still have an open problem regarding IKE and IPsec ESP/AH, and I don't see a comparable way to resolve it without an application transparency helper or by allowing inbound ESP/AH by default. It remains to be seen whether consensus will emerge around the latter solution, so I contend the former remains an open problem. There are similar issues with RTSP and RTCP/RTP flows. And other existing application protocols. Not to mention applications not imagined by their developers yet. And and and. So long as the IPv6 architecture is defined such that communications between endpoints are always expected to originate with nodes behind firewalls and mediated by services in data centers, we will be saddled with the need for either 1) application transparency helpers inside network firewalls, and/or 2) an improvement to the core IPv6 specifications along the lines of my Application Listener Discovery (ALD) proposal. > I do hope you pursue a BoF in Vancouver to discuss the need for > endpoints to communicate to firewalls in IPv6. I'm working on socializing that plan with my management. -- james woodyatt member of technical staff, communications engineering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 16:30: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 1IFbsb-0005bT-AE; Mon, 30 Jul 2007 16:30:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFbsZ-0005bH-Ro for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 16:30:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbsZ-0005b9-I9 for behave@ietf.org; Mon, 30 Jul 2007 16:30:11 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFbsY-0008VW-UV for behave@ietf.org; Mon, 30 Jul 2007 16:30:11 -0400 Received: from auguste.remlab.net (unknown [IPv6:2002:3e4e:969c:0:20d:60ff:fe38:6d16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by poy.chewa.net (Postfix) with ESMTP id 289039661F; Mon, 30 Jul 2007 22:30:08 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: IPv6 Operations , Behave WG Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 23:30:05 +0300 User-Agent: KMail/1.9.7 References: <02ed01c7d2dd$f4b90500$c5f0200a@amer.cisco.com> <32279DF2-63AB-4EA4-AC82-11ECBE3D7765@apple.com> In-Reply-To: <32279DF2-63AB-4EA4-AC82-11ECBE3D7765@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707302330.05726@auguste.remlab.net> X-Spam-Score: -0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Le lundi 30 juillet 2007, james woodyatt a =E9crit : > So long as the IPv6 > architecture is defined such that communications between endpoints > are always expected to originate with nodes behind firewalls and > mediated by services in data centers, we will be saddled with the > need for either 1) application transparency helpers inside network > firewalls, and/or 2) an improvement to the core IPv6 specifications > along the lines of my Application Listener Discovery (ALD) proposal. I would not that the architecture is defined such. First, because the=20 IETF, as an SDO, has an history of NOT specifying architectures.=20 Second, because there is clearly NOT a consensus on that topic. *But*, I would agree that, in any case, =2D whatever the IETF mandates, recommends, suggests, or not, =2D whether or not this is a good idea, =2D whether or not it abides to the IETF design principles, =2D whether ir not this is good engineering, =2D whether it displeases some consumer ISPs, =2D whether it breaks IETF transport protocols, =2D whether it breaks IETF mobility protocols [1], =2D whether or not it makes IPv6 rather useless compared to IPv4+NATs, =2D ... =2E..there will be stateful firewalling middleboxes in some "unmanaged"=20 network cases. And it will also definitely happen on consumer-grade=20 radio links. =2D-- Footnote: --- [1] Mobile IPv6 has been notoriously absent from this debate so far. It=20 is all the weirder as it has been at the center of another recent IETF=20 IPv6 hot topic: RH0 deprecation. =2D-- Therefore, as an individual, I think there would be value for IETF in: =2D working on ALD or something along its line, and, =2D working on BEHAVE-ish recommendations for such boxes, to minimize the=20 damage to the works of the IETF Transport and Internet areas (and=20 indirectly the RAI and Apps areas). By this, I mean non-UDP transport=20 protocols, mobility/multihoming stuff, and some future proofing. My 2 cents, =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 16:33:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbw9-0008R5-Fa; Mon, 30 Jul 2007 16:33:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFbw7-0008PF-Lf for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 16:33:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbw7-0008Lt-3f for behave@ietf.org; Mon, 30 Jul 2007 16:33:51 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFbw5-00009V-TH for behave@ietf.org; Mon, 30 Jul 2007 16:33:51 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2007 13:33:50 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKfnrUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,200,1183359600"; d="scan'208"; a="191296505:sNHT26060184" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6UKXn4o016259; Mon, 30 Jul 2007 13:33:49 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6UKXlTb023707; Mon, 30 Jul 2007 20:33:47 GMT From: "Dan Wing" To: "'Gert Doering'" Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 13:33:47 -0700 Message-ID: <036a01c7d2e8$ef201010$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfS4Hm4CbUKQVcERzmeoshdVVOVxQAB8CZw In-Reply-To: <20070730193304.GV69215@Space.Net> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1997; t=1185827629; x=1186691629; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20CPE=20equipments=20and=20stateful= 20filters |Sender:=20; bh=R2EUX+1njLsSb3ksfpcsTQEgwezMhsN/93AtU6bH0pA=; b=EGeXbeta4n6b7Xw7LS8OYEZAoe0+ry6ZrW77gF2LIjuUG91bRgfGF+rWF7c+LUUw18VKLokR rjmrqHUN3z9jYoFBJucan/1ur2T26v/SVoiDwsf23k27q+gKJ7Wa5+QZ; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Gert Doering [mailto:gert@Space.Net] > Sent: Monday, July 30, 2007 12:33 PM > To: Dan Wing > Cc: 'james woodyatt'; 'IPv6 Operations'; 'Behave WG' > Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters > > Hi, > > On Mon, Jul 30, 2007 at 12:15:11PM -0700, Dan Wing wrote: > > Passive-mode FTP (using the "PASV" verb) has been supported on > > all modern FTP clients and FTP servers for a long time (going on a > > decade for most FTP clients and FTP servers). Passive-mode FTP > > causes the TCP data connection to be initiated by the FTP > > client (as > > is the TCP control connection), which eliminates the need > > for any ALG > > or ALG-like function in NATs and in firewalls. Is there a reason > > passive FTP can't simply be mandated for v6, so we can > > avoid FTP-aware ALGs? > > Correct me if I'm wrong - but you'll need "firewall support" for > PASV / EPSV ftp as well, just on the other side of the connection. > > If you run your server behind a firewall (which is a pretty > common thing > to do), and want to offer FTP services, the firewall needs to > know which port to open for PASV connections. You are certainly right that such a firewall protecting the FTP server needs to open pinholes for the incoming TCP data connection when using PASV. (We could argue about the commonality of such a configuration, but there isn't much point in such an argument; the need for hosts to communicate the desire for incoming connections to the firewall is what's important.) -d > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 113403 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 18:47:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFe1b-0005W6-FL; Mon, 30 Jul 2007 18:47:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFe1Z-0005Vi-Bh for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 18:47:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFe1Z-0005VX-2B for behave@ietf.org; Mon, 30 Jul 2007 18:47:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFe1Y-0004Wl-DI for behave@ietf.org; Mon, 30 Jul 2007 18:47:37 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2007 15:47:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABMHrkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,200,1183359600"; d="scan'208"; a="191361101:sNHT26343477" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6UMlZf5011502; Mon, 30 Jul 2007 15:47:35 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6UMlZTb008025; Mon, 30 Jul 2007 22:47:35 GMT From: "Dan Wing" To: "'james woodyatt'" , "'IPv6 Operations'" , "'Behave WG'" Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 15:47:34 -0700 Message-ID: <041c01c7d2fb$9f2c8df0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfS4wspw48Fhl3lRvasrp8+QHXNtgAD/Tng In-Reply-To: <32279DF2-63AB-4EA4-AC82-11ECBE3D7765@apple.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2906; t=1185835655; x=1186699655; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20CPE=20equipments=20and=20stateful= 20filters |Sender:=20; bh=ZUn/ZJNnCGorwO2uEHD/yWmFUu/gmpfApQTVGt6jDH0=; b=D9ZCP7MHAniGcspvfSyMr7Mi9YoFbHubUuejkckQ1G655T0bWWa3g7y+9fTtgGpq63NkpZ3/ XyjYQgz7WvtuCfB+vQpiMdi9t9ChQ3lqVdYLHPd9N4IOVecBmIU6PREi; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 > No. Passive-mode FTP is broken for exterior clients connecting to > interior servers by stateful packet filters. Merely allowing > the FTP > control port through the filter to the interior server is > insufficient. You're right. Thanks for pointing out my mistake in assuming the FTP server wouldn't, itself, be behind a similar firewall. > Requiring FTP clients and servers to use TCP > simultaneous open for data connections could address this problem, > but I've been using FTP as an example to illustrate the wider > problem with applications in general. > > We still have an open problem regarding IKE and IPsec ESP/AH, and I > don't see a comparable way to resolve it without an application > transparency helper or by allowing inbound ESP/AH by default. It > remains to be seen whether consensus will emerge around the latter > solution, so I contend the former remains an open problem. I don't see why you'd allow unsolicited ESP or AH, but deny other protocols (ICMP, UDP, TCP, SCTP, DCCP). It seems we need to solve this problem for all protocols. Certainly, if one is considering a battery-powered host, where receiving any packet will wake up the radio and host processor, unsolicited IPsec packets shouldn't be allowed any more so than unsolicited UDP or TCP. > There are similar issues with RTSP RTSP control traffic over TCP? > and RTCP/RTP flows. At this point, ICE (draft-ietf-mmusic-ice) is believed to provide a viable, incrementally deployable mechanism for IPv4 and IPv6, including if you're behind a NAT or firewall if that NAT or firewall allows packets from inside->outside to create permissions for outside->inside; most NATs available to consumers work like that and all firewalls can be configured like that. > And other > existing application protocols. Not to mention applications not > imagined by their developers yet. And and and. So long as the IPv6 > architecture is defined such that communications between endpoints > are always expected to originate with nodes behind firewalls and > mediated by services in data centers, we will be saddled with the > need for either 1) application transparency helpers inside network > firewalls, and/or 2) an improvement to the core IPv6 specifications > along the lines of my Application Listener Discovery (ALD) proposal. I see ALD being helpful for both the case of talking to a well- known server in a datacenter, and also being helpful for peer-to- peer applications, such as running an FTP client when you're behind a firewall trying to communicate with an FTP server that is also behind a firewall. > > I do hope you pursue a BoF in Vancouver to discuss the need for > > endpoints to communicate to firewalls in IPv6. > > I'm working on socializing that plan with my management. Good deal. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 19:31:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFeiI-00048A-Al; Mon, 30 Jul 2007 19:31:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFeiH-00045p-MS for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 19:31:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFeiH-00043K-Aw for behave@ietf.org; Mon, 30 Jul 2007 19:31:45 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFeiG-0006GN-Te for behave@ietf.org; Mon, 30 Jul 2007 19:31:45 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id 4AFCCD2B864; Mon, 30 Jul 2007 16:31:44 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 37E8930063; Mon, 30 Jul 2007 16:31:44 -0700 (PDT) X-AuditID: 11807125-a3a21bb0000007e5-46-46ae74e0ca13 Received: from [17.206.23.199] (il0602a-dhcp71.apple.com [17.206.23.199]) by relay7.apple.com (Apple SCV relay) with ESMTP id 25D2E300C6; Mon, 30 Jul 2007 16:31:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <041c01c7d2fb$9f2c8df0$c5f0200a@amer.cisco.com> References: <041c01c7d2fb$9f2c8df0$c5f0200a@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01D283D0-1FD0-4716-90B8-38086595C262@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 16:31:43 -0700 To: IPv6 Operations , Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Jul 30, 2007, at 15:47, Dan Wing wrote: > [I wrote:] >> >> There are similar issues with RTSP > > RTSP control traffic over TCP? Yes. As seen in QuickTime and RealPlayer applications. >> and RTCP/RTP flows. > > At this point, ICE (draft-ietf-mmusic-ice) is believed to provide > a viable, incrementally deployable mechanism for IPv4 and IPv6, > including if you're behind a NAT or firewall if that NAT or firewall > allows packets from inside->outside to create permissions for > outside->inside; most NATs available to consumers work like that > and all firewalls can be configured like that. Existing code (which does support IPv6) has no support for ICE. Even in the event ICE isn't deployed, how do you recommend I resist the inevitable pressure to implement an application transparency helper for these A/V streaming applications? I'm still having to maintain ALG's in IPv4/NAT for various VPN protocols even though we have long had standards track protocols for IPsec encapsulated in UDP and negotiating NAT traversal of IKE. I'm expecting to have to implement a helper for IKE and IPsec ESP/AH in IPv6. Without it, I expect route optimization in Mobile IPv6 to be broken, since mobile nodes are supposed to bind with their home agents using an IPsec ESP security association. In fact, the more I read about route optimization in MIPv6, the more convinced I am that it represents the most glaring illustration yet of our failure to consider properly the implications of recommending the widespread deployment of stateful middlebox packet filtering in IPv6 networks. -- james woodyatt member of technical staff, communications engineering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 20:28: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 1IFfas-0006oy-ON; Mon, 30 Jul 2007 20:28:10 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFfar-0006or-Ck for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 20:28:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFfar-0006oj-24 for behave@ietf.org; Mon, 30 Jul 2007 20:28:09 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFfaq-0007Xo-G6 for behave@ietf.org; Mon, 30 Jul 2007 20:28:08 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2007 17:28:03 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHYerkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,200,1183359600"; d="scan'208"; a="191400487:sNHT30401496" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6V0S36a007341; Mon, 30 Jul 2007 17:28:03 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6V0S34w012218; Tue, 31 Jul 2007 00:28:03 GMT From: "Dan Wing" To: "'james woodyatt'" , "'IPv6 Operations'" , "'Behave WG'" Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 17:28:02 -0700 Message-ID: <050701c7d309$a84e2b10$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfTAdGzQnUoEa7KTauvL+V8dgygzgABhmFQ In-Reply-To: <01D283D0-1FD0-4716-90B8-38086595C262@apple.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3269; t=1185841683; x=1186705683; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20CPE=20equipments=20and=20stateful= 20filters |Sender:=20; bh=YKfd5VlGzjM1prOH+oI/O6WdOOAtKlsNvFyM2BqXsi8=; b=L328DQAPV1ON/0m4tmX8/+rcKWkCOgn4I4nOSvVWOD6Nbiyy1qvrIyV4QqYUA4FK2gQNe9Ft GvwwKSvZwg1QT5rwd4WAfMJUA+Egkd9Z0IoZ8W4OixDSJVdYs5a/8Fk+; 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: 4b800b1eab964a31702fa68f1ff0e955 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 Jul 30, 2007, at 15:47, Dan Wing wrote: > > [I wrote:] > >> > >> There are similar issues with RTSP > > > > RTSP control traffic over TCP? > > Yes. As seen in QuickTime and RealPlayer applications. > > >> and RTCP/RTP flows. > > > > At this point, ICE (draft-ietf-mmusic-ice) is believed to provide > > a viable, incrementally deployable mechanism for IPv4 and IPv6, > > including if you're behind a NAT or firewall if that NAT or firewall > > allows packets from inside->outside to create permissions for > > outside->inside; most NATs available to consumers work like that > > and all firewalls can be configured like that. > > Existing code (which does support IPv6) has no support for ICE. > > Even in the event ICE isn't deployed, how do you recommend I resist > the inevitable pressure to implement an application transparency > helper for these A/V streaming applications? With ICE, such application helpers are not necessary. This was one of the major design decisions in ICE. This is the same design descision that allows Skype to "work anywhere". > I'm still having to > maintain ALG's in IPv4/NAT for various VPN protocols even though we > have long had standards track protocols for IPsec > encapsulated in UDP and negotiating NAT traversal of IKE. The only IPsec client implementation I'm aware of is Cisco's, and I know our implementation does not provide automatic detection or fallback from IPsec-over-IP to IPsec-over-UDP; rather, the user has to select this themselves or be artificially limited to always use UDP. IPsec-over-UDP is, of course, less bandwidth efficient than IPsec-over-IP. It's important to have such automatic fallback mechanisms. ICE provides these automatic fallbacks by using connectivity checks. We know how to multiplex those connectivity checks with RTP/RTCP, DTLS, TLS, HIP, and SIP. I expect ICE connectivity checks could be multiplexed with many other protocols. I am not suggesting ICE is the ideal solution for a host to tell its v6 firewall that it desires incoming traffic -- I am just explaining how ICE works as a datapoint. You may find it valuable to read the first two sections of ICE (and ignore the detail). Also, Jonathan Rosenberg gave an ICE tutorial in Chicago, posted at http://www.jdrosen.net/papers/ice-ietf-tutorial2.ppt. Like you, I wasn't present at the Thursday technical plenary but I listened to the audio, http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch5-thurs- afnoon-plenary.mp3 > I'm expecting to have to implement a helper for IKE and IPsec ESP/AH > in IPv6. Without it, I expect route optimization in Mobile IPv6 to > be broken, since mobile nodes are supposed to bind with their home > agents using an IPsec ESP security association. In fact, the more I > read about route optimization in MIPv6, the more convinced I am that > it represents the most glaring illustration yet of our failure to > consider properly the implications of recommending the widespread > deployment of stateful middlebox packet filtering in IPv6 networks. http://tools.ietf.org/html/draft-tschofenig-mip6-ice-01 describes how ICE might be useful for Mobile IPv6. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 20:56: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 1IFg20-0005LV-0A; Mon, 30 Jul 2007 20:56:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFg1y-0005LL-Oe for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 20:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFg1y-0005LD-F7 for behave@ietf.org; Mon, 30 Jul 2007 20:56:10 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFg1x-0007gS-3S for behave@ietf.org; Mon, 30 Jul 2007 20:56:10 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out3.apple.com (Postfix) with ESMTP id 84FA5D2CF42; Mon, 30 Jul 2007 17:56:08 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 6D0A01011D; Mon, 30 Jul 2007 17:56:08 -0700 (PDT) X-AuditID: 11807124-a4fb7bb0000007f3-e5-46ae88a8af95 Received: from [17.206.23.199] (il0602a-dhcp71.apple.com [17.206.23.199]) by relay6.apple.com (Apple SCV relay) with ESMTP id 60D4410093; Mon, 30 Jul 2007 17:56:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <050701c7d309$a84e2b10$c5f0200a@amer.cisco.com> References: <050701c7d309$a84e2b10$c5f0200a@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CBFAEC6-9677-4862-BFBF-073B701B9B67@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 17:56:08 -0700 To: IPv6 Operations , Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Jul 30, 2007, at 17:28, Dan Wing wrote: > > describes > how ICE might be useful for Mobile IPv6. I'm reading this draft now. It's fascinating. The authors apparently assume the deployment of IPv6 NAT. I wonder why. -- james woodyatt member of technical staff, communications engineering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jul 30 22:01: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 1IFh3I-00027d-Cg; Mon, 30 Jul 2007 22:01:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFh3H-00027Y-2r for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 22:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFh3G-00027P-PZ for behave@ietf.org; Mon, 30 Jul 2007 22:01:34 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFh3G-0001s3-Ag for behave@ietf.org; Mon, 30 Jul 2007 22:01:34 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id F12ADD2DE72; Mon, 30 Jul 2007 19:01:33 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id DEDA8300B6; Mon, 30 Jul 2007 19:01:33 -0700 (PDT) X-AuditID: 11807125-a121cbb0000007e5-5a-46ae97fd4241 Received: from [17.206.23.199] (il0602a-dhcp71.apple.com [17.206.23.199]) by relay7.apple.com (Apple SCV relay) with ESMTP id CB847300B5; Mon, 30 Jul 2007 19:01:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <9CBFAEC6-9677-4862-BFBF-073B701B9B67@apple.com> References: <050701c7d309$a84e2b10$c5f0200a@amer.cisco.com> <9CBFAEC6-9677-4862-BFBF-073B701B9B67@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <147F1193-7284-4C9A-8926-36068376E7EA@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 19:01:33 -0700 To: IPv6 Operations , Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Jul 30, 2007, at 17:56, james woodyatt wrote: > On Jul 30, 2007, at 17:28, Dan Wing wrote: >> >> describes >> how ICE might be useful for Mobile IPv6. > > I'm reading this draft now. If I understand how this might work, it would involve encapsulating IPsec ESP and IKE in UDP, to transit firewalls between MN's and their HA's, using conventional UDP state tracking. We don't currently have any protocol whereby IKE decides to switch over to UDP encapsulation, except in the NAT-traversal case, do we? With IPv6, we still think we have no NAT, so tests for reflexive addresses to match IKE initiations will always succeed. What triggers the switch to UDP encapsulation? The mobility layer trying to do STUN connectivity tests on the ESP protocol? Blech, but I guess it works most of the time. If it fails mysteriously, just try again-- that seems to be a common failure recovery method in human-centered systems. I can't say I approve of it. For one thing, I really don't like the idea of extending my implementations of IPsec and IKE to do STUN over protocol=50 and port=udp/500. RFC 4487 describes additional issues, e.g. CN's reaching MN's that roam behind networks with firewalls. proposes a way to work around the RRT issue, which looks on its face to be an ugly but workable hack. It reminds me that needs to be very explicit about how to handle the mobility extension header. Finally, seems not to care at all about the problem of home agents behind firewalls. RFC 4487 raises that issue, but I'm not seeing how M-ICE is supposed to address it. Did I miss something? My head hurts trying to sort out all the questions I have about ways these approaches potentially might fail during incremental deployment. On the other hand, all this stuff seems a lot simpler-- though still pretty soul-killingly fragile-- with ALD in the mix. I still think we'd be better off without any SPF middleboxes. (Oh, by the way, I remember now why I'm not optimistic about firewalls helping keep denial-of-service traffic off first mile links. That's a topic for another message, though.) -- james woodyatt member of technical staff, communications engineering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 02:43:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlRp-0008TY-2F; Tue, 31 Jul 2007 02:43:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFlRn-0008TS-EI for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 02:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlRn-0008TJ-4T for behave@ietf.org; Tue, 31 Jul 2007 02:43:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFlRm-0002He-OI for behave@ietf.org; Tue, 31 Jul 2007 02:43:11 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2007 23:43:10 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJZ2rkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,201,1183359600"; d="scan'208"; a="389182084:sNHT26034398" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6V6hAlc027786; Mon, 30 Jul 2007 23:43:10 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6V6h24w016316; Tue, 31 Jul 2007 06:43:04 GMT From: "Dan Wing" To: "'Gert Doering'" Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Mon, 30 Jul 2007 23:43:03 -0700 Message-ID: <05b401c7d33e$10360fc0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfTO90j9pI9PGKnQmCDrRTrsU+ojAAAYwRg In-Reply-To: <20070731062712.GA69215@Space.Net> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1152; t=1185864190; x=1186728190; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20CPE=20equipments=20and=20stateful= 20filters |Sender:=20; bh=/sWxJUBRXYvDeP4l2k28MYD0F8Z+MjWmLekRwjpW3IM=; b=PuTCuFlwWJFbSWtquEw4ZB/P3QA77TnieiQvtP6Q7KWEXJ7aZPBNDJj9kJly1tk5Z2n+dtx3 nMGWqVnOAVpNePwM9il1sa5z0J7P0HUe3gwjMTeZ66ujE0wkDRAJoZUk; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > On Mon, Jul 30, 2007 at 05:28:02PM -0700, Dan Wing wrote: > > The only IPsec client implementation I'm aware of is Cisco's, and > > I know our implementation does not provide automatic detection or > > fallback from IPsec-over-IP to IPsec-over-UDP; rather, the user has > > to select this themselves or be artificially limited to always use > > UDP. IPsec-over-UDP is, of course, less bandwidth efficient than > > IPsec-over-IP. > > This is again assuming "the IPSEC session is initiated outbound-only, > and the IPSEC server (gateway, whatever) is in a corporate > data center". > > In an end-to-end world, it may be desirable to have one residential > user setup IPSEC to another residential user. Both behind > such stateful firewalls that neither permit unsolicited > inbound UDP. In such a case, they need to communicate each others IP addresses (and perhaps UDP ports) using a rendezvous protocol (such as SIP, see draft-saito-mmusic-sdp-ike-01.txt) in order to allow one (or both) to allow inbound UDP (or 'raw' IPsec), or the server would need to tell its firewall to permit unsolicited incoming traffic. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 05:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFnqK-00071W-Ee; Tue, 31 Jul 2007 05:16:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFnqJ-00071R-62 for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 05:16:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFnqI-00071H-RR for behave@ietf.org; Tue, 31 Jul 2007 05:16:38 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFnqI-00083w-6J for behave@ietf.org; Tue, 31 Jul 2007 05:16:38 -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 l6V9Fv3A014451; Tue, 31 Jul 2007 12:16:27 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 12:16:13 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 12:16:12 +0300 Received: from esdhcp05136.research.nokia.com ([172.21.51.36]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 12:16:12 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN: technical review by September 1 Date: Tue, 31 Jul 2007 12:16:18 +0300 User-Agent: KMail/1.9.6 References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> In-Reply-To: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707311216.18858.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 31 Jul 2007 09:16:12.0212 (UTC) FILETIME=[703CAF40:01C7D353] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 'Rohan Mahy' , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hey, Rohan pointed out that congestion handling when there are multiple TCP=20 sessions to remote peers was an open issue. As far as I can tell, there is NO WAY to solve this, so long as we use a=20 single TCP session between the client and the TURN server. It is inherent t= o=20 how TCP works, and is the exact same issue that MSRP relays have. Regardles= s=20 whether that breaks forking, I really think we simply cannot do that=20 properly. Take this scenario: TURN client <-- TCP_C --> TURN server <-- TCP_A --> Peer A <-- TCP_B --> Peer B Now consider that TCP_B session gets congested. At some point, TURN server= =20 output buffer for TCP_B gets full. Now so long as the client only sends dat= a=20 to peer A, every thing is fine. But if the client sends data to peer B, the= =20 TURN server gets stuck. At this point, the server really can only do one of three things: (1) queue an indefinitely big amount of data, (2) stop dequeing data from the TURN client until TCP_B gets "decongested", (3) drop data for B, and reset/timeout connection with B. (1) is basically what MSRP does. Im my humble opinion, it is utterly broken= ;=20 and I think we agreed this was not the way to go. (2) is flawed, as communication between client and peer A will be unduly=20 disrupted. It is an obvious security issue if A and B do not trust each=20 others. Even then, it is probably unacceptable: if say, B looses connectivi= ty=20 for some reason, the flow to A will be totally disrupted until TCP_B=20 connection times out. There are similar problem if connectivity to B is muc= h=20 slower or less reliable than that to A. (3) has similar problems, though mirrored. Say we have a forked MSRP file=20 transfer from client to peers. If the client knew the "bandwidth quotient"= =20 between A and B, it could send data to each at appropriate speed. But it do= es=20 not, so the connection to B will fail, and only A will receive the file. This is all the same problem as with MSRP: one cannot multiplex multiple TC= P=20 sessions on a single TCP session, not directly. I am not an IETF congestion= =20 control expert, but it all comes down to the need for the TURN client to=20 maintain separate congestion control for each peers. And then, there is the separate issue of how do we not turn this multiple=20 connections "feature" into an open port service, which would allow running= =20 servers from behind a TURN relay. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 09:24: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 1IFriK-0007FV-AV; Tue, 31 Jul 2007 09:24:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFriI-0007FM-Kh for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 09:24:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFriI-0007FC-7v; Tue, 31 Jul 2007 09:24:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFriH-0001To-8m; Tue, 31 Jul 2007 09:24:38 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 69A6821185; Tue, 31 Jul 2007 15:24:36 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-6f-46af3814c655 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3333B21236; Tue, 31 Jul 2007 15:24:36 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 15:24:35 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 15:24:35 +0200 Message-ID: <46AF3813.1020105@ericsson.com> Date: Tue, 31 Jul 2007 15:24:35 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC References: <383711.88528.qm@web33304.mail.mud.yahoo.com> In-Reply-To: <383711.88528.qm@web33304.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 13:24:35.0134 (UTC) FILETIME=[23121DE0:01C7D376] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: behave@ietf.org, mmusic@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 Suresh, I would propose that you drop MMUSIC mailing listif responding to this as you appear to want to discuss the removal of a BEHAVE milestone, rather than ICE and its way forward. But I will leave it there to let the MMUSIC people see my response. It seems most of the issues in this discussion is between, what I at least thought was a specific way of performing the hole punching rather than the general concept that I acknowledge has existed since the creation of NATs. I will drop these items an respond to few of them. Pyda Srisuresh skrev: > --- Magnus Westerlund wrote: >> >> There also has been discussion about if there should be multiple >> solutions etc. But, to my knowledge the consensus also there has been >> that one solution is the way to go. >> > [suresh] I have not been part of the discussion pertaining to the merit of > multiple solutions vs single soultions. This may have been discussed in the > context of SIP and NAT traversal. So, I cant comment on this. Yes, that was in the context of ICE. As my email was about that. > >> So Suresh, you and everyone else as participants in the IETF is >> responsible for what you call HOLE PUNCHING TECHNIQUES are not an WG >> item. > > [suresh] Magnus - I dont know what you are talking about. How do you mean I am > responsible for why the HOLE PUNCHING TECHNIQUE draft is not a WG item. The > ford-behave-app draft has been around for many years since the inception of > BEHAVE. Last I checked, The application milestone is no longer on BEHVAE > charter. I certainly am not responsible for removign the milestone. This was written as reaction on how work gets done in the IETF. One or more proponents goes out and sell their idea so that enough people are interested to participate in the work on that idea. In cases the proponents are not succesful in getting traction for the idea it rarely goes anywhere. In the case of the ford-behave-app draft there has been no support for keeping the milestone or more important, do the work. > [suresh] Magnus - I have not been part of the consensus for ICE. However, I do > know ICE adapts the HOLE PUNCHING TECHNIQUES and the BCP recommendations > identified in ford-behave-app draft. Yet, neither of the ICE drafts (UDP or the > TCP version) refer the ford-behave-app draft or prior work on HOLE PUNCHING as > normative reference. This iS WRONG. > > I believe, the ICE drafts should refer the prior work (kegel work on UDP hole > punching, USENIX paper for TCP hole punching and ford-behave-app draft for > application traversal design) on which the ICE work is based. > I think you should review your sources here. The first version of ford-beahve-app was submitted february 2005. At that point STUN (RFC 3489 had been published in almost 2 years (March 2003). The first individual version of ICE was submitted to IETF february 2003. I am not going to untangle this, but if you are going down this path: Please have you facts right. I am not denying that work commonly builds up on others. And that it is common curtesy to reference such work. However, that is commonly done by an informative reference. Normative references are for things that you absolutely need to include to build interoperable implementations. Please do review IESG statement on references: http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt > On the one hand, IETF (IESG) has been adamant about the standard level of the > normative references for a proposes standard. Yet, it is ironic that when HOLE > PUNCHING is normative to the design of ICE, the IETF is not allowing the HOLE > PUNCHING work to be standardized. Once more a missunderstanding about what it means to be a normative reference in an RFC. > > Why is the IETF not allowing HOLE PUNCHING TECHNIQUES and P2P application > traversal identified in draft-ford-behave-app draft to move forward as a BCP WG > item? > As stated before. There is a clear lack of interest in this document. I wished there wasn't. But the fact is that no-one except you have really argued for it, not even your co-authors. We can't publish a document where no-one reads and reviews it and stil claim that their exist consensus behind it. Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 12:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFukV-0007pa-29; Tue, 31 Jul 2007 12:39:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFlCM-0007ev-J7 for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 02:27:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlCM-0007dp-7G for behave@ietf.org; Tue, 31 Jul 2007 02:27:14 -0400 Received: from moebius2.space.net ([195.30.1.100]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFlCL-0002qO-IQ for behave@ietf.org; Tue, 31 Jul 2007 02:27:14 -0400 Received: (qmail 67094 invoked by uid 1007); 31 Jul 2007 06:27:12 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=evSCBaXXzfpxcht0TrqAXQdCrR2NcC1DqZwvUYTPCnfEYGGl8vsTY/STgVU9pRk8 ; Date: Tue, 31 Jul 2007 08:27:12 +0200 From: Gert Doering To: Dan Wing Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Message-ID: <20070731062712.GA69215@Space.Net> References: <01D283D0-1FD0-4716-90B8-38086595C262@apple.com> <050701c7d309$a84e2b10$c5f0200a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <050701c7d309$a84e2b10$c5f0200a@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Tue, 31 Jul 2007 12:39:05 -0400 Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, On Mon, Jul 30, 2007 at 05:28:02PM -0700, Dan Wing wrote: > The only IPsec client implementation I'm aware of is Cisco's, and > I know our implementation does not provide automatic detection or > fallback from IPsec-over-IP to IPsec-over-UDP; rather, the user has > to select this themselves or be artificially limited to always use > UDP. IPsec-over-UDP is, of course, less bandwidth efficient than > IPsec-over-IP. This is again assuming "the IPSEC session is initiated outbound-only, and the IPSEC server (gateway, whatever) is in a corporate data center". In an end-to-end world, it may be desirable to have one residential user setup IPSEC to another residential user. Both behind such stateful firewalls that neither permit unsolicited inbound UDP. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 12:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFukV-0007q3-Al; Tue, 31 Jul 2007 12:39:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFlgZ-0007vW-Oc for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 02:58:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (EximFrom behave-bounces@ietf.org Tue Jul 31 12:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFukV-0007pa-29; Tue, 31 Jul 2007 12:39:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFlCM-0007ev-J7 for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 02:27:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlCM-0007dp-7G for behave@ietf.org; Tue, 31 Jul 2007 02:27:14 -0400 Received: from moebius2.space.net ([195.30.1.100]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFlCL-0002qO-IQ for behave@ietf.org; Tue, 31 Jul 2007 02:27:14 -0400 Received: (qmail 67094 invoked by uid 1007); 31 Jul 2007 06:27:12 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=evSCBaXXzfpxcht0TrqAXQdCrR2NcC1DqZwvUYTPCnfEYGGl8vsTY/STgVU9pRk8 ; Date: Tue, 31 Jul 2007 08:27:12 +0200 From: Gert Doering To: Dan Wing Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Message-ID: <20070731062712.GA69215@Space.Net> References: <01D283D0-1FD0-4716-90B8-38086595C262@apple.com> <050701c7d309$a84e2b10$c5f0200a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <050701c7d309$a84e2b10$c5f0200a@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Tue, 31 Jul 2007 12:39:05 -0400 Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, On Mon, Jul 30, 2007 at 05:28:02PM -0700, Dan Wing wrote: > The only IPsec client implementation I'm aware of is Cisco's, and > I know our implementation does not provide automatic detection or > fallback from IPsec-over-IP to IPsec-over-UDP; rather, the user has > to select this themselves or be artificially limited to always use > UDP. IPsec-over-UDP is, of course, less bandwidth efficient than > IPsec-over-IP. This is again assuming "the IPSEC session is initiated outbound-only, and the IPSEC server (gateway, whatever) is in a corporate data center". In an end-to-end world, it may be desirable to have one residential user setup IPSEC to another residential user. Both behind such stateful firewalls that neither permit unsolicited inbound UDP. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 12:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFukV-0007q3-Al; Tue, 31 Jul 2007 12:39:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFlgZ-0007vW-Oc for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 02:58:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlgW-0007vN-9E for behave@ietf.org; Tue, 31 Jul 2007 02:58:24 -0400 Received: from moebius2.space.net ([195.30.1.100]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFlgV-0003hC-LQ for behave@ietf.org; Tue, 31 Jul 2007 02:58:24 -0400 Received: (qmail 77764 invoked by uid 1007); 31 Jul 2007 06:58:22 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=TUdVA3FK1OktmgEDUG/deUzpMgrj3gWThmx9ENxg5En2Bl/BRdP8LjIGdAL0P0Br ; Date: Tue, 31 Jul 2007 08:58:22 +0200 From: Gert Doering To: Dan Wing Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Message-ID: <20070731065822.GB69215@Space.Net> References: <20070731062712.GA69215@Space.Net> <05b401c7d33e$10360fc0$c5f0200a@amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <05b401c7d33e$10360fc0$c5f0200a@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Tue, 31 Jul 2007 12:39:05 -0400 Cc: 'IPv6 Operations' , 'Behave WG' , 'Gert Doering' X-BeenThere: behave@ietf.org X-Mailman-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="===============0283191592==" Errors-To: behave-bounces@ietf.org --===============0283191592== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mpDMMNN3hoi9V8qC" Content-Disposition: inline --mpDMMNN3hoi9V8qC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jul 30, 2007 at 11:43:03PM -0700, Dan Wing wrote: > > In an end-to-end world, it may be desirable to have one residential > > user setup IPSEC to another residential user. Both behind=20 > > such stateful firewalls that neither permit unsolicited=20 > > inbound UDP. >=20 > In such a case, they need to communicate each others IP addresses > (and perhaps UDP ports) using a rendezvous protocol (such as SIP, > see draft-saito-mmusic-sdp-ike-01.txt) in order to allow one (or both) > to allow inbound UDP (or 'raw' IPsec), or the server would need to=20 > tell its firewall to permit unsolicited incoming traffic. Which seems to be the point of this discussion. "If we are going to=20 have stateful firewalls, due to popular belief that this is a good thing,= =20 how to tell the firewall that it should stop disturbing traffic". Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --mpDMMNN3hoi9V8qC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBRq7djqkuBuNlUUl1AQKZ3wP+OKGlyqnlUKVNmCZyXT5AV45vb8j+WUr0 kVIGqkxOOTX6pHV08ZefqDL0w+nUASjvWYXUqHGYGYmQaWHdRfsQ8DUH9fPV565w 3Y9jwAZhRyFDgxx9AELGmy+2/KlFI5PgqS52SSYrhMiy060ZARm/kCwCDwcF6O3G wwPaLiS8Am8= =Ehwy -----END PGP SIGNATURE----- --mpDMMNN3hoi9V8qC-- --===============0283191592== 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 --===============0283191592==-- 4.43) id 1IFlgW-0007vN-9E for behave@ietf.org; Tue, 31 Jul 2007 02:58:24 -0400 Received: from moebius2.space.net ([195.30.1.100]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFlgV-0003hC-LQ for behave@ietf.org; Tue, 31 Jul 2007 02:58:24 -0400 Received: (qmail 77764 invoked by uid 1007); 31 Jul 2007 06:58:22 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=TUdVA3FK1OktmgEDUG/deUzpMgrj3gWThmx9ENxg5En2Bl/BRdP8LjIGdAL0P0Br ; Date: Tue, 31 Jul 2007 08:58:22 +0200 From: Gert Doering To: Dan Wing Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Message-ID: <20070731065822.GB69215@Space.Net> References: <20070731062712.GA69215@Space.Net> <05b401c7d33e$10360fc0$c5f0200a@amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <05b401c7d33e$10360fc0$c5f0200a@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Tue, 31 Jul 2007 12:39:05 -0400 Cc: 'IPv6 Operations' , 'Behave WG' , 'Gert Doering' X-BeenThere: behave@ietf.org X-Mailman-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="===============0283191592==" Errors-To: behave-bounces@ietf.org --===============0283191592== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mpDMMNN3hoi9V8qC" Content-Disposition: inline --mpDMMNN3hoi9V8qC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jul 30, 2007 at 11:43:03PM -0700, Dan Wing wrote: > > In an end-to-end world, it may be desirable to have one residential > > user setup IPSEC to another residential user. Both behind=20 > > such stateful firewalls that neither permit unsolicited=20 > > inbound UDP. >=20 > In such a case, they need to communicate each others IP addresses > (and perhaps UDP ports) using a rendezvous protocol (such as SIP, > see draft-saito-mmusic-sdp-ike-01.txt) in order to allow one (or both) > to allow inbound UDP (or 'raw' IPsec), or the server would need to=20 > tell its firewall to permit unsolicited incoming traffic. Which seems to be the point of this discussion. "If we are going to=20 have stateful firewalls, due to popular belief that this is a good thing,= =20 how to tell the firewall that it should stop disturbing traffic". Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --mpDMMNN3hoi9V8qC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBRq7djqkuBuNlUUl1AQKZ3wP+OKGlyqnlUKVNmCZyXT5AV45vb8j+WUr0 kVIGqkxOOTX6pHV08ZefqDL0w+nUASjvWYXUqHGYGYmQaWHdRfsQ8DUH9fPV565w 3Y9jwAZhRyFDgxx9AELGmy+2/KlFI5PgqS52SSYrhMiy060ZARm/kCwCDwcF6O3G wwPaLiS8Am8= =Ehwy -----END PGP SIGNATURE----- --mpDMMNN3hoi9V8qC-- --===============0283191592== 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 --===============0283191592==-- From behave-bounces@ietf.org Tue Jul 31 12:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFukU-0007pR-Se; Tue, 31 Jul 2007 12:39:06 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFazK-0007rh-R0 for behave-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 15:33:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFazK-0007rY-G1 for behave@ietf.org; Mon, 30 Jul 2007 15:33:06 -0400 Received: from moebius2.space.net ([195.30.1.100]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFazJ-0007J6-OY for behave@ietf.org; Mon, 30 Jul 2007 15:33:06 -0400 Received: (qmail 38807 invoked by uid 1007); 30 Jul 2007 19:33:04 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=lI5OXxNWL807PQiy50sKDrJQZdwioTH7wzO3HjyY0RajRBjnCNRXILjHX+sAb1kz ; Date: Mon, 30 Jul 2007 21:33:04 +0200 From: Gert Doering To: Dan Wing Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Message-ID: <20070730193304.GV69215@Space.Net> References: <44BC323E-454C-4B96-A0A5-2840B20137C5@apple.com> <02ed01c7d2dd$f4b90500$c5f0200a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02ed01c7d2dd$f4b90500$c5f0200a@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Tue, 31 Jul 2007 12:39:05 -0400 Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, On Mon, Jul 30, 2007 at 12:15:11PM -0700, Dan Wing wrote: > Passive-mode FTP (using the "PASV" verb) has been supported on > all modern FTP clients and FTP servers for a long time (going on a > decade for most FTP clients and FTP servers). Passive-mode FTP > causes the TCP data connection to be initiated by the FTP client (as > is the TCP control connection), which eliminates the need for any ALG > or ALG-like function in NATs and in firewalls. Is there a reason > passive FTP can't simply be mandated for v6, so we can avoid FTP-aware > ALGs? Correct me if I'm wrong - but you'll need "firewall support" for PASV / EPSV ftp as well, just on the other side of the connection. If you run your server behind a firewall (which is a pretty common thing to do), and want to offer FTP services, the firewall needs to know which port to open for PASV connections. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 13:20:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvO1-0004CK-Vm; Tue, 31 Jul 2007 13:19:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFvO0-0004CA-7i for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 13:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvNz-0004C0-UL for behave@ietf.org; Tue, 31 Jul 2007 13:19:55 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFvNy-00086q-Hw for behave@ietf.org; Tue, 31 Jul 2007 13:19:55 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id 2C8EDD3A812; Tue, 31 Jul 2007 10:19:54 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 0D62130063; Tue, 31 Jul 2007 10:19:54 -0700 (PDT) X-AuditID: 11807125-a3220bb0000007e5-2c-46af6f390837 Received: from [17.206.23.199] (il0602a-dhcp71.apple.com [17.206.23.199]) by relay7.apple.com (Apple SCV relay) with ESMTP id E32EB30002; Tue, 31 Jul 2007 10:19:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <05b401c7d33e$10360fc0$c5f0200a@amer.cisco.com> References: <05b401c7d33e$10360fc0$c5f0200a@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85404457-04A1-4EBB-99F1-38F7965C2DD3@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Date: Tue, 31 Jul 2007 10:19:52 -0700 To: IPv6 Operations , Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Jul 30, 2007, at 23:43, Dan Wing wrote: > > ...or the server would need to tell its firewall to permit > unsolicited incoming traffic. It would be more accurate to describe that method like this: the server would need to solicit the firewall to permit 1) inbound IKE initiations from arbitrary remote addresses, and 2) IPsec ESP/AH flows for negotiated security associations. Neither of these two forms of traffic could reasonably be described as "unsolicited" in this case. -- james woodyatt member of technical staff, communications engineering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 13:46: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 1IFvnw-00051V-UK; Tue, 31 Jul 2007 13:46:44 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFvnv-000507-Fi for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 13:46:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvnv-0004zy-2y for behave@ietf.org; Tue, 31 Jul 2007 13:46:43 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFvnu-0002Br-L1 for behave@ietf.org; Tue, 31 Jul 2007 13:46:42 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2007 10:46:42 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADcSr0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,204,1183359600"; d="scan'208"; a="191881929:sNHT26021718" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6VHkf4B012223; Tue, 31 Jul 2007 10:46:41 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6VHkcTb012443; Tue, 31 Jul 2007 17:46:38 GMT From: "Dan Wing" To: "'james woodyatt'" , "'IPv6 Operations'" , "'Behave WG'" Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Tue, 31 Jul 2007 10:46:37 -0700 Message-ID: <07cc01c7d39a$c084c720$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfTlwm57akX8q/UTUWs9MXQ7CsTrQAAqPfQ In-Reply-To: <85404457-04A1-4EBB-99F1-38F7965C2DD3@apple.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1657; t=1185904001; x=1186768001; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20CPE=20equipments=20and=20stateful= 20filters |Sender:=20; bh=D7NdcvBCXHry+lanm35awuvJQeaDj7AVdXK8uXnnfhk=; b=Zupmiv73Q/MF0rJudQJ16cMWPi+b26hHNrm6ytfO2pVbIEdFFTd0LupHQ/GwjLOPzN9f/BqJ VEbA8BcH56WJDdSwkhXY5JKmyolHMINiU7/y9vuzbb7M8i9Jw6Xys5Cw; 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: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 > > ...or the server would need to tell its firewall to permit > > unsolicited incoming traffic. > > It would be more accurate to describe that method like this: the > server would need to solicit the firewall to permit 1) inbound IKE > initiations from arbitrary remote addresses, and 2) IPsec ESP/AH > flows for negotiated security associations. Agreed. > Neither of these two > forms of traffic could reasonably be described as "unsolicited" in > this case. We have different definitions of 'solicited traffic' and 'unsolicited traffic'. Other than opening a listener on UDP/500 for IKE (and telling the upstream firewall to please open a permission for incoming traffic), the host didn't do anything to solicit an incoming IKE packet. I call that incoming traffic 'unsolicited', because the host (and its firewall) are unaware of when a client will send a packet to establish a connection. An HTTP server or SMTP server fall into this category, for example. This differs from the SIP model and the RTSP 2.0 model. In both SIP and RTSP 2.0, an offer/answer exchange allows the server to learn the client desires a new session. With that knowledge, the server can communicate more specific information to its firewall about the client's IP address; in this way, the firewall doens't need to necessarily permit incoming IKE packets from arbitrary remote addresses, unless those are first signaled with SIP or RTSP. This model is also used by HIP and EME, two working groups in the IRTF (www.irtf.org). This is what I would consider 'solicited traffic'. What are your definitions? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 15:08: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 1IFx50-0001Hf-MM; Tue, 31 Jul 2007 15:08:26 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFx4y-0001HF-Bj for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 15:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFx4y-0001H6-2F for behave@ietf.org; Tue, 31 Jul 2007 15:08:24 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFx4w-0002VD-HX for behave@ietf.org; Tue, 31 Jul 2007 15:08:24 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id 3BB25D3CEDE; Tue, 31 Jul 2007 12:08:22 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 263F9300DB; Tue, 31 Jul 2007 12:08:22 -0700 (PDT) X-AuditID: 11807125-a4222bb0000007e5-9c-46af88a63841 Received: from [17.206.23.199] (il0602a-dhcp71.apple.com [17.206.23.199]) by relay7.apple.com (Apple SCV relay) with ESMTP id 12A9D300A5; Tue, 31 Jul 2007 12:08:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <07cc01c7d39a$c084c720$c5f0200a@amer.cisco.com> References: <07cc01c7d39a$c084c720$c5f0200a@amer.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <7F8C0FAB-FD1D-4600-976A-3785A7CA57D1@apple.com> Content-Transfer-Encoding: quoted-printable From: james woodyatt Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Date: Tue, 31 Jul 2007 12:08:21 -0700 To: IPv6 Operations , Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Jul 31, 2007, at 10:46, Dan Wing wrote: > [ I wrote: ] >> Neither of these two forms of traffic could reasonably be =20 >> described as "unsolicited" in this case. > > We have different definitions of 'solicited traffic' and =20 > 'unsolicited traffic'. That seems to be the case. > What are your definitions? I have a more human-centered view of what it means for traffic to be =20 solicited: if a human network administrator is expecting the traffic, =20= then any protocol or method initiated by an administrator for the =20 purpose of enabling an exception to the "denial by default" policy is =20= an explicit solicitation. For example, an HTTP or SMTP server could solicit inbound connections =20= by sending an NSLP CREATE/EXT message to the appropriate NSIS =20 responder. A more common scenario might be the case where an Apple =20 File Sharing (AFP) protocol server advertises a DNS-SD record with =20 wide-area Bonjour=99 and opens an IPv4/NAT translation for it with NAT-=20= PMP. -- james woodyatt member of technical staff, communications engineering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 15:12:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFx99-0003P3-R1; Tue, 31 Jul 2007 15:12:43 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFx98-0003Ol-5P for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 15:12:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFx97-0003Oc-QH for behave@ietf.org; Tue, 31 Jul 2007 15:12:41 -0400 Received: from submit01.sysedata.no ([195.159.29.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFx97-0004FN-68 for behave@ietf.org; Tue, 31 Jul 2007 15:12:41 -0400 Received: from [84.215.127.238] (helo=[10.0.0.4]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1IFx93-0003h8-72; Tue, 31 Jul 2007 21:12:37 +0200 Message-ID: <46AF8AB1.5090401@db.org> Date: Tue, 31 Jul 2007 21:17:05 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.12 (X11/20070606) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [BEHAVE] TURN: technical review by September 1 References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com> In-Reply-To: <200707311216.18858.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'Rohan Mahy' , behave@ietf.org, ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi I would agree with Rémi, that multiple peers per TURN client is a complex scenario and I think the use-case for this must be reviewed. The "Connection Status Indication" and the CONNECT_STAT attribute can only indicate status of one (1) connection, and there is no way of mapping which connection is indicated. This means that TCP connections can only be setup one at a time. I do not see a real use-case for multiple TCP/UDP peers per TURN client, so my apologies if there are already many good use-cases for this, but I think that TURN can be made much simpler if we only allow one peer per TURN client. If a User-Agent wants two "channels", he can just start two different TURN clients on the same host, but listening on different ports. /alfred Rémi Denis-Courmont wrote: > Hey, > > Rohan pointed out that congestion handling when there are multiple TCP > sessions to remote peers was an open issue. > > As far as I can tell, there is NO WAY to solve this, so long as we use a > single TCP session between the client and the TURN server. It is inherent to > how TCP works, and is the exact same issue that MSRP relays have. Regardless > whether that breaks forking, I really think we simply cannot do that > properly. > > Take this scenario: > > TURN client <-- TCP_C --> TURN server <-- TCP_A --> Peer A > <-- TCP_B --> Peer B > > Now consider that TCP_B session gets congested. At some point, TURN server > output buffer for TCP_B gets full. Now so long as the client only sends data > to peer A, every thing is fine. But if the client sends data to peer B, the > TURN server gets stuck. > > At this point, the server really can only do one of three things: > (1) queue an indefinitely big amount of data, > (2) stop dequeing data from the TURN client until TCP_B gets "decongested", > (3) drop data for B, and reset/timeout connection with B. > > (1) is basically what MSRP does. Im my humble opinion, it is utterly broken; > and I think we agreed this was not the way to go. > > (2) is flawed, as communication between client and peer A will be unduly > disrupted. It is an obvious security issue if A and B do not trust each > others. Even then, it is probably unacceptable: if say, B looses connectivity > for some reason, the flow to A will be totally disrupted until TCP_B > connection times out. There are similar problem if connectivity to B is much > slower or less reliable than that to A. > > (3) has similar problems, though mirrored. Say we have a forked MSRP file > transfer from client to peers. If the client knew the "bandwidth quotient" > between A and B, it could send data to each at appropriate speed. But it does > not, so the connection to B will fail, and only A will receive the file. > > > This is all the same problem as with MSRP: one cannot multiplex multiple TCP > sessions on a single TCP session, not directly. I am not an IETF congestion > control expert, but it all comes down to the need for the TURN client to > maintain separate congestion control for each peers. > > > And then, there is the separate issue of how do we not turn this multiple > connections "feature" into an open port service, which would allow running > servers from behind a TURN relay. > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 15:41: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 1IFxaX-0004bl-Sp; Tue, 31 Jul 2007 15:41:01 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IFxaV-0004ac-SD for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 15:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFxaV-0004aU-IU for behave@ietf.org; Tue, 31 Jul 2007 15:40:59 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFxaU-0003gH-78 for behave@ietf.org; Tue, 31 Jul 2007 15:40:59 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id E5BCB2C04E; Tue, 31 Jul 2007 15:40:57 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lorB2VZOp2Zx; Tue, 31 Jul 2007 15:40:56 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 9FE872C032; Tue, 31 Jul 2007 15:40:56 -0400 (EDT) In-Reply-To: <07cc01c7d39a$c084c720$c5f0200a@amer.cisco.com> To: "Dan Wing" Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Tue, 31 Jul 2007 15:40:53 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/31/2007 03:40:54 PM, Serialize complete at 07/31/2007 03:40:54 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: 'IPv6 Operations' , 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1961381609==" Errors-To: behave-bounces@ietf.org This is a multipart message in MIME format. --===============1961381609== Content-Type: multipart/alternative; boundary="=_alternative 006C1D1085257329_=" This is a multipart message in MIME format. --=_alternative 006C1D1085257329_= Content-Type: text/plain; charset="US-ASCII" YES! Definitions are very important here, or we'll wind up talking in circles. > ... We have different definitions of 'solicited traffic' and > 'unsolicited traffic'. ... Interesting observations Dan. The differences are around what prior knowledge is available. I think it can be generalized and expanded. (Whipping out my handy dictionary.) > I call that incoming traffic [intentionally listened for] > 'unsolicited', because the host (and its firewall) are unaware > of when [or from where] a client will send a packet to establish > a connection. "Unsolicited" does seem to be a good term for this category. Perhaps "Expected" would be a good characterization also. > ... [some protocol] exchange allows the > server to learn the client desires a new session. With that > knowledge, the server can communicate more specific information > to its firewall about the client's IP address [and timing > of the required pihole]; ... This is what I would > consider 'solicited traffic'. Yup, "Solicited". "Negotiated" or "Signalled" might also be appropriate terms. Note also, the actual signalling, leading up to the Solicited traffic, may well have been some other category. I would add: "Unexpected / unwanted" -- traffic which was not explicitly indicated as ready to receive, either by listening at the server and (potentially) opening the corresponding pinhole in the firewall (either of Unsolicited or Solicited above), or by client initiation (next). This is the "bad stuff" that should be dropped on the floor. "(Client) Initiated" -- traffic that started from the "inside", by the client. Just typing out loud... -- Peter Blatherwick "Dan Wing" Sent by: owner-v6ops@ops.ietf.org 31.07.07 13:46 To: "'james woodyatt'" , "'IPv6 Operations'" , "'Behave WG'" cc: Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters > > ...or the server would need to tell its firewall to permit > > unsolicited incoming traffic. > > It would be more accurate to describe that method like this: the > server would need to solicit the firewall to permit 1) inbound IKE > initiations from arbitrary remote addresses, and 2) IPsec ESP/AH > flows for negotiated security associations. Agreed. > Neither of these two > forms of traffic could reasonably be described as "unsolicited" in > this case. We have different definitions of 'solicited traffic' and 'unsolicited traffic'. Other than opening a listener on UDP/500 for IKE (and telling the upstream firewall to please open a permission for incoming traffic), the host didn't do anything to solicit an incoming IKE packet. I call that incoming traffic 'unsolicited', because the host (and its firewall) are unaware of when a client will send a packet to establish a connection. An HTTP server or SMTP server fall into this category, for example. This differs from the SIP model and the RTSP 2.0 model. In both SIP and RTSP 2.0, an offer/answer exchange allows the server to learn the client desires a new session. With that knowledge, the server can communicate more specific information to its firewall about the client's IP address; in this way, the firewall doens't need to necessarily permit incoming IKE packets from arbitrary remote addresses, unless those are first signaled with SIP or RTSP. This model is also used by HIP and EME, two working groups in the IRTF (www.irtf.org). This is what I would consider 'solicited traffic'. What are your definitions? -d --=_alternative 006C1D1085257329_= Content-Type: text/html; charset="US-ASCII"
YES!  Definitions are very important here, or we'll wind up talking in circles.  

> ... We have different definitions of 'solicited traffic' and
> 'unsolicited traffic'. ...

Interesting observations Dan.  The differences are around what prior knowledge is available.  I think it can be generalized and expanded.  (Whipping out my handy dictionary.)  

> I call that incoming traffic [intentionally listened for]
> 'unsolicited', because the host (and its firewall) are unaware
> of when [or from where] a client will send a packet to establish
> a connection.

"Unsolicited" does seem to be a good term for this category.  Perhaps "Expected" would be a good characterization also.  

> ... [some protocol] exchange allows the
> server to learn the client desires a new session.  With that
> knowledge, the server can communicate more specific information
> to its firewall about the client's IP address [and timing
> of the required pihole]; ...  This is what I would
> consider 'solicited traffic'.

Yup, "Solicited".  "Negotiated" or "Signalled" might also be appropriate terms.    Note also, the actual signalling, leading up to the Solicited traffic, may well have been some other category.  

I would add:

"Unexpected / unwanted" -- traffic which was not explicitly indicated as ready to receive, either by listening at the server and (potentially) opening the corresponding pinhole in the firewall (either of Unsolicited or Solicited above), or by client initiation (next).   This is the "bad stuff" that should be dropped on the floor.  

"(Client) Initiated" -- traffic that started from the "inside", by the client.  

Just typing out loud...

-- Peter Blatherwick





"Dan Wing" <dwing@cisco.com>
Sent by: owner-v6ops@ops.ietf.org

31.07.07 13:46

       
        To:        "'james woodyatt'" <jhw@apple.com>, "'IPv6 Operations'" <v6ops@ops.ietf.org>, "'Behave WG'" <behave@ietf.org>
        cc:        
        Subject:        RE: [BEHAVE] Re: CPE equipments and stateful filters



> > ...or the server would need to tell its firewall to permit  
> > unsolicited incoming traffic.
>
> It would be more accurate to describe that method like this: the  
> server would need to solicit the firewall to permit 1) inbound IKE  
> initiations from arbitrary remote addresses, and 2) IPsec ESP/AH  
> flows for negotiated security associations.

Agreed.

> Neither of these two  
> forms of traffic could reasonably be described as "unsolicited" in  
> this case.

We have different definitions of 'solicited traffic' and
'unsolicited traffic'.  Other than opening a listener on UDP/500
for IKE (and telling the upstream firewall to please open a
permission for incoming traffic), the host didn't do anything to
solicit an incoming IKE packet.  I call that incoming traffic
'unsolicited', because the host (and its firewall) are unaware
of when a client will send a packet to establish a connection.
An HTTP server or SMTP server fall into this category, for
example.


This differs from the SIP model and the RTSP 2.0 model.  In
both SIP and RTSP 2.0, an offer/answer exchange allows the
server to learn the client desires a new session.  With that
knowledge, the server can communicate more specific information
to its firewall about the client's IP address; in this way, the
firewall doens't need to necessarily permit incoming IKE packets
from arbitrary remote addresses, unless those are first signaled
with SIP or RTSP.  This model is also used by HIP and EME, two
working groups in the IRTF (www.irtf.org).  This is what I would
consider 'solicited traffic'.


What are your definitions?

-d
--=_alternative 006C1D1085257329_=-- --===============1961381609== 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 --===============1961381609==-- From behave-bounces@ietf.org Tue Jul 31 18:51: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 1IG0Yt-0002IQ-UE; Tue, 31 Jul 2007 18:51:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IG0Ys-0002IF-8W for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 18:51:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG0Yr-0002I6-VA for behave@ietf.org; Tue, 31 Jul 2007 18:51:29 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG0Yr-0008HP-Hw for behave@ietf.org; Tue, 31 Jul 2007 18:51:29 -0400 Received: by wa-out-1112.google.com with SMTP id j37so26592waf for ; Tue, 31 Jul 2007 15:51:28 -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=S9SQxSH1j0usN6Lt5lEC5+25d2KNCjxk+Y5u8M+Ek8qPnMTkchPPOcReotvrDtqT+eRNwenIBcQyH5URHcraXFQlrElSEGbrj31aqjKAQSgMysUQ9B7PWW+qnjw5Z/n+kl3HzuuswXaPat77B2YZHBGOJgRtet0PB/WGlX1LYXk= 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=lv7KOlM6IF199jisTLYsae7lr+khnTanC8XVQsBNYgisXeo01xSk270iRIxWxb8XyUJn0cmEvDCaUHggdzhyjpwsfY1txzzd1C0hp5CrvDyAgAUCTtqS7uDxwD+W6Q4UY+PNYJvOUdfULe0FKcIsm3wS4aC27LT/mniBCE/FzZ0= Received: by 10.114.171.1 with SMTP id t1mr63091wae.1185922287048; Tue, 31 Jul 2007 15:51:27 -0700 (PDT) Received: by 10.114.95.13 with HTTP; Tue, 31 Jul 2007 15:51:26 -0700 (PDT) Message-ID: Date: Wed, 1 Aug 2007 08:51:27 +1000 From: "Evgeniy Khramtsov" To: "Alfred E. Heggestad" Subject: Re: [BEHAVE] TURN: technical review by September 1 In-Reply-To: <46AF8AB1.5090401@db.org> MIME-Version: 1.0 References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com> <46AF8AB1.5090401@db.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Rohan Mahy , ext Dan Wing , 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="===============0142696093==" Errors-To: behave-bounces@ietf.org --===============0142696093== Content-Type: multipart/alternative; boundary="----=_Part_64708_29207020.1185922287003" ------=_Part_64708_29207020.1185922287003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2007/8/1, Alfred E. Heggestad : > I do not see a real use-case for multiple TCP/UDP peers per TURN client, > so my apologies if there are already many good use-cases for this, but I > think that TURN can be made much simpler if we only allow one peer per > TURN client. If a User-Agent wants two "channels", he can just start > two different TURN clients on the same host, but listening on different > ports. Completely agree with you. ------=_Part_64708_29207020.1185922287003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2007/8/1, Alfred E. Heggestad <aeh@db.org>:
I do not see a real use-case for multiple TCP/UDP peers per TURN client,
so my apologies if there are already many good use-cases for this, but I
think that TURN can be made much simpler if we only allow one peer per
TURN client. If a User-Agent wants two "channels", he can just start
two different TURN clients on the same host, but listening on different
ports.

Completely agree with you.
------=_Part_64708_29207020.1185922287003-- --===============0142696093== 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 --===============0142696093==-- From behave-bounces@ietf.org Tue Jul 31 21:02: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 1IG2bK-0001s9-Hr; Tue, 31 Jul 2007 21:02:10 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IG2bI-0001s4-Un for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 21:02:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2bI-0001rv-Jy for behave@ietf.org; Tue, 31 Jul 2007 21:02:08 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG2bI-0003po-4W for behave@ietf.org; Tue, 31 Jul 2007 21:02:08 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 31 Jul 2007 18:02:07 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.70.16) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.726.0; Tue, 31 Jul 2007 18:02:07 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com (157.54.62.24) by TK5-EXMLT-W601.wingroup.windeploy.ntdev.microsoft.com (157.54.70.16) with Microsoft SMTP Server id 8.1.122.1; Tue, 31 Jul 2007 18:02:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters Date: Tue, 31 Jul 2007 18:01:44 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0640547EE7A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <07cc01c7d39a$c084c720$c5f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: CPE equipments and stateful filters Thread-Index: AcfTlwm57akX8q/UTUWs9MXQ7CsTrQAAqPfQAAR+eMA= References: <85404457-04A1-4EBB-99F1-38F7965C2DD3@apple.com> <07cc01c7d39a$c084c720$c5f0200a@amer.cisco.com> From: Christian Huitema To: Dan Wing , james woodyatt , IPv6 Operations , Behave WG X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > We have different definitions of 'solicited traffic' and > 'unsolicited traffic'. Other than opening a listener on UDP/500 > for IKE (and telling the upstream firewall to please open a > permission for incoming traffic), the host didn't do anything to > solicit an incoming IKE packet. I call that incoming traffic > 'unsolicited', because the host (and its firewall) are unaware > of when a client will send a packet to establish a connection. > An HTTP server or SMTP server fall into this category, for > example. It makes a ton of sense to just leave the IKE port (UDP 500) open. IKE is a fairly robust protocol, with built in protection against DOS. It is part of the security suite, and thus the software implementations tend to be scrutinized and well tested. At the end of the IKE exchange, the parties have identified each other, and have made a conscious decision to authorize the communication. Clearly, the follow on traffic may be "unsolicited", but it will not come from random parties. Leaving port 500 open looks like good engineering! -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jul 31 23:01: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 1IG4TA-0003in-2g; Tue, 31 Jul 2007 23:01:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IG4T9-0003if-0F for behave-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 23:01:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG4T8-0003iX-Lo for behave@ietf.org; Tue, 31 Jul 2007 23:01:50 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG4T8-0006SX-4J for behave@ietf.org; Tue, 31 Jul 2007 23:01:50 -0400 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id 804D3D45AED; Tue, 31 Jul 2007 20:01:49 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 6A0EC40080; Tue, 31 Jul 2007 20:01:49 -0700 (PDT) X-AuditID: 11807126-a6c47bb0000007e3-8f-46aff79d4b24 Received: from [17.206.23.199] (il0602a-dhcp71.apple.com [17.206.23.199]) by relay8.apple.com (Apple SCV relay) with ESMTP id 5462540053; Tue, 31 Jul 2007 20:01:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640547EE7A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <85404457-04A1-4EBB-99F1-38F7965C2DD3@apple.com> <07cc01c7d39a$c084c720$c5f0200a@amer.cisco.com> <70C6EFCDFC8AAD418EF7063CD132D0640547EE7A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters Date: Tue, 31 Jul 2007 20:01:49 -0700 To: IPv6 Operations , Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Jul 31, 2007, at 18:01, Christian Huitema wrote: > > It makes a ton of sense to just leave the IKE port (UDP 500) open. I agree. I think says to do this. If it doesn't, then the next revision (coming soon) will say it. The argument against doing this, which I've heard at least one WG Chairman offer me, is that leaving any port or protocol open to all inbound traffic exposes the interior network to denial of bandwidth attacks (along with potentially draining the batteries of portables in power-save mode). The more I've thought about that problem, the more I've come to believe that using stateful filtering middleboxes to counter the threat is like responding to the possibility of your house eventually being attacked by a swarm of mosquitos by always keeping your living room filled with carbon monoxide. Yes, you've prevented the mosquitos, but you've also denied yourself access to your living room. The traditional way you control mosquito populations is with taxpayer- funded pest control services going through the neighborhood, spraying insecticide into all the standing water collectors to keep them from breeding. Something similar to that, I think, is the proper way to engineer an Internet pest control program. If I ruled the world with an iron fist, operating a zombie-- even unknowingly-- would get your IP dial-tone terminated at your demarcation point, and you'd have to submit to an audit to get it turned back on again. Carriers who didn't do this would see their peering jeopardized, then degraded, and finally dumped, with their contracts thrown into liquidated damages. Failure to police your peering points would be grounds for operators in the DFZ to apply filters, limiters and/or delays on your prefixes in the global routing tables. Operators who didn't like this could complain to their governments, which would then decide whether and how to go to the World Trade Organization. When the zombie apocalypse hits, I want all the walking dead to be nuked from space. It's the only way to be sure. Alas, I don't rule the world. We'll probably be stuck with a solution much more jackbooted and less effective. Like stateful filtering middleboxes that have to be told to open pinholes for the IKE port. -- james woodyatt member of technical staff, communications engineering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave