From exim@www1.ietf.org Wed Oct 1 20:39:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12362 for ; Wed, 1 Oct 2003 20:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4rUm-0007q4-H7 for midcom-archive@odin.ietf.org; Wed, 01 Oct 2003 20:39:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h920d44U030126 for midcom-archive@odin.ietf.org; Wed, 1 Oct 2003 20:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4rUj-0007pf-2l; Wed, 01 Oct 2003 20:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4rTn-0007mT-Sj for midcom@optimus.ietf.org; Wed, 01 Oct 2003 20:38:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12292; Wed, 1 Oct 2003 20:36:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4rSp-0007em-00; Wed, 01 Oct 2003 20:37:03 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1A4rSp-0007eD-00; Wed, 01 Oct 2003 20:37:03 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 17:36:33 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Oct 2003 17:36:33 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Oct 2003 17:36:33 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 17:36:32 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 1 Oct 2003 17:36:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] I-D ACTION:draft-ford-midcom-p2p-00.txt Date: Wed, 1 Oct 2003 17:36:26 -0700 Message-ID: Thread-Topic: [midcom] I-D ACTION:draft-ford-midcom-p2p-00.txt thread-index: AcOGwVLzfcWnlnkJSlaKyccNW6pGjwBu3dCg From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 02 Oct 2003 00:36:32.0099 (UTC) FILETIME=[39F28330:01C3887D] Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable After reading that draft, may I offer a few comments? The draft contains a very good survey of the existing techniques, and then three sections that are not descriptive: the proposal of a new IP option, recommendations for applications developers, and recommendations for NAT designers. Out of these three sections, two are quite sound, as they follow directly from the survey -- the recommendations to applications and NAT. The description of the IP option, however, is sure to generate a lot of discussion and controversy. Could it be moved to a separate draft? > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, September 29, 2003 12:38 PM > Cc: midcom@ietf.org > Subject: [midcom] I-D ACTION:draft-ford-midcom-p2p-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Peer-to-Peer communication across Middleboxes > Author(s) : B. Ford, P. Srisuresh, D. Kegel > Filename : draft-ford-midcom-p2p-00.txt > Pages : 28 > Date : 2003-9-29 >=20 > This memo documents the methods which the current peer-to-peer > (P2P) applications use to communicate in the presence of > middleboxes such as firewalls and network address translators > (NAT). Further, the document proposes a new middlebox IP option > to allow deployment of P2P applications more effectively without > significant rework on the middleboxes or the applications. The > goal of this document is to enable immediate, wider deployment > of P2P applications without requiring the use of special proxy, > relay or midcom protocols, while not precluding their use. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ford-midcom-p2p-00.txt >=20 > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. >=20 > 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-ford-midcom-p2p-00.txt". >=20 > 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 >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ford-midcom-p2p-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different 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. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 2 10:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22398 for ; Thu, 2 Oct 2003 10:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54ck-0002kh-PG for midcom-archive@odin.ietf.org; Thu, 02 Oct 2003 10:40:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92EeAbP010573 for midcom-archive@odin.ietf.org; Thu, 2 Oct 2003 10:40:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54cd-0002jx-Va; Thu, 02 Oct 2003 10:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54c7-0002j9-0U for midcom@optimus.ietf.org; Thu, 02 Oct 2003 10:39:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22299 for ; Thu, 2 Oct 2003 10:39:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54c4-0001M5-00 for midcom@ietf.org; Thu, 02 Oct 2003 10:39:28 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A54c3-0001LK-00 for midcom@ietf.org; Thu, 02 Oct 2003 10:39:28 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h92Ecpf7011174 for ; Thu, 2 Oct 2003 16:38:56 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h92EbmaN011160 for ; Thu, 2 Oct 2003 16:37:48 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h92Ebmev011158; Thu, 02 Oct 2003 16:37:48 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AC72C340ED; Thu, 2 Oct 2003 16:06:31 +0200 (CEST) Date: Thu, 02 Oct 2003 16:37:44 +0200 From: Martin Stiemerling To: Tom Taylor Cc: midcom@ietf.org Subject: Re: [midcom] Reminder: wg last call Message-ID: <190470000.1065105464@n-stiemerling.office> In-Reply-To: <3F6DA88F.6000104@nortelnetworks.com> References: <20030920182150.12453.qmail@web40412.mail.yahoo.com> <3F6DA88F.6000104@nortelnetworks.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, --On Sunday, September 21, 2003 09:33:03 -0400 Tom Taylor wrote: [...] |> |> Even if the agent was using an address in the range of 10.1.0.0/16 - say, |> 10.1.0.1, and the agent obtains an address, say X1.1, the middlebox has |> no way to know that all sessions from 10.1.0.1 have to be bound to X1.1. |> The agent might create a BIND (using PER) at a later time. But, prior to |> this, if NAT sees any session originating from 10.1.0.1, it would bind |> the address to one of the available addresses within X1/8 (different |> from X1.1, as X1.1 is reseved by an agent). Now, lots of chaos ensues |> because, the PER from the agent would fail. |> | | [PTT] This one is definitely a concern. It seems to me we have to | specify in the semantics of PRR that if a reservation is made, it must be | honoured in subsequent sessions set up automatically by the middlebox | (need better words). In the context of your particular example, if the | middlebox assigns address X1.1 (as address A2) to 10.1.0.1 (address A0) | as a result of PRR, then while the reservation holds, any subsequent | BINDs for sessions from 10.1.0.1 must use address X1.1. We have added this text to the PRR section: "Once a PRR transaction has reserved an outside address (A2) for an internal end point (A0) at the middlebox, the middlebox must ensure that this reserved A2 is available in any subsequent PER and PRR transaction." Martin | | [PTT - implementation details snipped] |> |> Now, let us consider the case of PER transaction(section 2.3.8). PER in |> the context of a NAT refers to the agent creating a NAT binding with |> specific parameters. This will fail if the prameters specified in the |> bind-create request donot correspond to one or more (in the case of |> twice-NAT) address map entries. Without reference of an address map |> entry, the agent has no knowledge of whether to request for an address |> bind or a port bind. Further, the binding is meaningless without the |> exact session description to a symmetric NAPT. This is because symmetric |> NAPT uses different port bindings for the same (private IP address, |> port) tuple used in different sessions. The port bind may work only for |> the first session that originates from (provate IP address, port). There |> are other caveats. Without a PRR preceding the PER, how is the PER to |> know what external address to bound to? Why not let the middlebox select |> the external address to bound to? |> |> This is why I suggested the tansactions CreateBind, CreateportBind, |> RequestCreateBind, and RequestCreatePortBind to create binds |> unequivocally. These transactions use address map as an argument. Either |> the agent or the middlebox can create a bind. | | [PTT] You are arguing that if the agent knows the map entries, it can | request the specific binding that it needs. I'll put it the other way: | the current PER parameters include the internal endpoint address A0, the | external endpoint address A3, and, if a PRR was performed previously, a | reference to the A1 and A2 assignments that resulted from that PRR. What | other information does the middlebox need to complete the bind? | |> |> Creating binds is not adequate. The agent needs to be able to specify the |> permitted sessions as well. Without going into the details, i will simply |> suggest FTP(TCP based) and TFTP(UDP based) are examples of this. |> | [PTT] I want to carry on further discussion of this point with a clear | understanding of your terminology. Please indicate what additional | parameters distinguish a session from a bind. | | [PTT - remainder snipped] | Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 2 10:45:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22571 for ; Thu, 2 Oct 2003 10:45:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54hT-00033K-93 for midcom-archive@odin.ietf.org; Thu, 02 Oct 2003 10:45:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Ej3sN011717 for midcom-archive@odin.ietf.org; Thu, 2 Oct 2003 10:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54hS-00032Z-Gl; Thu, 02 Oct 2003 10:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54h7-0002zc-CJ for midcom@optimus.ietf.org; Thu, 02 Oct 2003 10:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22543 for ; Thu, 2 Oct 2003 10:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54h4-0001Pb-00 for midcom@ietf.org; Thu, 02 Oct 2003 10:44:39 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A54h3-0001Oy-00 for midcom@ietf.org; Thu, 02 Oct 2003 10:44:38 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h92Ei6ev011604 for ; Thu, 2 Oct 2003 16:44:06 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 03972D2CDC for ; Thu, 2 Oct 2003 16:12:50 +0200 (CEST) Date: Thu, 02 Oct 2003 16:44:02 +0200 From: Martin Stiemerling To: midcom@ietf.org Message-ID: <198720000.1065105842@n-stiemerling.office> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [midcom] Changes in semantics (Version 05) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello folks, I have submitted an updated version of the semantics (Version 05). The version is available in advance here: ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-midcom-semantics-05.t xt The changes in this version are: - Policy Rule List (PRL) and Policy Rule Status (PRS) are now mandatory. (Based on comments from Juergen Schoenwaelder) - Fixed comments from Daniel - Text in Section 2.1.8 - Figure 2, (mc=0) inserted text before Figure 2 - Text in 2.3.6 about IPv4 and IPv6 changed - in PRR mode parameter changed to service parameter, adapted text on middlebox modes - Fixed failure text in RLC - fixed all text errors - added middlebox (NAT) policy rule idle-timeout to middlebox's capabilities with a link to ARE - added 'optional interface specific policy rules' capability to capability list - inserted new chapter "Interface specific Policy Rules" - adapted references in whole text to the new numbering due to issue one above - added optional inside/outside interface parameter to PRS (2.3.12) - added optional inside/outside interface parameter to PRR (2.3.8) - added to request parameter list - added corresponding failure reasons - added semantical descriptions - added optional inside/outside interface parameter to PER (2.3.8) - added to request parameter list - added corresponding failure reasons - added semantical descriptions - added statements in conformance section - checked spelling - added A0 parameter to PRR transaction (Pyda's comment) - added PRR/A0 statement to PER - added text about Pyda's concern w.r.t. reserved outside NATed addresses in PRR : Once a PRR transaction has reserved an outside address (A2) for an internal end point (A0) at the middlebox, the middlebox must ensure that this reserved A2 is available in any subsequent PER and PRR transaction. - added paragraph about NAT terminology in terminology section - revised examples to reflect changes in semantics With best regards Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 2 10:56:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23692 for ; Thu, 2 Oct 2003 10:56:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54s8-0004EA-T0 for midcom-archive@odin.ietf.org; Thu, 02 Oct 2003 10:56:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Eu4dC016233 for midcom-archive@odin.ietf.org; Thu, 2 Oct 2003 10:56:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54s6-0004DJ-57; Thu, 02 Oct 2003 10:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54re-0004CJ-27 for midcom@optimus.ietf.org; Thu, 02 Oct 2003 10:55:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23619 for ; Thu, 2 Oct 2003 10:55:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54rb-0001ZX-00 for midcom@ietf.org; Thu, 02 Oct 2003 10:55:31 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A54rZ-0001Yo-00 for midcom@ietf.org; Thu, 02 Oct 2003 10:55:29 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h92EsvXg010299 for ; Thu, 2 Oct 2003 07:54:57 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMT10005; Thu, 2 Oct 2003 07:54:55 -0700 (PDT) Date: Thu, 2 Oct 2003 10:54:53 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Subject: Fwd: [midcom] Changes in semantics (Version 05) From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <618AD9F4-F4E8-11D7-9105-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't think we need to go through full WG last call on this revision before sending it to the IESG, but I'd like to give participants a few days to look it over and raise any objections they may have. So, if no concerns are raised by the end-of-business on Monday, 5 October, I'll be forwarding the document to the IESG for review next week. At a minimum, please look at the changes that Martin has listed. Thanks, Melinda Begin forwarded message: > From: Martin Stiemerling > Date: Thu Oct 2, 2003 10:44:02 AM US/Eastern > To: midcom@ietf.org > Subject: [midcom] Changes in semantics (Version 05) > > Hello folks, > > I have submitted an updated version of the semantics (Version 05). The > version is available in advance here: > > ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-midcom- > semantics-05.t > xt > > The changes in this version are: > > - Policy Rule List (PRL) and Policy Rule Status (PRS) are now > mandatory. > (Based on comments from Juergen Schoenwaelder) > > - Fixed comments from Daniel > - Text in Section 2.1.8 > - Figure 2, (mc=0) inserted text before Figure 2 > - Text in 2.3.6 about IPv4 and IPv6 changed > - in PRR mode parameter changed to service parameter, adapted text > on middlebox modes > - Fixed failure text in RLC > - fixed all text errors > > - added middlebox (NAT) policy rule idle-timeout to middlebox's > capabilities > with a link to ARE > - added 'optional interface specific policy rules' capability to > capability list > - inserted new chapter "Interface specific Policy Rules" > - adapted references in whole text to the new numbering due to issue > one > above > - added optional inside/outside interface parameter to PRS (2.3.12) > - added optional inside/outside interface parameter to PRR (2.3.8) > - added to request parameter list > - added corresponding failure reasons > - added semantical descriptions > - added optional inside/outside interface parameter to PER (2.3.8) > - added to request parameter list > - added corresponding failure reasons > - added semantical descriptions > - added statements in conformance section > - checked spelling > - added A0 parameter to PRR transaction (Pyda's comment) > - added PRR/A0 statement to PER > - added text about Pyda's concern w.r.t. reserved outside NATed > addresses > in PRR : > Once a PRR transaction has reserved an outside address (A2) for an > internal end point (A0) at the middlebox, the middlebox must ensure > that > this reserved A2 is available in any subsequent PER and PRR > transaction. > - added paragraph about NAT terminology in terminology section > - revised examples to reflect changes in semantics > > With best regards > > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 3 07:30:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01344 for ; Fri, 3 Oct 2003 07:30:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5O8L-0000am-Vu for midcom-archive@odin.ietf.org; Fri, 03 Oct 2003 07:30:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93BU5mP002275 for midcom-archive@odin.ietf.org; Fri, 3 Oct 2003 07:30:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5O8J-0000Zb-Fl; Fri, 03 Oct 2003 07:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5O8E-0000Yk-2g for midcom@optimus.ietf.org; Fri, 03 Oct 2003 07:29:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01236; Fri, 3 Oct 2003 07:29:50 -0400 (EDT) Message-Id: <200310031129.HAA01236@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 03 Oct 2003 07:29:49 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-05.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling et al. Filename : draft-ietf-midcom-semantics-05.txt Pages : 64 Date : 2003-10-2 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-midcom-semantics-05.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-midcom-semantics-05.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: <2003-10-2120956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-2120956.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 3 15:06:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21249 for ; Fri, 3 Oct 2003 15:06:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VFg-0006Fe-OK for midcom-archive@odin.ietf.org; Fri, 03 Oct 2003 15:06:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93J68d8024029 for midcom-archive@odin.ietf.org; Fri, 3 Oct 2003 15:06:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VFa-0006Ds-9w; Fri, 03 Oct 2003 15:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VEa-0006Bt-LL for midcom@optimus.ietf.org; Fri, 03 Oct 2003 15:05:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21060 for ; Fri, 3 Oct 2003 15:04:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5VEX-000511-00 for midcom@ietf.org; Fri, 03 Oct 2003 15:04:57 -0400 Received: from web40408.mail.yahoo.com ([66.218.78.105]) by ietf-mx with smtp (Exim 4.12) id 1A5VEW-00050Y-00 for midcom@ietf.org; Fri, 03 Oct 2003 15:04:57 -0400 Message-ID: <20031003190425.11458.qmail@web40408.mail.yahoo.com> Received: from [66.224.113.194] by web40408.mail.yahoo.com via HTTP; Fri, 03 Oct 2003 12:04:25 PDT Date: Fri, 3 Oct 2003 12:04:25 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] I-D ACTION:draft-ford-midcom-p2p-00.txt To: Christian Huitema Cc: midcom@ietf.org, Dan Kegel , Bryan Ford In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Christian Huitema wrote: > After reading that draft, may I offer a few comments? Thanks, Christian, for the comments. > The draft contains > a very good survey of the existing techniques, and then three sections > that are not descriptive: the proposal of a new IP option, > recommendations for applications developers, and recommendations for NAT > designers. Out of these three sections, two are quite sound, as they > follow directly from the survey -- the recommendations to applications > and NAT. The description of the IP option, however, is sure to generate > a lot of discussion and controversy. Could it be moved to a separate > draft? Well, the middlebox IP option is central to the theme of enabling immediate deployment of p2p applications and making P2P applications work across middleboxes Basically, we took 3 tacks to the p2p deployment. 1. Suggest tweaks to the existing middlebox and P2P application developers. Expand the application suite to include both TCP and UDP based applications. 2. Suggest the use of a simple IP Middlebox option by the applications and the middleboxes. This is simple and easy to do. Applications donot need to know of the middleboxes enroute. The IP option will traverse all the middleboxes along the way. This, we believe, will trigger wider development of P2P applications. 3. Lastly, the Midcom protocol, if designed right, could help in P2P deployment. Midcom protocol is still in development - Unfrtunately, not enough discussion on the need to control address and port binds and their settings. I donot know, at this time, if the protocol will turn out to be useful for P2P applications. So, while we do understand, use of IP option for anything does tend to be controversial, that seems like the best option at this time given the choices out there. We are certainly open to and welcome considered opinions and comments from middlebox vendors and P2P application developers. Thanks. regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 6 23:07:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03288 for ; Mon, 6 Oct 2003 23:07:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6iBo-00071W-EJ for midcom-archive@odin.ietf.org; Mon, 06 Oct 2003 23:07:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97378Sc026991 for midcom-archive@odin.ietf.org; Mon, 6 Oct 2003 23:07:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6iBi-0006zg-0n; Mon, 06 Oct 2003 23:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6iBI-0006zA-DU for midcom@optimus.ietf.org; Mon, 06 Oct 2003 23:06:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03268 for ; Mon, 6 Oct 2003 23:06:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6iBE-0007ZL-00 for midcom@ietf.org; Mon, 06 Oct 2003 23:06:32 -0400 Received: from web40406.mail.yahoo.com ([66.218.78.103]) by ietf-mx with smtp (Exim 4.12) id 1A6iBD-0007Z4-00 for midcom@ietf.org; Mon, 06 Oct 2003 23:06:31 -0400 Message-ID: <20031007030601.49664.qmail@web40406.mail.yahoo.com> Received: from [66.224.113.194] by web40406.mail.yahoo.com via HTTP; Mon, 06 Oct 2003 20:06:01 PDT Date: Mon, 6 Oct 2003 20:06:01 -0700 (PDT) From: Pyda Srisuresh Subject: Re: Fwd: [midcom] Changes in semantics (Version 05) To: Melinda Shore , midcom@ietf.org In-Reply-To: <618AD9F4-F4E8-11D7-9105-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, I briefly read through the draft this weekend. I still do not believe, the semantics is clear. The abstractions are not adequate to eliminate ALGs from a middlebox. 1. Terminology - I do not believe, you should proliferate of semantics for "NAT binding". This sounds like, it will be whatever you want it to be in sessing up a session. 2. PRR is still fuzzy. The PRR reserves a maximum of two IP addresses (in the case of twice-NAT) and/or several ports on an address. Depending upon what the agent lists in the request parameters, this can be reservation of an address bind, or reservation of a bunch of ports (from a NAPT map entry, presumably) or reservation of an address each from two map entries. The middlebox returned rule identifier can represent any of this (Bind handle or single map reservation or two address map reservations). This is simply a lot of stuff in a single transaction. Very difficult and confusing for a middlebox to do this. Specifying the internal IP address helps in reserving a pool of ports in a NAPT case or an address BIND in the case of basic NAT. But, that alone is not adequate for twice-NAT. The transaction needs to include the destinaion end-point. otherwise, PRR is not usable for Twice-NAT for the same reason the PRR was not usable for traditional NAT in the previous rev of the draft. The middlebox cannot pick up an arbitrary address from one of the map entries for twice-nat, not with just A0 in the request list. As I said earlier, I suggest, the PRR be simplified split up into doing BIND reservations and MAP reservations independently. 3. PER should simply be labelled as session creation request. The text in the draft that refers this as BIND in some cases shoudl simply be eliminated. PER essentially boils down to setting up NAT sessions/flows using pre-established binds or pre-reserved map entries or simply creating a new session. When the session is created, the response should indicate the BINDs used, if any, and the translation end-points for the session. The twice-NAT example doesnt make sense. If the session is between A0 & A1 (as would be in the case of twice-NAT) the agent cannot know A3 ahead of time. However, that is what the PER request parametere description indicates. 3. The document says in several places that the NAT is one of traditional NAT or Twice-NAT. What about bi-directional NAT? I saw this mentioned just once in PER description. When you support bi-directional NAT, it is important for the PRR and PERs to support sessions initiated from the outside, in additiona to sessions initiated from the private realm. The request parameters in PRR and PER are not adequate to support this. 4. I still have an issue with GroupId assignment being mandated on the middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 does not madate this. Thats all for now. cheers, suresh --- Melinda Shore wrote: > I don't think we need to go through full WG last call > on this revision before sending it to the IESG, but I'd > like to give participants a few days to look it over and > raise any objections they may have. So, if no concerns > are raised by the end-of-business on Monday, 5 October, > I'll be forwarding the document to the IESG for review > next week. At a minimum, please look at the changes > that Martin has listed. > > Thanks, > > Melinda > > Begin forwarded message: > > > From: Martin Stiemerling > > Date: Thu Oct 2, 2003 10:44:02 AM US/Eastern > > To: midcom@ietf.org > > Subject: [midcom] Changes in semantics (Version 05) > > > > Hello folks, > > > > I have submitted an updated version of the semantics (Version 05). The > > version is available in advance here: > > > > ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-midcom- > > semantics-05.t > > xt > > > > The changes in this version are: > > > > - Policy Rule List (PRL) and Policy Rule Status (PRS) are now > > mandatory. > > (Based on comments from Juergen Schoenwaelder) > > > > - Fixed comments from Daniel > > - Text in Section 2.1.8 > > - Figure 2, (mc=0) inserted text before Figure 2 > > - Text in 2.3.6 about IPv4 and IPv6 changed > > - in PRR mode parameter changed to service parameter, adapted text > > on middlebox modes > > - Fixed failure text in RLC > > - fixed all text errors > > > > - added middlebox (NAT) policy rule idle-timeout to middlebox's > > capabilities > > with a link to ARE > > - added 'optional interface specific policy rules' capability to > > capability list > > - inserted new chapter "Interface specific Policy Rules" > > - adapted references in whole text to the new numbering due to issue > > one > > above > > - added optional inside/outside interface parameter to PRS (2.3.12) > > - added optional inside/outside interface parameter to PRR (2.3.8) > > - added to request parameter list > > - added corresponding failure reasons > > - added semantical descriptions > > - added optional inside/outside interface parameter to PER (2.3.8) > > - added to request parameter list > > - added corresponding failure reasons > > - added semantical descriptions > > - added statements in conformance section > > - checked spelling > > - added A0 parameter to PRR transaction (Pyda's comment) > > - added PRR/A0 statement to PER > > - added text about Pyda's concern w.r.t. reserved outside NATed > > addresses > > in PRR : > > Once a PRR transaction has reserved an outside address (A2) for an > > internal end point (A0) at the middlebox, the middlebox must ensure > > that > > this reserved A2 is available in any subsequent PER and PRR > > transaction. > > - added paragraph about NAT terminology in terminology section > > - revised examples to reflect changes in semantics > > > > With best regards > > > > Martin Stiemerling > > > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > > PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg > > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 8 09:59:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15121 for ; Wed, 8 Oct 2003 09:59:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7EqH-0007Fe-9y for midcom-archive@odin.ietf.org; Wed, 08 Oct 2003 09:59:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Dx52n027870 for midcom-archive@odin.ietf.org; Wed, 8 Oct 2003 09:59:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7EqD-0007Et-2p; Wed, 08 Oct 2003 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7EpI-0007AO-Uk for midcom@optimus.ietf.org; Wed, 08 Oct 2003 09:58:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15036 for ; Wed, 8 Oct 2003 09:57:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7EpG-0005Fq-00 for midcom@ietf.org; Wed, 08 Oct 2003 09:58:02 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A7EpG-0005FQ-00 for midcom@ietf.org; Wed, 08 Oct 2003 09:58:02 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h98DvPex088968 for ; Wed, 8 Oct 2003 15:57:27 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h98DvN9v088967 for ; Wed, 8 Oct 2003 15:57:23 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h98DvMev088964; Wed, 08 Oct 2003 15:57:23 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 9B703CFB39; Wed, 8 Oct 2003 15:25:08 +0200 (CEST) Date: Wed, 08 Oct 2003 15:57:14 +0200 From: Martin Stiemerling To: Pyda Srisuresh Cc: midcom@ietf.org Subject: Re: Fwd: [midcom] Changes in semantics (Version 05) Message-ID: <2940337.1065628634@[10.1.1.109]> In-Reply-To: <20031007030601.49664.qmail@web40406.mail.yahoo.com> References: <20031007030601.49664.qmail@web40406.mail.yahoo.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Suresh, thanks for checking the document again. More comments inline and I hope on more comments from other working group members. Martin --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh wrote: | Hi, | | I briefly read through the draft this weekend. I still do not believe, the | semantics is clear. The abstractions are not adequate to eliminate | ALGs from a middlebox. | | 1. Terminology - I do not believe, you should proliferate of semantics | for "NAT binding". This sounds like, it will be whatever you want it to | be in sessing up a session. The intention was not to proliferate, but more an approach to bring more light to issue of NAT binding. Do you think that it confuses more than it does help? | | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP addresses (in | the case of twice-NAT) and/or several ports on an address. Depending upon | what the agent lists in the request parameters, this can be reservation | of an address bind, or reservation of a bunch of ports (from a NAPT map | entry, presumably) or reservation of an address each from two map | entries. The middlebox returned rule identifier can represent any of this | (Bind handle or single map reservation or two address map reservations). | This is simply a lot of stuff in a single transaction. Very difficult and | confusing for a middlebox to do this. Yes, that may look confusing, but pushing the task to the MIDCOM agent is more even more confusing to him. | | Specifying the internal IP address helps in reserving a pool of ports in | a NAPT case or an address BIND in the case of basic NAT. But, that alone | is not adequate for twice-NAT. The transaction needs to include the | destinaion end-point. otherwise, PRR is not usable for Twice-NAT for the | same reason the PRR was not usable for traditional NAT in the previous | rev of the draft. The middlebox cannot pick up an arbitrary address from | one of the map entries for twice-nat, not with just A0 in the request | list. The idea behind PRR is that the agent does not know the destination address. This is the case for example in SIP call set-up. Only the data receiver in the private address realm is known on the first INVITE, if the caller is in this private address realm. This is a very tricky thing and PRR does provide a good mean to cope with that, even when it looks somehow strange. I could offer a powerpoint presentation from one of the IETF meetings explaining the need for PRR if you like. | | As I said earlier, I suggest, the PRR be simplified split up into doing | BIND reservations and MAP reservations independently. | | 3. PER should simply be labelled as session creation request. The text in | the draft that refers this as BIND in some cases shoudl simply be | eliminated. PER essentially boils down to setting up NAT sessions/flows | using pre-established binds or pre-reserved map entries or simply | creating a new session. When the session is created, the response should | indicate the BINDs used, if any, and the translation end-points for the | session. You are right in saying that with PER a NAT session is created. But for instance consider this scenario: A PER request with an internal address (A0) and a wildcarded external sender (A3) (dataflow from outside to inside). The external sender is not known (One example is SIP early media). For that case you can not start a NAT session, since the NAT must create a NAT bind. Via this NAT bind several UDP/RTP flows from several destinations may traverse the middlebox to A0. | | The twice-NAT example doesn't make sense. If the session is between A0 & | A1 (as would be in the case of twice-NAT) the agent cannot know A3 ahead | of time. However, that is what the PER request parametere description | indicates. Hmm, I don't see the issue you raise immediately. A3 is the external end point and A1 the inside IP address/port number at the twice-NAT. The application level session is between A0 and A3, but the IP/transport 'sessions' are between A0/A1 and A2/A3. Could you give me some more hints? | 3. The document says in several places that the NAT is one of traditional | NAT or Twice-NAT. What about bi-directional NAT? I saw this mentioned | just once in PER description. When you support bi-directional NAT, it is | important for the PRR and PERs to support sessions initiated from the | outside, in additiona to sessions initiated from the private realm. The | request parameters in PRR and PER are not adequate to support this. That's not true. For PRR the direction is not relevant, since only a resource reservation is made at the NAT. In PER there is the flow direction parameter that indicates the flow direction (inbound, outbound, or bi-directional). So with this it is possible to allow even sessions initiated from the outside. | | 4. I still have an issue with GroupId assignment being mandated on the | middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 does not madate | this. Right the protocol requirements do not mandate this, but as a lot of other points this is a design issue. So far nobody else has any objection about this. | | That's all for now. Thanks for the comments. Martin [... cut by Martin ] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 8 16:23:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07633 for ; Wed, 8 Oct 2003 16:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kpu-0007mB-15 for midcom-archive@odin.ietf.org; Wed, 08 Oct 2003 16:23:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98KN6Li029890 for midcom-archive@odin.ietf.org; Wed, 8 Oct 2003 16:23:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kpp-0007lW-Aa; Wed, 08 Oct 2003 16:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KpF-0007kw-BF for midcom@optimus.ietf.org; Wed, 08 Oct 2003 16:22:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07543 for ; Wed, 8 Oct 2003 16:22:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KpD-0003vy-00 for midcom@ietf.org; Wed, 08 Oct 2003 16:22:23 -0400 Received: from mail2.netscreen.com ([63.126.135.18]) by ietf-mx with esmtp (Exim 4.12) id 1A7KpC-0003vn-00 for midcom@ietf.org; Wed, 08 Oct 2003 16:22:22 -0400 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h98KLeOh006017; Wed, 8 Oct 2003 13:21:41 -0700 (PDT) Received: by NS-CA.netscreen.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 13:21:40 -0700 Message-ID: <82CC1E573B94A648B87027C9419E2C05FDAC3F@LOSGATOS.netscreen.com> From: Wanqun Bao To: "'Martin Stiemerling'" , Pyda Srisuresh Cc: midcom@ietf.org Subject: RE: Fwd: [midcom] Changes in semantics (Version 05) Date: Wed, 8 Oct 2003 13:21:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Martin, I have some comments inline and some general comments regarding the draft following that. Thanks, Wanqun Bao > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Wednesday, October 08, 2003 6:57 AM > To: Pyda Srisuresh > Cc: midcom@ietf.org > Subject: Re: Fwd: [midcom] Changes in semantics (Version 05) > > > Hi Suresh, > > thanks for checking the document again. More comments inline > and I hope on > more comments from other working group members. > > Martin > > --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh > wrote: > > | Hi, > | > | I briefly read through the draft this weekend. I still do > not believe, the > | semantics is clear. The abstractions are not adequate to eliminate > | ALGs from a middlebox. > | > | 1. Terminology - I do not believe, you should proliferate > of semantics > | for "NAT binding". This sounds like, it will be whatever > you want it to > | be in sessing up a session. > > The intention was not to proliferate, but more an approach to > bring more > light to issue of NAT binding. Do you think that it confuses > more than it > does help? > > | > | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP > addresses (in > | the case of twice-NAT) and/or several ports on an address. > Depending upon > | what the agent lists in the request parameters, this can be > reservation > | of an address bind, or reservation of a bunch of ports > (from a NAPT map > | entry, presumably) or reservation of an address each from two map > | entries. The middlebox returned rule identifier can > represent any of this > | (Bind handle or single map reservation or two address map > reservations). > | This is simply a lot of stuff in a single transaction. Very > difficult and > | confusing for a middlebox to do this. > > Yes, that may look confusing, but pushing the task to the > MIDCOM agent is > more even more confusing to him. > My understanding is that a PID returned from the middlebox uniquely identifies a rule which contains a tightly related set of reserved resources(either one or two IP addresses, transport type, and port number(s)). These resources will be used for creating pinholes using PER. > | > | Specifying the internal IP address helps in reserving a > pool of ports in > | a NAPT case or an address BIND in the case of basic NAT. > But, that alone > | is not adequate for twice-NAT. The transaction needs to include the > | destinaion end-point. otherwise, PRR is not usable for > Twice-NAT for the > | same reason the PRR was not usable for traditional NAT in > the previous > | rev of the draft. The middlebox cannot pick up an arbitrary > address from > | one of the map entries for twice-nat, not with just A0 in > the request > | list. > > The idea behind PRR is that the agent does not know the destination > address. > > This is the case for example in SIP call set-up. Only the > data receiver in > the private address realm is known on the first INVITE, if > the caller is in > this private address realm. This is a very tricky thing and PRR does > provide a good mean to cope with that, even when it looks > somehow strange. > I could offer a powerpoint presentation from one of the IETF meetings > explaining the need for PRR if you like. > A middlebox does not need A3 to reserve A1. To me, a reservation can be made without its final binding peer. Binding is only needed when a PER is made, which will be used for the flow session(the actual traffic). On the other hand, if A3 is known and presented in the PRR request, later PER needs not to really mention A1 and A3(although they can be used for verification purpose.) What is interesting is that in the case of SIP, even after call is set-up(an ACK is sent from the caller), we may not really know the source IP for the media from both directions until they actually arrive at the middle box(e.g., a media gateway uses one IP for sending and another IP for receiving). > | > | As I said earlier, I suggest, the PRR be simplified split > up into doing > | BIND reservations and MAP reservations independently. > | > | 3. PER should simply be labelled as session creation > request. The text in > | the draft that refers this as BIND in some cases shoudl simply be > | eliminated. PER essentially boils down to setting up NAT > sessions/flows > | using pre-established binds or pre-reserved map entries or simply > | creating a new session. When the session is created, the > response should > | indicate the BINDs used, if any, and the translation > end-points for the > | session. > > You are right in saying that with PER a NAT session is > created. But for > instance consider this scenario: > > A PER request with an internal address (A0) and a wildcarded external > sender (A3) (dataflow from outside to inside). The external > sender is not > known (One example is SIP early media). For that case you can > not start a > NAT session, since the NAT must create a NAT bind. Via this NAT bind > several UDP/RTP flows from several destinations may traverse > the middlebox > to A0. > Just want to add that enabling a rule is not the same as creating a session. A session is only created when actual traffic comes and matches a rule. > | > | The twice-NAT example doesn't make sense. If the session is > between A0 & > | A1 (as would be in the case of twice-NAT) the agent cannot > know A3 ahead > | of time. However, that is what the PER request parametere > description > | indicates. > > Hmm, I don't see the issue you raise immediately. > > A3 is the external end point and A1 the inside IP > address/port number at > the twice-NAT. The application level session is between A0 > and A3, but the > IP/transport 'sessions' are between A0/A1 and A2/A3. > > Could you give me some more hints? > > > | 3. The document says in several places that the NAT is one > of traditional > | NAT or Twice-NAT. What about bi-directional NAT? I saw this > mentioned > | just once in PER description. When you support > bi-directional NAT, it is > | important for the PRR and PERs to support sessions > initiated from the > | outside, in additiona to sessions initiated from the > private realm. The > | request parameters in PRR and PER are not adequate to support this. > > That's not true. For PRR the direction is not relevant, since only a > resource reservation is made at the NAT. In PER there is the > flow direction > parameter that indicates the flow direction (inbound, outbound, or > bi-directional). So with this it is possible to allow even sessions > initiated from the outside. > Does "direction of flow" applies only to the initial packet or to all the subsequent packets enabled by this rule? For example, if the direction of flow is inbound and the protocol is UDP, the first packet comes from external to internal(inbound), it matches a rule and a session is created. Will the middlebox drop any outbound packet that actually matches with the session created? What about if the protocol is TCP? If the direction of flow really applies to the initial packet, we need specify it clearly in the doc. > | > | 4. I still have an issue with GroupId assignment being > mandated on the > | middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 > does not madate > | this. > > Right the protocol requirements do not mandate this, but as a > lot of other > points this is a design issue. So far nobody else has any > objection about > this. > I think GroupId is really needed for efficiently managing resources(rules) in the middle box. I have some general comments regarding the draft: 1. Rule's lifetime For PRR, it is simple: if a PRR is not replaced by a PER in its lifetime, it will be removed. It's a resource cleanup and there's no security issues. For PER, a rule is enabled(a pinhole is punched and in most cases, it's a cone). If there's no packet that macthes with the rule within rule's lifetime, the rule is removed. But what happens to the rule after the first packet matches with rule and a session is created for the intended flow? In many cases, in order to tighten the security, the pinhole should be closed immediately after the first packet comes and a session is created. A new field in PER might be needed to indicate that and the policy rule state machine should be modified accordingly. 2. Flow sessions derived from rules Forgive me if this has been discussed here before. In this draft, except "direction of flow", handling of flow sessions is totally excluded. Correct me if I'm wrong, MIDCOM is used to allow application-layer enabled traffic to traverse the middlebox. Traverse does not stop after a flow session is created. From the current draft, if an agent creates a number of rules under a group, intended traffic will traverse the middle box. After all the rules are timeout, the group with all its members(rules) is removed. What's left in the middle box are the flow sessions derived from these rules. Different middle box may have different timeouts for its sessions. If one session times out(for example, one of the audio channels may not send data at all for a period of time), it can not be re-established if the corresponding rule has already been removed. At the meantime, we don't want to keep rules around for a long time. One way to solve this is to let an agent tell the middlebox to use a flow session timeout for the entire group. As long as there's one session in the group that's alive within this timeout, none of the sessions within the group should be timed out. 3. Group Lifetime A group can be removed using GLC with lifetime being 0. A group should be removed when there is no rule and derived session in the group. A group's lifetime should be reset whenever there's a request(except GLC with lifetime being 0) from the agent. A group should be timed out using its lifetime which is independent to its rules and derived sessions(to clean up "dead" calls with media still sending.) 4. In 2.3.9., should PER also include a "service" field? Thanks, Wanqun > > | > | That's all for now. > > Thanks for the comments. > Martin > > [... cut by Martin ] > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 9 12:01:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25704 for ; Thu, 9 Oct 2003 12:01:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dED-0004Er-Pr for midcom-archive@odin.ietf.org; Thu, 09 Oct 2003 12:01:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99G1P46016293 for midcom-archive@odin.ietf.org; Thu, 9 Oct 2003 12:01:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dDx-00046e-VM; Thu, 09 Oct 2003 12:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dDU-0003wb-WB for midcom@optimus.ietf.org; Thu, 09 Oct 2003 12:00:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25633 for ; Thu, 9 Oct 2003 12:00:32 -0400 (EDT) From: martin@ccrle.nec.de Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7dDT-0000Gw-00 for midcom@ietf.org; Thu, 09 Oct 2003 12:00:39 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A7dDS-0000GY-00 for midcom@ietf.org; Thu, 09 Oct 2003 12:00:38 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h99Fxvxw032326 for ; Thu, 9 Oct 2003 18:00:02 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h99FxubH032325 for ; Thu, 9 Oct 2003 17:59:56 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h99Fxsxs032322; Thu, 09 Oct 2003 17:59:56 +0200 (CEST) Received: from yamato.ccrle.nec.de (jupiter.office [10.1.1.3]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with SMTP id EAB9C34053; Thu, 9 Oct 2003 17:27:29 +0200 (CEST) Received: from 10.1.1.83 (SquirrelMail authenticated user martin) by yamato.ccrle.nec.de with HTTP; Thu, 9 Oct 2003 15:59:53 -0000 (GMT) Message-ID: <3692.10.1.1.83.1065715193.squirrel@yamato.ccrle.nec.de> In-Reply-To: <82CC1E573B94A648B87027C9419E2C05FDAC3F@LOSGATOS.netscreen.com> References: <82CC1E573B94A648B87027C9419E2C05FDAC3F@LOSGATOS.netscreen.com> Date: Thu, 9 Oct 2003 15:59:53 -0000 (GMT) Subject: RE: Fwd: [midcom] Changes in semantics (Version 05) To: "Wanqun Bao" Cc: midcom@ietf.org, quittek@ccrle.nec.de User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Scanned-By: MIMEDefang 2.35 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Wanqun Bao, many thanks for your comments! See answers inline. Cheers Martin > Hi Martin, > > I have some comments inline and some general comments > regarding the draft following that. > > Thanks, > > Wanqun Bao > >> -----Original Message----- >> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >> Sent: Wednesday, October 08, 2003 6:57 AM >> To: Pyda Srisuresh >> Cc: midcom@ietf.org >> Subject: Re: Fwd: [midcom] Changes in semantics (Version 05) >> >> >> Hi Suresh, >> >> thanks for checking the document again. More comments inline >> and I hope on >> more comments from other working group members. >> >> Martin >> >> --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh >> wrote: >> >> | Hi, >> | >> | I briefly read through the draft this weekend. I still do >> not believe, the >> | semantics is clear. The abstractions are not adequate to eliminate >> | ALGs from a middlebox. >> | >> | 1. Terminology - I do not believe, you should proliferate >> of semantics >> | for "NAT binding". This sounds like, it will be whatever >> you want it to >> | be in sessing up a session. >> >> The intention was not to proliferate, but more an approach to >> bring more >> light to issue of NAT binding. Do you think that it confuses >> more than it >> does help? >> >> | >> | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP >> addresses (in >> | the case of twice-NAT) and/or several ports on an address. >> Depending upon >> | what the agent lists in the request parameters, this can be >> reservation >> | of an address bind, or reservation of a bunch of ports >> (from a NAPT map >> | entry, presumably) or reservation of an address each from two map >> | entries. The middlebox returned rule identifier can >> represent any of this >> | (Bind handle or single map reservation or two address map >> reservations). >> | This is simply a lot of stuff in a single transaction. Very >> difficult and >> | confusing for a middlebox to do this. >> >> Yes, that may look confusing, but pushing the task to the >> MIDCOM agent is >> more even more confusing to him. >> > My understanding is that a PID returned from the middlebox uniquely > identifies a rule which contains a tightly related set of reserved > resources(either one or two IP addresses, transport type, and port > number(s)). > These resources will be used for creating pinholes using PER. A PID returned from the middlebox identifiers a midcom policy rule, which may infact represent multiple firewall rules and NAT configuration. The PID out of the PRR is used for creating policy rules in PER, that's right. > >> | >> | Specifying the internal IP address helps in reserving a >> pool of ports in >> | a NAPT case or an address BIND in the case of basic NAT. >> But, that alone >> | is not adequate for twice-NAT. The transaction needs to include the >> | destinaion end-point. otherwise, PRR is not usable for >> Twice-NAT for the >> | same reason the PRR was not usable for traditional NAT in >> the previous >> | rev of the draft. The middlebox cannot pick up an arbitrary >> address from >> | one of the map entries for twice-nat, not with just A0 in >> the request >> | list. >> >> The idea behind PRR is that the agent does not know the destination >> address. >> >> This is the case for example in SIP call set-up. Only the >> data receiver in >> the private address realm is known on the first INVITE, if >> the caller is in >> this private address realm. This is a very tricky thing and PRR does >> provide a good mean to cope with that, even when it looks >> somehow strange. >> I could offer a powerpoint presentation from one of the IETF meetings >> explaining the need for PRR if you like. >> > A middlebox does not need A3 to reserve A1. To me, a reservation > can be made without its final binding peer. Binding is only > needed when a PER is made, which will be used for the flow session(the > actual traffic). Right, but you can use PRR to reserve A1 and you get A2 as well. In PRR you don't need to know the external peer's address. As for instance in a SIP call from a peer behind a NAT: On the first INVITE you don't know the peer's address on the other side (the callee). In this case you can use PRR or PER in the case you want to support SIP early media. > On the other hand, if A3 is known and presented in the PRR request, > later PER needs not to really mention A1 and A3(although they > can be used for verification purpose.) As described above PRR is intended for cases when A3 is known in advance. So it is needed to have A3 in the PER. A1 is needed in PER since there is a unified PER transaction, independently of having a reserved policy rule (via PRR) or or having not a reserved policy rule. We discussed earlier in the working group, if it is wise to split PER into two different PER. The consensus was not to split PER. > What is interesting is that in the case of SIP, even after call is > set-up(an ACK is sent from the caller), we may not really know the > source IP for the media from both directions until they > actually arrive at the middle box(e.g., a media gateway uses one IP > for sending and another IP for receiving). Fully agreed. That's the above scenario for SIP. In this case the PRR is needed. > >> | >> | As I said earlier, I suggest, the PRR be simplified split >> up into doing >> | BIND reservations and MAP reservations independently. >> | >> | 3. PER should simply be labelled as session creation >> request. The text in >> | the draft that refers this as BIND in some cases shoudl simply be >> | eliminated. PER essentially boils down to setting up NAT >> sessions/flows >> | using pre-established binds or pre-reserved map entries or simply >> | creating a new session. When the session is created, the >> response should >> | indicate the BINDs used, if any, and the translation >> end-points for the >> | session. >> >> You are right in saying that with PER a NAT session is >> created. But for >> instance consider this scenario: >> >> A PER request with an internal address (A0) and a wildcarded external >> sender (A3) (dataflow from outside to inside). The external >> sender is not >> known (One example is SIP early media). For that case you can >> not start a >> NAT session, since the NAT must create a NAT bind. Via this NAT bind >> several UDP/RTP flows from several destinations may traverse >> the middlebox >> to A0. >> > Just want to add that enabling a rule is not the same as creating > a session. A session is only created when actual traffic comes > and matches a rule. That depends on your implementation. Perhaps you implement the PER in a way that you load sessions into your NAT. Perhaps not. I see that this is a difference, but this should be up to the implementor. > >> | >> | The twice-NAT example doesn't make sense. If the session is >> between A0 & >> | A1 (as would be in the case of twice-NAT) the agent cannot >> know A3 ahead >> | of time. However, that is what the PER request parametere >> description >> | indicates. >> >> Hmm, I don't see the issue you raise immediately. >> >> A3 is the external end point and A1 the inside IP >> address/port number at >> the twice-NAT. The application level session is between A0 >> and A3, but the >> IP/transport 'sessions' are between A0/A1 and A2/A3. >> >> Could you give me some more hints? >> >> >> | 3. The document says in several places that the NAT is one >> of traditional >> | NAT or Twice-NAT. What about bi-directional NAT? I saw this >> mentioned >> | just once in PER description. When you support >> bi-directional NAT, it is >> | important for the PRR and PERs to support sessions >> initiated from the >> | outside, in additiona to sessions initiated from the >> private realm. The >> | request parameters in PRR and PER are not adequate to support this. >> >> That's not true. For PRR the direction is not relevant, since only a >> resource reservation is made at the NAT. In PER there is the >> flow direction >> parameter that indicates the flow direction (inbound, outbound, or >> bi-directional). So with this it is possible to allow even sessions >> initiated from the outside. >> > Does "direction of flow" applies only to the initial packet or to all the > subsequent > packets enabled by this rule? > For example, if the direction of flow is inbound and the protocol is UDP, > the first packet comes from external to internal(inbound), it matches a > rule and a session is created. Will the middlebox drop any outbound packet > that actually matches with the session created? Right. If 'inbound' is selected only inbound packets can traverse the middlebox (necessary for configuration of firewall rules). So if you need in and outbound packet flow for this specific flow you have to specifiy bi-directional. TCP must use always bi-directional, otherwise it doesn't make sense. The TCP and bi-directional should be stated in the semantics, unfortunately I don't have them by now, so I can not show the section where it is printed. > What about if the protocol is TCP? > If the direction of flow really applies to the initial packet, we need > specify it clearly in the doc. Do you think that needs some clarification? Could you propose some text? > >> | >> | 4. I still have an issue with GroupId assignment being >> mandated on the >> | middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 >> does not madate >> | this. >> >> Right the protocol requirements do not mandate this, but as a >> lot of other >> points this is a design issue. So far nobody else has any >> objection about >> this. >> > I think GroupId is really needed for efficiently managing resources(rules) > in > the middle box. Fully agreed! > > I have some general comments regarding the draft: > 1. Rule's lifetime > For PRR, it is simple: if a PRR is not replaced by a PER in its lifetime, > it > will be removed. It's a resource cleanup and there's no security issues. > For PER, a rule is enabled(a pinhole is punched and in most cases, it's > a cone). If there's no packet that macthes with the rule within rule's > lifetime, > the rule is removed. But what happens to the rule after the first packet > matches > with rule and a session is created for the intended flow? In many cases, > in > order > to tighten the security, the pinhole should be closed immediately after > the > first > packet comes and a session is created. A new field in PER might be needed > to > indicate that and the policy rule state machine should be modified > accordingly. I feel that is an issue for local policies. If the sytem adiminstrator feels that this is needed he can configure the box in that way. MIDCOM provides the ARE (asyncrhonous rule event notification) in order to tell the agent that the policy rule was removed. > > 2. Flow sessions derived from rules > Forgive me if this has been discussed here before. In this draft, except > "direction of flow", handling of flow sessions is totally excluded. > Correct me if I'm wrong, MIDCOM is used to allow application-layer enabled > traffic to traverse the middlebox. Traverse does not stop after a flow > session > is created. From the current draft, if an agent creates a number of rules > under > a group, intended traffic will traverse the middle box. After all the > rules > are timeout, the group with all its members(rules) is removed. What's left > in the middle box are the flow sessions derived from these rules. The middlebox part must take care about removing pending sessions. Though if a policy rule is removed, the middlebox should free any resource that has been allocated through this binding (the box should of course not remove for example firewall rules and NAT configuration that is still needed by other flows). > Different > middle box may have different timeouts for its sessions. If one session > times > out(for example, one of the audio channels may not send data at all for a > period > of time), it can not be re-established if the corresponding rule has > already > been removed. But that is the intention. If the corresponding policy rule has been removed, the middlebox should block the stuff. > At the meantime, we don't want to keep rules around for a long time. > One way to solve this is to let an agent tell the middlebox to use a flow > session > timeout for the entire group. As long as there's one session in the group > that's > alive within this timeout, none of the sessions within the group should be > timed out. > > 3. Group Lifetime > A group can be removed using GLC with lifetime being 0. > A group should be removed when there is no rule and derived session in the > group. > A group's lifetime should be reset whenever there's a request(except GLC > with > lifetime being 0) from the agent. > A group should be timed out using its lifetime which is independent to its > rules > and derived sessions(to clean up "dead" calls with media still sending.) > > 4. In 2.3.9., should PER also include a "service" field? It was decided (in favor of having a unified PER, please see above) to go this way: We you need to choose the service, you first must a PRR transaction and afterwards you issue the PER transaction on the reserved policy reserve rule. > > > Thanks, You are welcome and thank you again for the comments. I hope I have answered the properly. Cheers Martin > > Wanqun > >> >> | >> | That's all for now. >> >> Thanks for the comments. >> Martin >> >> [... cut by Martin ] >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom >> > ----------------------------------------- This email was sent using SquirrelMail. "Webmail for nuts!" http://squirrelmail.org/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 9 16:58:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10722 for ; Thu, 9 Oct 2003 16:58:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hrP-0007c1-Et for midcom-archive@odin.ietf.org; Thu, 09 Oct 2003 16:58:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99KwBjm029257 for midcom-archive@odin.ietf.org; Thu, 9 Oct 2003 16:58:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hrE-0007a7-NR; Thu, 09 Oct 2003 16:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hqy-0007Zf-EG for midcom@optimus.ietf.org; Thu, 09 Oct 2003 16:57:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10673 for ; Thu, 9 Oct 2003 16:57:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hqw-0004S1-00 for midcom@ietf.org; Thu, 09 Oct 2003 16:57:42 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7hqv-0004Rx-00 for midcom@ietf.org; Thu, 09 Oct 2003 16:57:41 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h99Kus912622; Thu, 9 Oct 2003 16:56:54 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4S66SZG2; Thu, 9 Oct 2003 16:56:54 -0400 Received: from nortelnetworks.com (acart1b1.ca.nortel.com [47.129.129.11]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NCPL; Thu, 9 Oct 2003 16:56:54 -0400 Message-ID: <3F85CB94.8090406@nortelnetworks.com> Date: Thu, 09 Oct 2003 16:56:52 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Pyda Srisuresh CC: Melinda Shore , midcom@ietf.org References: <20031007030601.49664.qmail@web40406.mail.yahoo.com> In-Reply-To: <20031007030601.49664.qmail@web40406.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Need for A3 as a PRR parameter (was Changes in semantics (Version 05)) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I wanted to address your point regarding PRR. Please see below. Pyda Srisuresh wrote: > Hi, > > I briefly read through the draft this weekend. I still do not believe, the > semantics is clear. The abstractions are not adequate to eliminate > ALGs from a middlebox. > ... > > 2. PRR is still fuzzy. The PRR reserves a maximum of two IP addresses (in the > case of twice-NAT) and/or several ports on an address. Depending upon what the > agent lists in the request parameters, this can be reservation of an address > bind, or reservation of a bunch of ports (from a NAPT map entry, presumably) or > reservation of an address each from two map entries. The middlebox returned > rule identifier can represent any of this (Bind handle or single map > reservation or two address map reservations). This is simply a lot of stuff in > a single transaction. Very difficult and confusing for a middlebox to do this. > > Specifying the internal IP address helps in reserving a pool of ports in a NAPT > case or an address BIND in the case of basic NAT. But, that alone is not > adequate for twice-NAT. The transaction needs to include the destinaion > end-point. otherwise, PRR is not usable for Twice-NAT for the same reason the > PRR was not usable for traditional NAT in the previous rev of the draft. The > middlebox cannot pick up an arbitrary address from one of the map entries for > twice-nat, not with just A0 in the request list. > [PTT] The reason PRR was not usable for traditional NAT without specifying A0 was because it was possible the NAT already had a mapping for A0 because of an existing dynamically-established session, and had to have the information to choose it. The reason we added an optional interface identifier was because the NAT could be supporting multiple private interfaces. It is a fact that the application, and thus the agent, will often not know A3 at the time of the PRR request. It is thus important to confirm what is or is not possible in terms of NAT technology. I assume you consider A3 necessary for the same reason as A0: because the NAT is unable to map the same external address to more than one internal address in the twice-NAT case, and the host at A3 may already be involved in another session operating through this middlebox. If this is true (please confirm), it may be that we have to accept a certain percentage of cases where the PER will fail because the mapping assigned by the PRR is inconsistent with existing configuration. > As I said earlier, I suggest, the PRR be simplified split up into doing BIND > reservations and MAP reservations independently. [PTT] I don't believe PRR does more than MAP reservations. > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 9 17:43:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12203 for ; Thu, 9 Oct 2003 17:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7iYr-000274-HN for midcom-archive@odin.ietf.org; Thu, 09 Oct 2003 17:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Lh5c6008119 for midcom-archive@odin.ietf.org; Thu, 9 Oct 2003 17:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7iYn-00026M-Bn; Thu, 09 Oct 2003 17:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7iYQ-00021N-I1 for midcom@optimus.ietf.org; Thu, 09 Oct 2003 17:42:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12182 for ; Thu, 9 Oct 2003 17:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7iYN-0004x2-00 for midcom@ietf.org; Thu, 09 Oct 2003 17:42:35 -0400 Received: from mail2.netscreen.com ([63.126.135.18]) by ietf-mx with esmtp (Exim 4.12) id 1A7iYM-0004wd-00 for midcom@ietf.org; Thu, 09 Oct 2003 17:42:35 -0400 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h99LfsOh009461; Thu, 9 Oct 2003 14:41:54 -0700 (PDT) Received: by NS-CA.netscreen.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Oct 2003 14:41:54 -0700 Message-ID: <82CC1E573B94A648B87027C9419E2C05FDAC48@LOSGATOS.netscreen.com> From: Wanqun Bao To: "'martin@ccrle.nec.de'" , Wanqun Bao Cc: midcom@ietf.org, quittek@ccrle.nec.de Subject: RE: Fwd: [midcom] Changes in semantics (Version 05) Date: Thu, 9 Oct 2003 14:41:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Martin, Thanks very much for the answers. Please see the inline comments. Wanqun > -----Original Message----- > From: martin@ccrle.nec.de [mailto:martin@ccrle.nec.de] > Sent: Thursday, October 09, 2003 9:00 AM > To: Wanqun Bao > Cc: midcom@ietf.org; quittek@ccrle.nec.de > Subject: RE: Fwd: [midcom] Changes in semantics (Version 05) > > > Hi Wanqun Bao, > > many thanks for your comments! > > See answers inline. > > Cheers > Martin > > > Hi Martin, > > > > I have some comments inline and some general comments > > regarding the draft following that. > > > > Thanks, > > > > Wanqun Bao > > > >> -----Original Message----- > >> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > >> Sent: Wednesday, October 08, 2003 6:57 AM > >> To: Pyda Srisuresh > >> Cc: midcom@ietf.org > >> Subject: Re: Fwd: [midcom] Changes in semantics (Version 05) > >> > >> > >> Hi Suresh, > >> > >> thanks for checking the document again. More comments inline > >> and I hope on > >> more comments from other working group members. > >> > >> Martin > >> > >> --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh > >> wrote: > >> > >> | Hi, > >> | > >> | I briefly read through the draft this weekend. I still do > >> not believe, the > >> | semantics is clear. The abstractions are not adequate to > eliminate > >> | ALGs from a middlebox. > >> | > >> | 1. Terminology - I do not believe, you should proliferate > >> of semantics > >> | for "NAT binding". This sounds like, it will be whatever > >> you want it to > >> | be in sessing up a session. > >> > >> The intention was not to proliferate, but more an approach to > >> bring more > >> light to issue of NAT binding. Do you think that it confuses > >> more than it > >> does help? > >> > >> | > >> | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP > >> addresses (in > >> | the case of twice-NAT) and/or several ports on an address. > >> Depending upon > >> | what the agent lists in the request parameters, this can be > >> reservation > >> | of an address bind, or reservation of a bunch of ports > >> (from a NAPT map > >> | entry, presumably) or reservation of an address each from two map > >> | entries. The middlebox returned rule identifier can > >> represent any of this > >> | (Bind handle or single map reservation or two address map > >> reservations). > >> | This is simply a lot of stuff in a single transaction. Very > >> difficult and > >> | confusing for a middlebox to do this. > >> > >> Yes, that may look confusing, but pushing the task to the > >> MIDCOM agent is > >> more even more confusing to him. > >> > > My understanding is that a PID returned from the middlebox uniquely > > identifies a rule which contains a tightly related set of reserved > > resources(either one or two IP addresses, transport type, and port > > number(s)). > > These resources will be used for creating pinholes using PER. > > A PID returned from the middlebox identifiers a midcom policy > rule, which > may infact represent multiple firewall rules and NAT > configuration. The > PID out of the PRR is used for creating policy rules in PER, > that's right. > Agreed. But as long as an agent wants to manage these derived firewall rules and NAT mappings as a whole(a midcom policy rule), a single PID is enough. > > > >> | > >> | Specifying the internal IP address helps in reserving a > >> pool of ports in > >> | a NAPT case or an address BIND in the case of basic NAT. > >> But, that alone > >> | is not adequate for twice-NAT. The transaction needs to > include the > >> | destinaion end-point. otherwise, PRR is not usable for > >> Twice-NAT for the > >> | same reason the PRR was not usable for traditional NAT in > >> the previous > >> | rev of the draft. The middlebox cannot pick up an arbitrary > >> address from > >> | one of the map entries for twice-nat, not with just A0 in > >> the request > >> | list. > >> > >> The idea behind PRR is that the agent does not know the destination > >> address. > >> > >> This is the case for example in SIP call set-up. Only the > >> data receiver in > >> the private address realm is known on the first INVITE, if > >> the caller is in > >> this private address realm. This is a very tricky thing > and PRR does > >> provide a good mean to cope with that, even when it looks > >> somehow strange. > >> I could offer a powerpoint presentation from one of the > IETF meetings > >> explaining the need for PRR if you like. > >> > > A middlebox does not need A3 to reserve A1. To me, a reservation > > can be made without its final binding peer. Binding is only > > needed when a PER is made, which will be used for the flow > session(the > > actual traffic). > > Right, but you can use PRR to reserve A1 and you get A2 as > well. In PRR > you don't need to know the external peer's address. As for > instance in a > SIP call from a peer behind a NAT: On the first INVITE you > don't know the > peer's address on the other side (the callee). In this case > you can use > PRR or PER in the case you want to support SIP early media. > Agreed. In terms of supporting SIP early media, if PRR then PER is used, there's a chance that the some of the early media will be dropped by the middlebox within the window between right after the callee gets the INVITE and starts sending early media and before the moddlebox processing the PER. Depending on the situation, this window may not be small because the agent only sends PER out after it receives 200 OK. > > On the other hand, if A3 is known and presented in the PRR request, > > later PER needs not to really mention A1 and A3(although they > > can be used for verification purpose.) > > As described above PRR is intended for cases when A3 is known > in advance. > So it is needed to have A3 in the PER. A1 is needed in PER > since there is > a unified PER transaction, independently of having a reserved > policy rule > (via PRR) or or having not a reserved policy rule. We > discussed earlier in > the working group, if it is wise to split PER into two > different PER. The > consensus was not to split PER. You meant PRR is intended for cases when A3 is NOT known. Right? > > > What is interesting is that in the case of SIP, even after call is > > set-up(an ACK is sent from the caller), we may not really know the > > source IP for the media from both directions until they > > actually arrive at the middle box(e.g., a media gateway uses one IP > > for sending and another IP for receiving). > > Fully agreed. That's the above scenario for SIP. In this case > the PRR is > needed. > > > > >> | > >> | As I said earlier, I suggest, the PRR be simplified split > >> up into doing > >> | BIND reservations and MAP reservations independently. > >> | > >> | 3. PER should simply be labelled as session creation > >> request. The text in > >> | the draft that refers this as BIND in some cases shoudl simply be > >> | eliminated. PER essentially boils down to setting up NAT > >> sessions/flows > >> | using pre-established binds or pre-reserved map entries or simply > >> | creating a new session. When the session is created, the > >> response should > >> | indicate the BINDs used, if any, and the translation > >> end-points for the > >> | session. > >> > >> You are right in saying that with PER a NAT session is > >> created. But for > >> instance consider this scenario: > >> > >> A PER request with an internal address (A0) and a > wildcarded external > >> sender (A3) (dataflow from outside to inside). The external > >> sender is not > >> known (One example is SIP early media). For that case you can > >> not start a > >> NAT session, since the NAT must create a NAT bind. Via > this NAT bind > >> several UDP/RTP flows from several destinations may traverse > >> the middlebox > >> to A0. > >> > > Just want to add that enabling a rule is not the same as creating > > a session. A session is only created when actual traffic comes > > and matches a rule. > > That depends on your implementation. Perhaps you implement > the PER in a > way that you load sessions into your NAT. Perhaps not. I see > that this is > a difference, but this should be up to the implementor. > > > > >> | > >> | The twice-NAT example doesn't make sense. If the session is > >> between A0 & > >> | A1 (as would be in the case of twice-NAT) the agent cannot > >> know A3 ahead > >> | of time. However, that is what the PER request parametere > >> description > >> | indicates. > >> > >> Hmm, I don't see the issue you raise immediately. > >> > >> A3 is the external end point and A1 the inside IP > >> address/port number at > >> the twice-NAT. The application level session is between A0 > >> and A3, but the > >> IP/transport 'sessions' are between A0/A1 and A2/A3. > >> > >> Could you give me some more hints? > >> > >> > >> | 3. The document says in several places that the NAT is one > >> of traditional > >> | NAT or Twice-NAT. What about bi-directional NAT? I saw this > >> mentioned > >> | just once in PER description. When you support > >> bi-directional NAT, it is > >> | important for the PRR and PERs to support sessions > >> initiated from the > >> | outside, in additiona to sessions initiated from the > >> private realm. The > >> | request parameters in PRR and PER are not adequate to > support this. > >> > >> That's not true. For PRR the direction is not relevant, > since only a > >> resource reservation is made at the NAT. In PER there is the > >> flow direction > >> parameter that indicates the flow direction (inbound, outbound, or > >> bi-directional). So with this it is possible to allow even sessions > >> initiated from the outside. > >> > > Does "direction of flow" applies only to the initial packet > or to all the > > subsequent > > packets enabled by this rule? > > For example, if the direction of flow is inbound and the > protocol is UDP, > > the first packet comes from external to internal(inbound), > it matches a > > rule and a session is created. Will the middlebox drop any > outbound packet > > that actually matches with the session created? > > Right. If 'inbound' is selected only inbound packets can traverse the > middlebox (necessary for configuration of firewall rules). So > if you need > in and outbound packet flow for this specific flow you have > to specifiy > bi-directional. TCP must use always bi-directional, otherwise > it doesn't > make sense. The TCP and bi-directional should be stated in > the semantics, > unfortunately I don't have them by now, so I can not show the section > where it is printed. > > > > > What about if the protocol is TCP? > > If the direction of flow really applies to the initial > packet, we need > > specify it clearly in the doc. > > Do you think that needs some clarification? Could you propose > some text? > There's a difference between the direction of the initial packet and the direction of the flow(all the packets). Based on your explanation, the "direction of flow" refers to the later. This's fine. What's interesting is that if there's a field that indicates the direction of the initial packet, we can effectively tighten the rule. For example, in the case of TCP, the direction of flow has to be bi-directional, which allows both internal and external to initiate a session. If a direction of initial packet is used and set to either "inbound" or "outboud", which can effectively allow only one direction of initiation. > > > >> | > >> | 4. I still have an issue with GroupId assignment being > >> mandated on the > >> | middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 > >> does not madate > >> | this. > >> > >> Right the protocol requirements do not mandate this, but as a > >> lot of other > >> points this is a design issue. So far nobody else has any > >> objection about > >> this. > >> > > I think GroupId is really needed for efficiently managing > resources(rules) > > in > > the middle box. > > Fully agreed! > > > > > I have some general comments regarding the draft: > > 1. Rule's lifetime > > For PRR, it is simple: if a PRR is not replaced by a PER in > its lifetime, > > it > > will be removed. It's a resource cleanup and there's no > security issues. > > For PER, a rule is enabled(a pinhole is punched and in most > cases, it's > > a cone). If there's no packet that macthes with the rule > within rule's > > lifetime, > > the rule is removed. But what happens to the rule after the > first packet > > matches > > with rule and a session is created for the intended flow? > In many cases, > > in > > order > > to tighten the security, the pinhole should be closed > immediately after > > the > > first > > packet comes and a session is created. A new field in PER > might be needed > > to > > indicate that and the policy rule state machine should be modified > > accordingly. > > I feel that is an issue for local policies. If the sytem adiminstrator > feels that this is needed he can configure the box in that way. MIDCOM > provides the ARE (asyncrhonous rule event notification) in > order to tell > the agent that the policy rule was removed. > > > > > 2. Flow sessions derived from rules > > Forgive me if this has been discussed here before. In this > draft, except > > "direction of flow", handling of flow sessions is totally excluded. > > Correct me if I'm wrong, MIDCOM is used to allow > application-layer enabled > > traffic to traverse the middlebox. Traverse does not stop > after a flow > > session > > is created. From the current draft, if an agent creates a > number of rules > > under > > a group, intended traffic will traverse the middle box. > After all the > > rules > > are timeout, the group with all its members(rules) is > removed. What's left > > in the middle box are the flow sessions derived from these rules. > > The middlebox part must take care about removing pending > sessions. Though > if a policy rule is removed, the middlebox should free any > resource that > has been allocated through this binding (the box should of course not > remove for example firewall rules and NAT configuration that is still > needed by other flows). > > > Different > > middle box may have different timeouts for its sessions. If > one session > > times > > out(for example, one of the audio channels may not send > data at all for a > > period > > of time), it can not be re-established if the corresponding rule has > > already > > been removed. > > But that is the intention. If the corresponding policy rule has been > removed, the middlebox should block the stuff. > In order to prevent the situation I've discribed above(some of the sessions might be timed out during a call), you have to keep all the rules around. As we know, in many cases(e.g. SIP), the rules has wildcards attributes(cones). Sessions are tightest rules in a sense. Keeping rules around while having sessions derived from them not only wastes resources but decreases security as well(leaving holes on the firewall during the entire call). Thanks again, Wanqun > > > At the meantime, we don't want to keep rules around for a long time. > > One way to solve this is to let an agent tell the middlebox > to use a flow > > session > > timeout for the entire group. As long as there's one > session in the group > > that's > > alive within this timeout, none of the sessions within the > group should be > > timed out. > > > > 3. Group Lifetime > > A group can be removed using GLC with lifetime being 0. > > A group should be removed when there is no rule and derived > session in the > > group. > > A group's lifetime should be reset whenever there's a > request(except GLC > > with > > lifetime being 0) from the agent. > > A group should be timed out using its lifetime which is > independent to its > > rules > > and derived sessions(to clean up "dead" calls with media > still sending.) > > > > 4. In 2.3.9., should PER also include a "service" field? > > It was decided (in favor of having a unified PER, please see > above) to go > this way: We you need to choose the service, you first must a PRR > transaction and afterwards you issue the PER transaction on > the reserved > policy reserve rule. > > > > > > > Thanks, > > You are welcome and thank you again for the comments. I hope I have > answered the properly. > > Cheers > Martin > > > > > Wanqun > > > >> > >> | > >> | That's all for now. > >> > >> Thanks for the comments. > >> Martin > >> > >> [... cut by Martin ] > >> > >> _______________________________________________ > >> midcom mailing list > >> midcom@ietf.org > >> https://www1.ietf.org/mailman/listinfo/midcom > >> > > > > > > ----------------------------------------- > This email was sent using SquirrelMail. > "Webmail for nuts!" > http://squirrelmail.org/ > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 9 22:07:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20903 for ; Thu, 9 Oct 2003 22:07:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mgN-0000cT-Mr for midcom-archive@odin.ietf.org; Thu, 09 Oct 2003 22:07:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A277hT002360 for midcom-archive@odin.ietf.org; Thu, 9 Oct 2003 22:07:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mgI-0000aG-6V; Thu, 09 Oct 2003 22:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mgF-0000Zm-1V for midcom@optimus.ietf.org; Thu, 09 Oct 2003 22:06:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20882 for ; Thu, 9 Oct 2003 22:06:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7mgB-0007fp-00 for midcom@ietf.org; Thu, 09 Oct 2003 22:06:55 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7mgB-0007fg-00 for midcom@ietf.org; Thu, 09 Oct 2003 22:06:55 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9A266h14654; Thu, 9 Oct 2003 22:06:06 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4S66S50Y; Thu, 9 Oct 2003 22:06:07 -0400 Received: from nortelnetworks.com (acart1b1.ca.nortel.com [47.129.129.11]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NCR8; Thu, 9 Oct 2003 22:06:07 -0400 Message-ID: <3F861407.6090604@nortelnetworks.com> Date: Thu, 09 Oct 2003 22:05:59 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: martin@ccrle.nec.de, quittek@ccrle.nec.de CC: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Service identifier in PRR Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit When did the service parameter get added to the PRR request? I think that's a mistake. Either a given internal address space overlaps with the public space so that twice-NAT is required, or it does not. In any event, the agent isn't going to know whether it needs twice vs. single NAT -- only the middlebox has the necessary information, in its configuration. I'm wondering a bit about the external interface parameter in PRR. It would only matter if the flow were going from one internal address space to another. Surely address mapping on the public side is independent of which interface is being used. I would assume (unless someone corrects me) that if a given interface can reach any public addresses it can reach and be reached by all of them, except under failure conditions. (It just occurred to me that this is overly optimistic, since great swathes of public space are walled off by firewalls. Oh, well, someone else can comment on how important it is to allow for the possibility that different interfaces reach different parts of public space.) As a BTW, I notice that the current draft of the NAT MIB assumes that one end of every flow is in the public address space -- there seems to be no provision for internal A-to-internal B flows. Tom Taylor _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 10 06:20:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17252 for ; Fri, 10 Oct 2003 06:20:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uNV-00064b-Rg for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 06:20:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AAK9pL023295 for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 06:20:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uNO-00062f-Ls; Fri, 10 Oct 2003 06:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uMV-000611-Co for midcom@optimus.ietf.org; Fri, 10 Oct 2003 06:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17215 for ; Fri, 10 Oct 2003 06:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7uMR-0005SB-00 for midcom@ietf.org; Fri, 10 Oct 2003 06:19:03 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A7uMQ-0005Ry-00 for midcom@ietf.org; Fri, 10 Oct 2003 06:19:02 -0400 Received: from [172.16.2.7] (unknown [195.65.142.254]) by ftp.ccrle.nec.de (Postfix) with ESMTP id A84CBF5A6; Fri, 10 Oct 2003 12:23:17 +0200 (CEST) Date: Fri, 10 Oct 2003 12:18:59 +0200 From: Martin Stiemerling To: Wanqun Bao Cc: midcom@ietf.org, quittek@ccrle.nec.de Subject: RE: Fwd: [midcom] Changes in semantics (Version 05) Message-ID: <63870000.1065781139@localhost.office> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Wanqun, --On Thursday, October 09, 2003 14:41:53 -0700 Wanqun Bao wrote: | Martin, | | Thanks very much for the answers. Please see the inline comments. You are welcome! I have shortened the email to the necessary parts, since I'm sitting on small bandwidth line. Martin [...] |> A PID returned from the middlebox identifiers a midcom policy |> rule, which |> may infact represent multiple firewall rules and NAT |> configuration. The |> PID out of the PRR is used for creating policy rules in PER, |> that's right. |> | Agreed. But as long as an agent wants to manage these derived | firewall rules and NAT mappings as a whole(a midcom policy | rule), a single PID is enough. Right, a single PID is enough. The idea behind a PRR PID and (perhaps) a different PER PID is to leave some flexibility to the implementors. Ideally the both PIDs are the same. [...] |> Right, but you can use PRR to reserve A1 and you get A2 as |> well. In PRR |> you don't need to know the external peer's address. As for |> instance in a |> SIP call from a peer behind a NAT: On the first INVITE you |> don't know the |> peer's address on the other side (the callee). In this case |> you can use |> PRR or PER in the case you want to support SIP early media. |> | Agreed. In terms of supporting SIP early media, if PRR then PER | is used, there's a chance that the some of the early media | will be dropped by the middlebox within the window between right | after the callee gets the INVITE and starts sending early media and | before the moddlebox processing the PER. Depending on the situation, | this window may not be small because the agent only sends PER out | after it receives 200 OK. Agreed. [...] |> |> |> > What about if the protocol is TCP? |> > If the direction of flow really applies to the initial |> packet, we need |> > specify it clearly in the doc. |> |> Do you think that needs some clarification? Could you propose |> some text? |> | There's a difference between the direction of the initial packet | and the direction of the flow(all the packets). Based on | your explanation, the "direction of flow" refers to the later. This's | fine. | What's interesting is that if there's a field that indicates the direction | of the initial packet, we can effectively tighten the rule. For example, | in the case of TCP, the direction of flow has to be bi-directional, which | allows both internal and external to initiate a session. If a direction of | initial packet is used and set to either "inbound" or "outboud", which | can effectively allow only one direction of initiation. Yes, you are right. I have to check this in the semantics and coming back in again on that. [...] |> > Different |> > middle box may have different timeouts for its sessions. If |> one session |> > times |> > out(for example, one of the audio channels may not send |> data at all for a |> > period |> > of time), it can not be re-established if the corresponding rule has |> > already |> > been removed. |> |> But that is the intention. If the corresponding policy rule has been |> removed, the middlebox should block the stuff. |> | In order to prevent the situation I've discribed above(some of the | sessions might be timed out during a call), you have to keep all the rules | around. As we know, in many cases(e.g. SIP), the rules has wildcards | attributes(cones). Sessions are tightest rules in a sense. Keeping rules | around while having sessions derived from them not only wastes resources | but decreases security as well(leaving holes on the firewall during the | entire call). I see the problem your are describing. For each audio channel you would setup a policy rule, isn't it? If this audio channel is dead and the corresponding NAT session is going to timeout, the middlebox may remove the NAT session (plus a NAT bind) and sent a ARE notification to the agent indicating the deletion of the policy rule. But the scenario you are pointing to is when a audio channel is dead for the idle timeout, but it is from the SIP view still active (Hope that is the scenario). A solution for this is to set the policy rule lifetime in the beginning to the idle timeout for instance. The agent should extend the lifetime at the given time. [...] Regards Martin Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 10 06:25:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17547 for ; Fri, 10 Oct 2003 06:25:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uSG-0006eU-1l for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 06:25:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AAP30K025544 for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 06:25:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uSF-0006dY-2M; Fri, 10 Oct 2003 06:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uRp-0006b8-PA for midcom@optimus.ietf.org; Fri, 10 Oct 2003 06:24:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17501 for ; Fri, 10 Oct 2003 06:24:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7uRl-0005jP-00 for midcom@ietf.org; Fri, 10 Oct 2003 06:24:33 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A7uRk-0005jJ-00 for midcom@ietf.org; Fri, 10 Oct 2003 06:24:33 -0400 Received: from [172.16.2.7] (unknown [195.65.142.254]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 96071F5A6; Fri, 10 Oct 2003 12:28:49 +0200 (CEST) Date: Fri, 10 Oct 2003 12:24:32 +0200 From: Martin Stiemerling To: Tom Taylor , quittek@ccrle.nec.de Cc: midcom@ietf.org Message-ID: <68700000.1065781472@localhost.office> In-Reply-To: <3F861407.6090604@nortelnetworks.com> References: <3F861407.6090604@nortelnetworks.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Service identifier in PRR Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Tom, --On Thursday, October 09, 2003 22:05:59 -0400 Tom Taylor wrote: | When did the service parameter get added to the PRR request? I think | that's a mistake. Either a given internal address space overlaps with | the public space so that twice-NAT is required, or it does not. In any | event, the agent isn't going to know whether it needs twice vs. single | NAT -- only the middlebox has the necessary information, in its | configuration. The service parameter was added to PRR on a request from Bop Penfield. He described middleboxes that have dual-character: Being traditional NAT and twice NAT in one box and the same time. Never have heard about that earlier, but these middleboxes seem to exist. The service of the middlebox can be choosen depending on the target. | | I'm wondering a bit about the external interface parameter in PRR. It | would only matter if the flow were going from one internal address space | to another. Surely address mapping on the public side is independent of | which interface is being used. I would assume (unless someone corrects | me) that if a given interface can reach any public addresses it can reach | and be reached by all of them, except under failure conditions. (It just | occurred to me that this is overly optimistic, since great swathes of | public space are walled off by firewalls. Oh, well, someone else can | comment on how important it is to allow for the possibility that | different interfaces reach different parts of public space.) We added the external interface identifier on request of Pyda. He argued that without these parameters no real configuration could be done. Perhaps you are describing some good reasons (having the Internet divided into different 'reachability areas'. Martin | | As a BTW, I notice that the current draft of the NAT MIB assumes that one | end of every flow is in the public address space -- there seems to be no | provision for internal A-to-internal B flows. | | Tom Taylor | Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 10 06:37:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18117 for ; Fri, 10 Oct 2003 06:37:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uds-0007RS-Em for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 06:37:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AAb4F0028577 for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 06:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7udp-0007PQ-CL; Fri, 10 Oct 2003 06:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ud3-0007JE-DE for midcom@optimus.ietf.org; Fri, 10 Oct 2003 06:36:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18076 for ; Fri, 10 Oct 2003 06:36:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ucz-0006IY-00 for midcom@ietf.org; Fri, 10 Oct 2003 06:36:09 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A7ucx-0006IP-00 for midcom@ietf.org; Fri, 10 Oct 2003 06:36:07 -0400 Received: from [172.16.2.7] (unknown [195.65.142.254]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 33D7CF5A6; Fri, 10 Oct 2003 12:40:24 +0200 (CEST) Date: Fri, 10 Oct 2003 12:36:06 +0200 From: Martin Stiemerling To: Wanqun Bao Cc: midcom@ietf.org, quittek@ccrle.nec.de Message-ID: <91000000.1065782166@localhost.office> In-Reply-To: <82CC1E573B94A648B87027C9419E2C05FDAC48@LOSGATOS.netscreen.com> References: <82CC1E573B94A648B87027C9419E2C05FDAC48@LOSGATOS.netscreen.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] TCP plus inbound, outbound and bi-directional Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Wanqun, I have checked the semantics for the semantics of inbound, outbound, and bi-directional. The current meaning is meaningful for UDP streams, but lacks indeed a more precise semantics for TCP. I would propose to say that for TCP: - inbound: First packet must arrive at the outside of the middlebox - outbound: First packet must arrive at the inside of the middlebox - bi-directional: First packet can arrive either outside or inside of the firewall. Thanks for pointing this out. Cheers Martin --On Thursday, October 09, 2003 14:41:53 -0700 Wanqun Bao wrote: | Martin, | | Thanks very much for the answers. Please see the inline comments. | | Wanqun | |> -----Original Message----- |> From: martin@ccrle.nec.de [mailto:martin@ccrle.nec.de] |> Sent: Thursday, October 09, 2003 9:00 AM |> To: Wanqun Bao |> Cc: midcom@ietf.org; quittek@ccrle.nec.de |> Subject: RE: Fwd: [midcom] Changes in semantics (Version 05) |> |> |> Hi Wanqun Bao, |> |> many thanks for your comments! |> |> See answers inline. |> |> Cheers |> Martin |> |> > Hi Martin, |> > |> > I have some comments inline and some general comments |> > regarding the draft following that. |> > |> > Thanks, |> > |> > Wanqun Bao |> > |> >> -----Original Message----- |> >> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] |> >> Sent: Wednesday, October 08, 2003 6:57 AM |> >> To: Pyda Srisuresh |> >> Cc: midcom@ietf.org |> >> Subject: Re: Fwd: [midcom] Changes in semantics (Version 05) |> >> |> >> |> >> Hi Suresh, |> >> |> >> thanks for checking the document again. More comments inline |> >> and I hope on |> >> more comments from other working group members. |> >> |> >> Martin |> >> |> >> --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh |> >> wrote: |> >> |> >> | Hi, |> >> | |> >> | I briefly read through the draft this weekend. I still do |> >> not believe, the |> >> | semantics is clear. The abstractions are not adequate to |> eliminate |> >> | ALGs from a middlebox. |> >> | |> >> | 1. Terminology - I do not believe, you should proliferate |> >> of semantics |> >> | for "NAT binding". This sounds like, it will be whatever |> >> you want it to |> >> | be in sessing up a session. |> >> |> >> The intention was not to proliferate, but more an approach to |> >> bring more |> >> light to issue of NAT binding. Do you think that it confuses |> >> more than it |> >> does help? |> >> |> >> | |> >> | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP |> >> addresses (in |> >> | the case of twice-NAT) and/or several ports on an address. |> >> Depending upon |> >> | what the agent lists in the request parameters, this can be |> >> reservation |> >> | of an address bind, or reservation of a bunch of ports |> >> (from a NAPT map |> >> | entry, presumably) or reservation of an address each from two map |> >> | entries. The middlebox returned rule identifier can |> >> represent any of this |> >> | (Bind handle or single map reservation or two address map |> >> reservations). |> >> | This is simply a lot of stuff in a single transaction. Very |> >> difficult and |> >> | confusing for a middlebox to do this. |> >> |> >> Yes, that may look confusing, but pushing the task to the |> >> MIDCOM agent is |> >> more even more confusing to him. |> >> |> > My understanding is that a PID returned from the middlebox uniquely |> > identifies a rule which contains a tightly related set of reserved |> > resources(either one or two IP addresses, transport type, and port |> > number(s)). |> > These resources will be used for creating pinholes using PER. |> |> A PID returned from the middlebox identifiers a midcom policy |> rule, which |> may infact represent multiple firewall rules and NAT |> configuration. The |> PID out of the PRR is used for creating policy rules in PER, |> that's right. |> | Agreed. But as long as an agent wants to manage these derived | firewall rules and NAT mappings as a whole(a midcom policy | rule), a single PID is enough. | |> > |> >> | |> >> | Specifying the internal IP address helps in reserving a |> >> pool of ports in |> >> | a NAPT case or an address BIND in the case of basic NAT. |> >> But, that alone |> >> | is not adequate for twice-NAT. The transaction needs to |> include the |> >> | destinaion end-point. otherwise, PRR is not usable for |> >> Twice-NAT for the |> >> | same reason the PRR was not usable for traditional NAT in |> >> the previous |> >> | rev of the draft. The middlebox cannot pick up an arbitrary |> >> address from |> >> | one of the map entries for twice-nat, not with just A0 in |> >> the request |> >> | list. |> >> |> >> The idea behind PRR is that the agent does not know the destination |> >> address. |> >> |> >> This is the case for example in SIP call set-up. Only the |> >> data receiver in |> >> the private address realm is known on the first INVITE, if |> >> the caller is in |> >> this private address realm. This is a very tricky thing |> and PRR does |> >> provide a good mean to cope with that, even when it looks |> >> somehow strange. |> >> I could offer a powerpoint presentation from one of the |> IETF meetings |> >> explaining the need for PRR if you like. |> >> |> > A middlebox does not need A3 to reserve A1. To me, a reservation |> > can be made without its final binding peer. Binding is only |> > needed when a PER is made, which will be used for the flow |> session(the |> > actual traffic). |> |> Right, but you can use PRR to reserve A1 and you get A2 as |> well. In PRR |> you don't need to know the external peer's address. As for |> instance in a |> SIP call from a peer behind a NAT: On the first INVITE you |> don't know the |> peer's address on the other side (the callee). In this case |> you can use |> PRR or PER in the case you want to support SIP early media. |> | Agreed. In terms of supporting SIP early media, if PRR then PER | is used, there's a chance that the some of the early media | will be dropped by the middlebox within the window between right | after the callee gets the INVITE and starts sending early media and | before the moddlebox processing the PER. Depending on the situation, | this window may not be small because the agent only sends PER out | after it receives 200 OK. | | |> > On the other hand, if A3 is known and presented in the PRR request, |> > later PER needs not to really mention A1 and A3(although they |> > can be used for verification purpose.) |> |> As described above PRR is intended for cases when A3 is known |> in advance. |> So it is needed to have A3 in the PER. A1 is needed in PER |> since there is |> a unified PER transaction, independently of having a reserved |> policy rule |> (via PRR) or or having not a reserved policy rule. We |> discussed earlier in |> the working group, if it is wise to split PER into two |> different PER. The |> consensus was not to split PER. | You meant PRR is intended for cases when A3 is NOT known. Right? | |> |> > What is interesting is that in the case of SIP, even after call is |> > set-up(an ACK is sent from the caller), we may not really know the |> > source IP for the media from both directions until they |> > actually arrive at the middle box(e.g., a media gateway uses one IP |> > for sending and another IP for receiving). |> |> Fully agreed. That's the above scenario for SIP. In this case |> the PRR is |> needed. |> |> > |> >> | |> >> | As I said earlier, I suggest, the PRR be simplified split |> >> up into doing |> >> | BIND reservations and MAP reservations independently. |> >> | |> >> | 3. PER should simply be labelled as session creation |> >> request. The text in |> >> | the draft that refers this as BIND in some cases shoudl simply be |> >> | eliminated. PER essentially boils down to setting up NAT |> >> sessions/flows |> >> | using pre-established binds or pre-reserved map entries or simply |> >> | creating a new session. When the session is created, the |> >> response should |> >> | indicate the BINDs used, if any, and the translation |> >> end-points for the |> >> | session. |> >> |> >> You are right in saying that with PER a NAT session is |> >> created. But for |> >> instance consider this scenario: |> >> |> >> A PER request with an internal address (A0) and a |> wildcarded external |> >> sender (A3) (dataflow from outside to inside). The external |> >> sender is not |> >> known (One example is SIP early media). For that case you can |> >> not start a |> >> NAT session, since the NAT must create a NAT bind. Via |> this NAT bind |> >> several UDP/RTP flows from several destinations may traverse |> >> the middlebox |> >> to A0. |> >> |> > Just want to add that enabling a rule is not the same as creating |> > a session. A session is only created when actual traffic comes |> > and matches a rule. |> |> That depends on your implementation. Perhaps you implement |> the PER in a |> way that you load sessions into your NAT. Perhaps not. I see |> that this is |> a difference, but this should be up to the implementor. |> |> > |> >> | |> >> | The twice-NAT example doesn't make sense. If the session is |> >> between A0 & |> >> | A1 (as would be in the case of twice-NAT) the agent cannot |> >> know A3 ahead |> >> | of time. However, that is what the PER request parametere |> >> description |> >> | indicates. |> >> |> >> Hmm, I don't see the issue you raise immediately. |> >> |> >> A3 is the external end point and A1 the inside IP |> >> address/port number at |> >> the twice-NAT. The application level session is between A0 |> >> and A3, but the |> >> IP/transport 'sessions' are between A0/A1 and A2/A3. |> >> |> >> Could you give me some more hints? |> >> |> >> |> >> | 3. The document says in several places that the NAT is one |> >> of traditional |> >> | NAT or Twice-NAT. What about bi-directional NAT? I saw this |> >> mentioned |> >> | just once in PER description. When you support |> >> bi-directional NAT, it is |> >> | important for the PRR and PERs to support sessions |> >> initiated from the |> >> | outside, in additiona to sessions initiated from the |> >> private realm. The |> >> | request parameters in PRR and PER are not adequate to |> support this. |> >> |> >> That's not true. For PRR the direction is not relevant, |> since only a |> >> resource reservation is made at the NAT. In PER there is the |> >> flow direction |> >> parameter that indicates the flow direction (inbound, outbound, or |> >> bi-directional). So with this it is possible to allow even sessions |> >> initiated from the outside. |> >> |> > Does "direction of flow" applies only to the initial packet |> or to all the |> > subsequent |> > packets enabled by this rule? |> > For example, if the direction of flow is inbound and the |> protocol is UDP, |> > the first packet comes from external to internal(inbound), |> it matches a |> > rule and a session is created. Will the middlebox drop any |> outbound packet |> > that actually matches with the session created? |> |> Right. If 'inbound' is selected only inbound packets can traverse the |> middlebox (necessary for configuration of firewall rules). So |> if you need |> in and outbound packet flow for this specific flow you have |> to specifiy |> bi-directional. TCP must use always bi-directional, otherwise |> it doesn't |> make sense. The TCP and bi-directional should be stated in |> the semantics, |> unfortunately I don't have them by now, so I can not show the section |> where it is printed. |> |> |> |> > What about if the protocol is TCP? |> > If the direction of flow really applies to the initial |> packet, we need |> > specify it clearly in the doc. |> |> Do you think that needs some clarification? Could you propose |> some text? |> | There's a difference between the direction of the initial packet | and the direction of the flow(all the packets). Based on | your explanation, the "direction of flow" refers to the later. This's | fine. | What's interesting is that if there's a field that indicates the direction | of the initial packet, we can effectively tighten the rule. For example, | in the case of TCP, the direction of flow has to be bi-directional, which | allows both internal and external to initiate a session. If a direction of | initial packet is used and set to either "inbound" or "outboud", which | can effectively allow only one direction of initiation. | |> > |> >> | |> >> | 4. I still have an issue with GroupId assignment being |> >> mandated on the |> >> | middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 |> >> does not madate |> >> | this. |> >> |> >> Right the protocol requirements do not mandate this, but as a |> >> lot of other |> >> points this is a design issue. So far nobody else has any |> >> objection about |> >> this. |> >> |> > I think GroupId is really needed for efficiently managing |> resources(rules) |> > in |> > the middle box. |> |> Fully agreed! |> |> > |> > I have some general comments regarding the draft: |> > 1. Rule's lifetime |> > For PRR, it is simple: if a PRR is not replaced by a PER in |> its lifetime, |> > it |> > will be removed. It's a resource cleanup and there's no |> security issues. |> > For PER, a rule is enabled(a pinhole is punched and in most |> cases, it's |> > a cone). If there's no packet that macthes with the rule |> within rule's |> > lifetime, |> > the rule is removed. But what happens to the rule after the |> first packet |> > matches |> > with rule and a session is created for the intended flow? |> In many cases, |> > in |> > order |> > to tighten the security, the pinhole should be closed |> immediately after |> > the |> > first |> > packet comes and a session is created. A new field in PER |> might be needed |> > to |> > indicate that and the policy rule state machine should be modified |> > accordingly. |> |> I feel that is an issue for local policies. If the sytem adiminstrator |> feels that this is needed he can configure the box in that way. MIDCOM |> provides the ARE (asyncrhonous rule event notification) in |> order to tell |> the agent that the policy rule was removed. |> |> > |> > 2. Flow sessions derived from rules |> > Forgive me if this has been discussed here before. In this |> draft, except |> > "direction of flow", handling of flow sessions is totally excluded. |> > Correct me if I'm wrong, MIDCOM is used to allow |> application-layer enabled |> > traffic to traverse the middlebox. Traverse does not stop |> after a flow |> > session |> > is created. From the current draft, if an agent creates a |> number of rules |> > under |> > a group, intended traffic will traverse the middle box. |> After all the |> > rules |> > are timeout, the group with all its members(rules) is |> removed. What's left |> > in the middle box are the flow sessions derived from these rules. |> |> The middlebox part must take care about removing pending |> sessions. Though |> if a policy rule is removed, the middlebox should free any |> resource that |> has been allocated through this binding (the box should of course not |> remove for example firewall rules and NAT configuration that is still |> needed by other flows). |> |> > Different |> > middle box may have different timeouts for its sessions. If |> one session |> > times |> > out(for example, one of the audio channels may not send |> data at all for a |> > period |> > of time), it can not be re-established if the corresponding rule has |> > already |> > been removed. |> |> But that is the intention. If the corresponding policy rule has been |> removed, the middlebox should block the stuff. |> | In order to prevent the situation I've discribed above(some of the | sessions might be timed out during a call), you have to keep all the rules | around. As we know, in many cases(e.g. SIP), the rules has wildcards | attributes(cones). Sessions are tightest rules in a sense. Keeping rules | around while having sessions derived from them not only wastes resources | but decreases security as well(leaving holes on the firewall during the | entire call). | | Thanks again, | | Wanqun | |> |> > At the meantime, we don't want to keep rules around for a long time. |> > One way to solve this is to let an agent tell the middlebox |> to use a flow |> > session |> > timeout for the entire group. As long as there's one |> session in the group |> > that's |> > alive within this timeout, none of the sessions within the |> group should be |> > timed out. |> > |> > 3. Group Lifetime |> > A group can be removed using GLC with lifetime being 0. |> > A group should be removed when there is no rule and derived |> session in the |> > group. |> > A group's lifetime should be reset whenever there's a |> request(except GLC |> > with |> > lifetime being 0) from the agent. |> > A group should be timed out using its lifetime which is |> independent to its |> > rules |> > and derived sessions(to clean up "dead" calls with media |> still sending.) |> > |> > 4. In 2.3.9., should PER also include a "service" field? |> |> It was decided (in favor of having a unified PER, please see |> above) to go |> this way: We you need to choose the service, you first must a PRR |> transaction and afterwards you issue the PER transaction on |> the reserved |> policy reserve rule. |> |> > |> > |> > Thanks, |> |> You are welcome and thank you again for the comments. I hope I have |> answered the properly. |> |> Cheers |> Martin |> |> > |> > Wanqun |> > |> >> |> >> | |> >> | That's all for now. |> >> |> >> Thanks for the comments. |> >> Martin |> >> |> >> [... cut by Martin ] |> >> |> >> _______________________________________________ |> >> midcom mailing list |> >> midcom@ietf.org |> >> https://www1.ietf.org/mailman/listinfo/midcom |> >> |> > |> |> |> |> ----------------------------------------- |> This email was sent using SquirrelMail. |> "Webmail for nuts!" |> http://squirrelmail.org/ |> Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 10 13:20:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08350 for ; Fri, 10 Oct 2003 13:20:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80vz-00037p-4P for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 13:20:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AHKBQs012013 for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 13:20:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80vs-00035a-BP; Fri, 10 Oct 2003 13:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80vR-00034V-7V for midcom@optimus.ietf.org; Fri, 10 Oct 2003 13:19:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08327 for ; Fri, 10 Oct 2003 13:19:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80vP-0006WG-00 for midcom@ietf.org; Fri, 10 Oct 2003 13:19:35 -0400 Received: from mail2.netscreen.com ([63.126.135.18]) by ietf-mx with esmtp (Exim 4.12) id 1A80vO-0006Vk-00 for midcom@ietf.org; Fri, 10 Oct 2003 13:19:34 -0400 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9AHIqOh012134; Fri, 10 Oct 2003 10:18:53 -0700 (PDT) Received: by NS-CA.netscreen.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Oct 2003 10:18:52 -0700 Message-ID: <82CC1E573B94A648B87027C9419E2C05FDAC4D@LOSGATOS.netscreen.com> From: Wanqun Bao To: "'Martin Stiemerling'" , Wanqun Bao Cc: midcom@ietf.org, quittek@ccrle.nec.de Date: Fri, 10 Oct 2003 10:18:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] RE: TCP plus inbound, outbound and bi-directional Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Martin, Thanks for the precise description. Wanqun > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Friday, October 10, 2003 3:36 AM > To: Wanqun Bao > Cc: midcom@ietf.org; quittek@ccrle.nec.de > Subject: TCP plus inbound, outbound and bi-directional > > > Hi Wanqun, > > I have checked the semantics for the semantics of inbound, > outbound, and > bi-directional. > > The current meaning is meaningful for UDP streams, but lacks > indeed a more > precise semantics for TCP. > I would propose to say that for TCP: > - inbound: First packet must arrive at the outside of the middlebox > - outbound: First packet must arrive at the inside of the middlebox > - bi-directional: First packet can arrive either outside or > inside of the > firewall. > > Thanks for pointing this out. > > Cheers > Martin > > --On Thursday, October 09, 2003 14:41:53 -0700 Wanqun Bao > wrote: > > | Martin, > | > | Thanks very much for the answers. Please see the inline comments. > | > | Wanqun > | > |> -----Original Message----- > |> From: martin@ccrle.nec.de [mailto:martin@ccrle.nec.de] > |> Sent: Thursday, October 09, 2003 9:00 AM > |> To: Wanqun Bao > |> Cc: midcom@ietf.org; quittek@ccrle.nec.de > |> Subject: RE: Fwd: [midcom] Changes in semantics (Version 05) > |> > |> > |> Hi Wanqun Bao, > |> > |> many thanks for your comments! > |> > |> See answers inline. > |> > |> Cheers > |> Martin > |> > |> > Hi Martin, > |> > > |> > I have some comments inline and some general comments > |> > regarding the draft following that. > |> > > |> > Thanks, > |> > > |> > Wanqun Bao > |> > > |> >> -----Original Message----- > |> >> From: Martin Stiemerling > [mailto:Martin.Stiemerling@ccrle.nec.de] > |> >> Sent: Wednesday, October 08, 2003 6:57 AM > |> >> To: Pyda Srisuresh > |> >> Cc: midcom@ietf.org > |> >> Subject: Re: Fwd: [midcom] Changes in semantics (Version 05) > |> >> > |> >> > |> >> Hi Suresh, > |> >> > |> >> thanks for checking the document again. More comments inline > |> >> and I hope on > |> >> more comments from other working group members. > |> >> > |> >> Martin > |> >> > |> >> --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh > |> >> wrote: > |> >> > |> >> | Hi, > |> >> | > |> >> | I briefly read through the draft this weekend. I still do > |> >> not believe, the > |> >> | semantics is clear. The abstractions are not adequate to > |> eliminate > |> >> | ALGs from a middlebox. > |> >> | > |> >> | 1. Terminology - I do not believe, you should proliferate > |> >> of semantics > |> >> | for "NAT binding". This sounds like, it will be whatever > |> >> you want it to > |> >> | be in sessing up a session. > |> >> > |> >> The intention was not to proliferate, but more an approach to > |> >> bring more > |> >> light to issue of NAT binding. Do you think that it confuses > |> >> more than it > |> >> does help? > |> >> > |> >> | > |> >> | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP > |> >> addresses (in > |> >> | the case of twice-NAT) and/or several ports on an address. > |> >> Depending upon > |> >> | what the agent lists in the request parameters, this can be > |> >> reservation > |> >> | of an address bind, or reservation of a bunch of ports > |> >> (from a NAPT map > |> >> | entry, presumably) or reservation of an address each > from two map > |> >> | entries. The middlebox returned rule identifier can > |> >> represent any of this > |> >> | (Bind handle or single map reservation or two address map > |> >> reservations). > |> >> | This is simply a lot of stuff in a single transaction. Very > |> >> difficult and > |> >> | confusing for a middlebox to do this. > |> >> > |> >> Yes, that may look confusing, but pushing the task to the > |> >> MIDCOM agent is > |> >> more even more confusing to him. > |> >> > |> > My understanding is that a PID returned from the > middlebox uniquely > |> > identifies a rule which contains a tightly related set > of reserved > |> > resources(either one or two IP addresses, transport > type, and port > |> > number(s)). > |> > These resources will be used for creating pinholes using PER. > |> > |> A PID returned from the middlebox identifiers a midcom policy > |> rule, which > |> may infact represent multiple firewall rules and NAT > |> configuration. The > |> PID out of the PRR is used for creating policy rules in PER, > |> that's right. > |> > | Agreed. But as long as an agent wants to manage these derived > | firewall rules and NAT mappings as a whole(a midcom policy > | rule), a single PID is enough. > | > |> > > |> >> | > |> >> | Specifying the internal IP address helps in reserving a > |> >> pool of ports in > |> >> | a NAPT case or an address BIND in the case of basic NAT. > |> >> But, that alone > |> >> | is not adequate for twice-NAT. The transaction needs to > |> include the > |> >> | destinaion end-point. otherwise, PRR is not usable for > |> >> Twice-NAT for the > |> >> | same reason the PRR was not usable for traditional NAT in > |> >> the previous > |> >> | rev of the draft. The middlebox cannot pick up an arbitrary > |> >> address from > |> >> | one of the map entries for twice-nat, not with just A0 in > |> >> the request > |> >> | list. > |> >> > |> >> The idea behind PRR is that the agent does not know the > destination > |> >> address. > |> >> > |> >> This is the case for example in SIP call set-up. Only the > |> >> data receiver in > |> >> the private address realm is known on the first INVITE, if > |> >> the caller is in > |> >> this private address realm. This is a very tricky thing > |> and PRR does > |> >> provide a good mean to cope with that, even when it looks > |> >> somehow strange. > |> >> I could offer a powerpoint presentation from one of the > |> IETF meetings > |> >> explaining the need for PRR if you like. > |> >> > |> > A middlebox does not need A3 to reserve A1. To me, a reservation > |> > can be made without its final binding peer. Binding is only > |> > needed when a PER is made, which will be used for the flow > |> session(the > |> > actual traffic). > |> > |> Right, but you can use PRR to reserve A1 and you get A2 as > |> well. In PRR > |> you don't need to know the external peer's address. As for > |> instance in a > |> SIP call from a peer behind a NAT: On the first INVITE you > |> don't know the > |> peer's address on the other side (the callee). In this case > |> you can use > |> PRR or PER in the case you want to support SIP early media. > |> > | Agreed. In terms of supporting SIP early media, if PRR then PER > | is used, there's a chance that the some of the early media > | will be dropped by the middlebox within the window between right > | after the callee gets the INVITE and starts sending early media and > | before the moddlebox processing the PER. Depending on the situation, > | this window may not be small because the agent only sends PER out > | after it receives 200 OK. > | > | > |> > On the other hand, if A3 is known and presented in the > PRR request, > |> > later PER needs not to really mention A1 and A3(although they > |> > can be used for verification purpose.) > |> > |> As described above PRR is intended for cases when A3 is known > |> in advance. > |> So it is needed to have A3 in the PER. A1 is needed in PER > |> since there is > |> a unified PER transaction, independently of having a reserved > |> policy rule > |> (via PRR) or or having not a reserved policy rule. We > |> discussed earlier in > |> the working group, if it is wise to split PER into two > |> different PER. The > |> consensus was not to split PER. > | You meant PRR is intended for cases when A3 is NOT known. Right? > | > |> > |> > What is interesting is that in the case of SIP, even > after call is > |> > set-up(an ACK is sent from the caller), we may not > really know the > |> > source IP for the media from both directions until they > |> > actually arrive at the middle box(e.g., a media gateway > uses one IP > |> > for sending and another IP for receiving). > |> > |> Fully agreed. That's the above scenario for SIP. In this case > |> the PRR is > |> needed. > |> > |> > > |> >> | > |> >> | As I said earlier, I suggest, the PRR be simplified split > |> >> up into doing > |> >> | BIND reservations and MAP reservations independently. > |> >> | > |> >> | 3. PER should simply be labelled as session creation > |> >> request. The text in > |> >> | the draft that refers this as BIND in some cases > shoudl simply be > |> >> | eliminated. PER essentially boils down to setting up NAT > |> >> sessions/flows > |> >> | using pre-established binds or pre-reserved map > entries or simply > |> >> | creating a new session. When the session is created, the > |> >> response should > |> >> | indicate the BINDs used, if any, and the translation > |> >> end-points for the > |> >> | session. > |> >> > |> >> You are right in saying that with PER a NAT session is > |> >> created. But for > |> >> instance consider this scenario: > |> >> > |> >> A PER request with an internal address (A0) and a > |> wildcarded external > |> >> sender (A3) (dataflow from outside to inside). The external > |> >> sender is not > |> >> known (One example is SIP early media). For that case you can > |> >> not start a > |> >> NAT session, since the NAT must create a NAT bind. Via > |> this NAT bind > |> >> several UDP/RTP flows from several destinations may traverse > |> >> the middlebox > |> >> to A0. > |> >> > |> > Just want to add that enabling a rule is not the same as creating > |> > a session. A session is only created when actual traffic comes > |> > and matches a rule. > |> > |> That depends on your implementation. Perhaps you implement > |> the PER in a > |> way that you load sessions into your NAT. Perhaps not. I see > |> that this is > |> a difference, but this should be up to the implementor. > |> > |> > > |> >> | > |> >> | The twice-NAT example doesn't make sense. If the session is > |> >> between A0 & > |> >> | A1 (as would be in the case of twice-NAT) the agent cannot > |> >> know A3 ahead > |> >> | of time. However, that is what the PER request parametere > |> >> description > |> >> | indicates. > |> >> > |> >> Hmm, I don't see the issue you raise immediately. > |> >> > |> >> A3 is the external end point and A1 the inside IP > |> >> address/port number at > |> >> the twice-NAT. The application level session is between A0 > |> >> and A3, but the > |> >> IP/transport 'sessions' are between A0/A1 and A2/A3. > |> >> > |> >> Could you give me some more hints? > |> >> > |> >> > |> >> | 3. The document says in several places that the NAT is one > |> >> of traditional > |> >> | NAT or Twice-NAT. What about bi-directional NAT? I saw this > |> >> mentioned > |> >> | just once in PER description. When you support > |> >> bi-directional NAT, it is > |> >> | important for the PRR and PERs to support sessions > |> >> initiated from the > |> >> | outside, in additiona to sessions initiated from the > |> >> private realm. The > |> >> | request parameters in PRR and PER are not adequate to > |> support this. > |> >> > |> >> That's not true. For PRR the direction is not relevant, > |> since only a > |> >> resource reservation is made at the NAT. In PER there is the > |> >> flow direction > |> >> parameter that indicates the flow direction (inbound, > outbound, or > |> >> bi-directional). So with this it is possible to allow > even sessions > |> >> initiated from the outside. > |> >> > |> > Does "direction of flow" applies only to the initial packet > |> or to all the > |> > subsequent > |> > packets enabled by this rule? > |> > For example, if the direction of flow is inbound and the > |> protocol is UDP, > |> > the first packet comes from external to internal(inbound), > |> it matches a > |> > rule and a session is created. Will the middlebox drop any > |> outbound packet > |> > that actually matches with the session created? > |> > |> Right. If 'inbound' is selected only inbound packets can > traverse the > |> middlebox (necessary for configuration of firewall rules). So > |> if you need > |> in and outbound packet flow for this specific flow you have > |> to specifiy > |> bi-directional. TCP must use always bi-directional, otherwise > |> it doesn't > |> make sense. The TCP and bi-directional should be stated in > |> the semantics, > |> unfortunately I don't have them by now, so I can not show > the section > |> where it is printed. > |> > |> > |> > |> > What about if the protocol is TCP? > |> > If the direction of flow really applies to the initial > |> packet, we need > |> > specify it clearly in the doc. > |> > |> Do you think that needs some clarification? Could you propose > |> some text? > |> > | There's a difference between the direction of the initial packet > | and the direction of the flow(all the packets). Based on > | your explanation, the "direction of flow" refers to the > later. This's > | fine. > | What's interesting is that if there's a field that > indicates the direction > | of the initial packet, we can effectively tighten the rule. > For example, > | in the case of TCP, the direction of flow has to be > bi-directional, which > | allows both internal and external to initiate a session. If > a direction of > | initial packet is used and set to either "inbound" or > "outboud", which > | can effectively allow only one direction of initiation. > | > |> > > |> >> | > |> >> | 4. I still have an issue with GroupId assignment being > |> >> mandated on the > |> >> | middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 > |> >> does not madate > |> >> | this. > |> >> > |> >> Right the protocol requirements do not mandate this, but as a > |> >> lot of other > |> >> points this is a design issue. So far nobody else has any > |> >> objection about > |> >> this. > |> >> > |> > I think GroupId is really needed for efficiently managing > |> resources(rules) > |> > in > |> > the middle box. > |> > |> Fully agreed! > |> > |> > > |> > I have some general comments regarding the draft: > |> > 1. Rule's lifetime > |> > For PRR, it is simple: if a PRR is not replaced by a PER in > |> its lifetime, > |> > it > |> > will be removed. It's a resource cleanup and there's no > |> security issues. > |> > For PER, a rule is enabled(a pinhole is punched and in most > |> cases, it's > |> > a cone). If there's no packet that macthes with the rule > |> within rule's > |> > lifetime, > |> > the rule is removed. But what happens to the rule after the > |> first packet > |> > matches > |> > with rule and a session is created for the intended flow? > |> In many cases, > |> > in > |> > order > |> > to tighten the security, the pinhole should be closed > |> immediately after > |> > the > |> > first > |> > packet comes and a session is created. A new field in PER > |> might be needed > |> > to > |> > indicate that and the policy rule state machine should > be modified > |> > accordingly. > |> > |> I feel that is an issue for local policies. If the sytem > adiminstrator > |> feels that this is needed he can configure the box in that > way. MIDCOM > |> provides the ARE (asyncrhonous rule event notification) in > |> order to tell > |> the agent that the policy rule was removed. > |> > |> > > |> > 2. Flow sessions derived from rules > |> > Forgive me if this has been discussed here before. In this > |> draft, except > |> > "direction of flow", handling of flow sessions is > totally excluded. > |> > Correct me if I'm wrong, MIDCOM is used to allow > |> application-layer enabled > |> > traffic to traverse the middlebox. Traverse does not stop > |> after a flow > |> > session > |> > is created. From the current draft, if an agent creates a > |> number of rules > |> > under > |> > a group, intended traffic will traverse the middle box. > |> After all the > |> > rules > |> > are timeout, the group with all its members(rules) is > |> removed. What's left > |> > in the middle box are the flow sessions derived from these rules. > |> > |> The middlebox part must take care about removing pending > |> sessions. Though > |> if a policy rule is removed, the middlebox should free any > |> resource that > |> has been allocated through this binding (the box should of > course not > |> remove for example firewall rules and NAT configuration > that is still > |> needed by other flows). > |> > |> > Different > |> > middle box may have different timeouts for its sessions. If > |> one session > |> > times > |> > out(for example, one of the audio channels may not send > |> data at all for a > |> > period > |> > of time), it can not be re-established if the > corresponding rule has > |> > already > |> > been removed. > |> > |> But that is the intention. If the corresponding policy > rule has been > |> removed, the middlebox should block the stuff. > |> > | In order to prevent the situation I've discribed above(some of the > | sessions might be timed out during a call), you have to > keep all the rules > | around. As we know, in many cases(e.g. SIP), the rules has wildcards > | attributes(cones). Sessions are tightest rules in a sense. > Keeping rules > | around while having sessions derived from them not only > wastes resources > | but decreases security as well(leaving holes on the > firewall during the > | entire call). > | > | Thanks again, > | > | Wanqun > | > |> > |> > At the meantime, we don't want to keep rules around for > a long time. > |> > One way to solve this is to let an agent tell the middlebox > |> to use a flow > |> > session > |> > timeout for the entire group. As long as there's one > |> session in the group > |> > that's > |> > alive within this timeout, none of the sessions within the > |> group should be > |> > timed out. > |> > > |> > 3. Group Lifetime > |> > A group can be removed using GLC with lifetime being 0. > |> > A group should be removed when there is no rule and derived > |> session in the > |> > group. > |> > A group's lifetime should be reset whenever there's a > |> request(except GLC > |> > with > |> > lifetime being 0) from the agent. > |> > A group should be timed out using its lifetime which is > |> independent to its > |> > rules > |> > and derived sessions(to clean up "dead" calls with media > |> still sending.) > |> > > |> > 4. In 2.3.9., should PER also include a "service" field? > |> > |> It was decided (in favor of having a unified PER, please see > |> above) to go > |> this way: We you need to choose the service, you first must a PRR > |> transaction and afterwards you issue the PER transaction on > |> the reserved > |> policy reserve rule. > |> > |> > > |> > > |> > Thanks, > |> > |> You are welcome and thank you again for the comments. I hope I have > |> answered the properly. > |> > |> Cheers > |> Martin > |> > |> > > |> > Wanqun > |> > > |> >> > |> >> | > |> >> | That's all for now. > |> >> > |> >> Thanks for the comments. > |> >> Martin > |> >> > |> >> [... cut by Martin ] > |> >> > |> >> _______________________________________________ > |> >> midcom mailing list > |> >> midcom@ietf.org > |> >> https://www1.ietf.org/mailman/listinfo/midcom > |> >> > |> > > |> > |> > |> > |> ----------------------------------------- > |> This email was sent using SquirrelMail. > |> "Webmail for nuts!" > |> http://squirrelmail.org/ > |> > > > > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 10 14:23:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10803 for ; Fri, 10 Oct 2003 14:23:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81up-0007tr-1u for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 14:23:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIN3kL030360 for midcom-archive@odin.ietf.org; Fri, 10 Oct 2003 14:23:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81um-0007tH-BZ; Fri, 10 Oct 2003 14:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81uX-0007oH-Fe for midcom@optimus.ietf.org; Fri, 10 Oct 2003 14:22:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10740 for ; Fri, 10 Oct 2003 14:22:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81uT-0007Ff-00 for midcom@ietf.org; Fri, 10 Oct 2003 14:22:41 -0400 Received: from mail2.netscreen.com ([63.126.135.18]) by ietf-mx with esmtp (Exim 4.12) id 1A81uS-0007FW-00 for midcom@ietf.org; Fri, 10 Oct 2003 14:22:40 -0400 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9AIM2Oh017604; Fri, 10 Oct 2003 11:22:02 -0700 (PDT) Received: by NS-CA.netscreen.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Oct 2003 11:22:02 -0700 Message-ID: <82CC1E573B94A648B87027C9419E2C05FDAC4E@LOSGATOS.netscreen.com> From: Wanqun Bao To: "'Martin Stiemerling'" , Wanqun Bao Cc: midcom@ietf.org, quittek@ccrle.nec.de Subject: RE: Fwd: [midcom] Changes in semantics (Version 05) Date: Fri, 10 Oct 2003 11:21:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, Martin, Thanks for the response. I've removed all other discussions but one below which I'd like to have more discussion. See inlines. Cheers, Wanqun > |> > Wanqun Wrote: > |> > > |> > Different > |> > middle box may have different timeouts for its sessions. If > |> one session > |> > times > |> > out(for example, one of the audio channels may not send > |> data at all for a > |> > period > |> > of time), it can not be re-established if the > corresponding rule has > |> > already > |> > been removed. > |> > |> But that is the intention. If the corresponding policy > rule has been > |> removed, the middlebox should block the stuff. > |> > | In order to prevent the situation I've discribed above(some of the > | sessions might be timed out during a call), you have to > keep all the rules > | around. As we know, in many cases(e.g. SIP), the rules has wildcards > | attributes(cones). Sessions are tightest rules in a sense. > Keeping rules > | around while having sessions derived from them not only > wastes resources > | but decreases security as well(leaving holes on the > firewall during the > | entire call). > > I see the problem your are describing. > For each audio channel you would setup a policy rule, isn't > it? If this > audio channel is dead and the corresponding NAT session is going to > timeout, the middlebox may remove the NAT session (plus a NAT > bind) and > sent a ARE notification to the agent indicating the deletion > of the policy > rule. > But the scenario you are pointing to is when a audio channel > is dead for > the idle timeout, but it is from the SIP view still active > (Hope that is > the scenario). A solution for this is to set the policy rule > lifetime in > the beginning to the idle timeout for instance. The agent > should extend the > lifetime at the given time. > There're two things I can see here: 1) Correct me if I'm wrong, current middlebox's rule is indenpendent of the session derived from it. When a rule is timed out, the session derived from it can still exist. If the session is timed out later, how can the middlebox send a notification to the agent? Again, my assumption here is that we don't want to keep rules around for the same duration while the derived sessions exist. 2) Even though if somehow the middlebox can send a notification to the agent when a session is gone, it might be too late for the agent to send a new PER to the middlebox since the the very session might be alive again at any time and its packets will be dropped before the new PER is in effect. The key to this issue is that in order for application-enabled traffic (e.g., SIP enabled media) to traverse middlebox, not only does a middlebox rule need to have information for openning pinholes, but also it needs to instruct a middlebox how to handle all the derived sessions as far as timeout is concerned. I can see for those middleboxes that don't use sessions, they have to keep rules all the time during a call. But for those middleboxes that do use sessions, making rules independent of sessions does impose problems such as decreased security and increased resource usage. Again, if this has been discussed in the group before and there's a consensus regarding this issue, I will not use this bandwidth to discuss this further. Thanks! Wanqun > > [...] > > Regards > Martin > > > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Oct 12 02:30:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09471 for ; Sun, 12 Oct 2003 02:30:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Zk6-0002rW-Ca for midcom-archive@odin.ietf.org; Sun, 12 Oct 2003 02:30:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9C6UEdo011000 for midcom-archive@odin.ietf.org; Sun, 12 Oct 2003 02:30:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Zjv-0002qA-Ez; Sun, 12 Oct 2003 02:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Ziz-0002o4-Uk for midcom@optimus.ietf.org; Sun, 12 Oct 2003 02:29:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09444 for ; Sun, 12 Oct 2003 02:28:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Ziv-0004ck-00 for midcom@ietf.org; Sun, 12 Oct 2003 02:29:01 -0400 Received: from web40410.mail.yahoo.com ([66.218.78.107]) by ietf-mx with smtp (Exim 4.12) id 1A8Ziv-0004ch-00 for midcom@ietf.org; Sun, 12 Oct 2003 02:29:01 -0400 Message-ID: <20031012062832.67213.qmail@web40410.mail.yahoo.com> Received: from [67.164.29.130] by web40410.mail.yahoo.com via HTTP; Sat, 11 Oct 2003 23:28:32 PDT Date: Sat, 11 Oct 2003 23:28:32 -0700 (PDT) From: Pyda Srisuresh Subject: PRRs (was Re: Fwd: [midcom] Changes in semantics (Version 05)) To: Martin Stiemerling Cc: midcom@ietf.org In-Reply-To: <2940337.1065628634@[10.1.1.109]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Martin, My apologies for not being able to respond sooner. Please see my comments below. I am breaking up the response into 3 parts so as to close individual parts seperately. Hope that is OK by you. In this e-mail I am going to simply focus on PRR. regards, suresh --- Martin Stiemerling wrote: > Hi Suresh, > > thanks for checking the document again. More comments inline and I hope on > more comments from other working group members. > > Martin > > --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh > wrote: > > | Hi, > | > | I briefly read through the draft this weekend. I still do not believe, the > | semantics is clear. The abstractions are not adequate to eliminate > | ALGs from a middlebox. > | > | 1. Terminology - I do not believe, you should proliferate of semantics > | for "NAT binding". This sounds like, it will be whatever you want it to > | be in sessing up a session. > > The intention was not to proliferate, but more an approach to bring more > light to issue of NAT binding. Do you think that it confuses more than it > does help? Yes. It is confusing to redefine the term. It would be better to use the term as originally defined and intended. > > | > | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP addresses (in > | the case of twice-NAT) and/or several ports on an address. Depending upon > | what the agent lists in the request parameters, this can be reservation > | of an address bind, or reservation of a bunch of ports (from a NAPT map > | entry, presumably) or reservation of an address each from two map > | entries. The middlebox returned rule identifier can represent any of this > | (Bind handle or single map reservation or two address map reservations). > | This is simply a lot of stuff in a single transaction. Very difficult and > | confusing for a middlebox to do this. > > Yes, that may look confusing, but pushing the task to the MIDCOM agent is > more even more confusing to him. I wasnt suggesting pushing anything to the Midcom agent, much less make it confusing. All I am saying is there should be transparency between Midcom requests and middlebox resources. When there is transparecy, there will be little consfusion on the part of the agent or the middlebox. Here is something that might work for the agents as well as the middleboxes. Do let me know what you think. Assume, the agent knows the middlebox IP interface(for which the midcom requests shoudl be applied). Let us say the purpose of PRR is restricted to reserve one of the following: a) Reserve translation address & port for SrcEndPOint on an inbound session b) Reserve translation address & port for DstEndPoint on an inbound session c) Reserve translation address & port for SrcEndpOint on an outbound session d) Reserve translation address & port for DstEndpoint on an outbound session e) (a) & (b) -- Twice NAT sessions f) (c) & (d) -- Twice NAT sessions g) (a) | (d) -- Bidirectional sessions h) (b) | (c) -- Bidirectional sessions i) Reserve translation address & portpair (for matching oddity) for SrcEndPOint on an inbound session j) Reserve translation address & portpair (for matching oddity) for DstEndPoint on an inbound session k) Reserve translation address & portpair (for matching oddity) for SrcEndpOint on an outbound session l) Reserve translation address & portpair (for matching oddity) for DstEndpoint on an outbound session For these, the response will consist of a maximum of two binds. As you know, Bind is essentially a reserve entity. A Bind is not enforced unless there is a live session that uses it. The reponse in the case of (a), (b), (c) or (d), can be a single address bind or port Bind. In the case of (e) and (f), the response is two BINDs. In the case of (g) or (h), the response can be a single BIND, but is set to be bi-directional. In the case of (i), (j), (k) or (l), the response can be two port binds or a single address bind. In all cases, the response will indicate the BIND type(address bind or port bind), BindId and the translation end points. In the case NAT is unable to assign a BIND, the response will indicate the same. In such a case, the agent will be advised to use PER directly without the use of PRR. Essentially, I eliminated the ability to reserve a bunch of ports (> 2). That would remove the need for address map entry partial/full ownership connotation. Hope this will work for you. > > | > | Specifying the internal IP address helps in reserving a pool of ports in > | a NAPT case or an address BIND in the case of basic NAT. But, that alone > | is not adequate for twice-NAT. The transaction needs to include the > | destinaion end-point. otherwise, PRR is not usable for Twice-NAT for the > | same reason the PRR was not usable for traditional NAT in the previous > | rev of the draft. The middlebox cannot pick up an arbitrary address from > | one of the map entries for twice-nat, not with just A0 in the request > | list. > > The idea behind PRR is that the agent does not know the destination > address. If this is twice-NAT and the agent doesnt know the destination address, how do you propose to reserve an address? > > This is the case for example in SIP call set-up. Only the data receiver in > the private address realm is known on the first INVITE, if the caller is in > this private address realm. This is a very tricky thing and PRR does > provide a good mean to cope with that, even when it looks somehow strange. > I could offer a powerpoint presentation from one of the IETF meetings > explaining the need for PRR if you like. > I donot know what you are refering to (i.e, where the caller, callee, midcom agent and middlebox arelocated relative to each other). You might want to refer the SIP example in the framework RFC-3303 (section 7.2, 7.3). In this example, the midcom agent on SIP-Proxy creates/queries binds to permit the application through. Basically, unless the parameters in the request are clear, the middlebox cannot do magic. If this is tricky for the agent, likely it is undoable for the middlebox. > | > | As I said earlier, I suggest, the PRR be simplified split up into doing > | BIND reservations and MAP reservations independently. Please seem my earlier comment. I think, we can get rid of map reservations and establish transparency between PRR and Binds. <... stuff deleted> regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Oct 12 03:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10120 for ; Sun, 12 Oct 2003 03:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8aEw-0004PP-Vr for midcom-archive@odin.ietf.org; Sun, 12 Oct 2003 03:02:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9C726TA016940 for midcom-archive@odin.ietf.org; Sun, 12 Oct 2003 03:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8aEs-0004Of-71; Sun, 12 Oct 2003 03:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8aEn-0004OI-Sl for midcom@optimus.ietf.org; Sun, 12 Oct 2003 03:01:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10085 for ; Sun, 12 Oct 2003 03:01:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8aEj-000506-00 for midcom@ietf.org; Sun, 12 Oct 2003 03:01:53 -0400 Received: from web40401.mail.yahoo.com ([66.218.78.98]) by ietf-mx with smtp (Exim 4.12) id 1A8aEi-0004zn-00 for midcom@ietf.org; Sun, 12 Oct 2003 03:01:53 -0400 Message-ID: <20031012070122.91895.qmail@web40401.mail.yahoo.com> Received: from [67.164.29.130] by web40401.mail.yahoo.com via HTTP; Sun, 12 Oct 2003 00:01:22 PDT Date: Sun, 12 Oct 2003 00:01:22 -0700 (PDT) From: Pyda Srisuresh Subject: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) To: Martin Stiemerling Cc: midcom@ietf.org In-Reply-To: <2940337.1065628634@[10.1.1.109]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Martin Stiemerling wrote: <... stuff deleted> > | 3. PER should simply be labelled as session creation request. The text in > | the draft that refers this as BIND in some cases shoudl simply be > | eliminated. PER essentially boils down to setting up NAT sessions/flows > | using pre-established binds or pre-reserved map entries or simply > | creating a new session. When the session is created, the response should > | indicate the BINDs used, if any, and the translation end-points for the > | session. > > You are right in saying that with PER a NAT session is created. But for > instance consider this scenario: > > A PER request with an internal address (A0) and a wildcarded external > sender (A3) (dataflow from outside to inside). The external sender is not > known (One example is SIP early media). For that case you can not start a > NAT session, since the NAT must create a NAT bind. Via this NAT bind > several UDP/RTP flows from several destinations may traverse the middlebox > to A0. If a BIND can be created ahead of time, PRR shoudl be used. Any number of sessions can use that BIND (for the directionality supported by the BIND). The second half of the session is irrelevant to the BIND. However, if the PRR is unsuccessful, PER maybe used by the agent to setup a NAT session (with wildcard match for external source and port) & the PER response will return back the session Id. When the actual session occurs, that session parameters will be used to plug the holes in the NAT session. Middlebox may be instructed to notify the agent when the holes are plugged by the actual session. > > | > | The twice-NAT example doesn't make sense. If the session is between A0 & > | A1 (as would be in the case of twice-NAT) the agent cannot know A3 ahead > | of time. However, that is what the PER request parametere description > | indicates. > > Hmm, I don't see the issue you raise immediately. > Basically, in a twice-NAT scenario, both source and destination end-points are in the same address realm on both end-points. So, A session between A0 and A1 would be translated as a session between A2 & A3. > A3 is the external end point and A1 the inside IP address/port number at > the twice-NAT. The application level session is between A0 and A3, but the > IP/transport 'sessions' are between A0/A1 and A2/A3. Right. So, if the agent is located on A0, the agent only knows A0 and A1. Agent cannot know A3, right? > > Could you give me some more hints? > Basically, what I am saying is that PER request parameters ought to indicate the session parameters as it knows. This is irrespective of whether the agent is inside private domain or outside private domain; whether the agent is resident on one of the end-hosts or on a proxy in-between. > > | 3. The document says in several places that the NAT is one of traditional > | NAT or Twice-NAT. What about bi-directional NAT? I saw this mentioned > | just once in PER description. When you support bi-directional NAT, it is > | important for the PRR and PERs to support sessions initiated from the > | outside, in additiona to sessions initiated from the private realm. The > | request parameters in PRR and PER are not adequate to support this. > > That's not true. For PRR the direction is not relevant, since only a > resource reservation is made at the NAT. Not true. BIND direction determines which sessions are allowed to use the BIND. > In PER there is the flow direction > parameter that indicates the flow direction (inbound, outbound, or > bi-directional). So with this it is possible to allow even sessions > initiated from the outside. <... snipped> regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Oct 12 04:24:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11884 for ; Sun, 12 Oct 2003 04:24:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8bVr-00013l-N5 for midcom-archive@odin.ietf.org; Sun, 12 Oct 2003 04:23:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9C8Ndsk004039 for midcom-archive@odin.ietf.org; Sun, 12 Oct 2003 04:23:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8bVn-00010G-Uj; Sun, 12 Oct 2003 04:23:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8aNs-0005XH-KY for midcom@optimus.ietf.org; Sun, 12 Oct 2003 03:11:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10589 for ; Sun, 12 Oct 2003 03:11:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8aNo-0005Dm-00 for midcom@ietf.org; Sun, 12 Oct 2003 03:11:16 -0400 Received: from web40406.mail.yahoo.com ([66.218.78.103]) by ietf-mx with smtp (Exim 4.12) id 1A8aNn-0005Dj-00 for midcom@ietf.org; Sun, 12 Oct 2003 03:11:15 -0400 Message-ID: <20031012071046.55728.qmail@web40406.mail.yahoo.com> Received: from [67.164.29.130] by web40406.mail.yahoo.com via HTTP; Sun, 12 Oct 2003 00:10:46 PDT Date: Sun, 12 Oct 2003 00:10:46 -0700 (PDT) From: Pyda Srisuresh Subject: Group Ids (part 3 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) To: Martin Stiemerling Cc: midcom@ietf.org In-Reply-To: <2940337.1065628634@[10.1.1.109]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Martin Stiemerling wrote: <... snipped> > | > | 4. I still have an issue with GroupId assignment being mandated on the > | middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 does not madate > | this. > > Right the protocol requirements do not mandate this, but as a lot of other > points this is a design issue. If you are saying the semantics design team opted for this approach, while either approach is acceptable, I understand that. The document should, however, state this explicitly. Otherwise, the reader gets the impression that the semantics document is mandating this on the Midcom protocol designer, as it did with everything else in the document. > So far nobody else has any objection about > this. Neither have i heard objections to not madating this on the middlebox. > > > | > | That's all for now. > > Thanks for the comments. > Martin > > [... cut by Martin ] regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Oct 12 04:24:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11951 for ; Sun, 12 Oct 2003 04:24:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8bWN-0001Ta-IF for midcom-archive@odin.ietf.org; Sun, 12 Oct 2003 04:24:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9C8OB1u005600 for midcom-archive@odin.ietf.org; Sun, 12 Oct 2003 04:24:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8bWL-0001S2-Ty; Sun, 12 Oct 2003 04:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8ajn-0006Cg-L2 for midcom@optimus.ietf.org; Sun, 12 Oct 2003 03:33:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10851 for ; Sun, 12 Oct 2003 03:33:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8ajl-0005Jh-00 for midcom@ietf.org; Sun, 12 Oct 2003 03:33:57 -0400 Received: from web40406.mail.yahoo.com ([66.218.78.103]) by ietf-mx with smtp (Exim 4.12) id 1A8ajk-0005JY-00 for midcom@ietf.org; Sun, 12 Oct 2003 03:33:56 -0400 Message-ID: <20031012073327.57235.qmail@web40406.mail.yahoo.com> Received: from [67.164.29.130] by web40406.mail.yahoo.com via HTTP; Sun, 12 Oct 2003 00:33:27 PDT Date: Sun, 12 Oct 2003 00:33:27 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Need for A3 as a PRR parameter (was Changes in semantics (Version 05)) To: Tom Taylor Cc: Melinda Shore , midcom@ietf.org In-Reply-To: <3F85CB94.8090406@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Tom Taylor wrote: > I wanted to address your point regarding PRR. Please see below. > > Pyda Srisuresh wrote: > > > Hi, > > > > I briefly read through the draft this weekend. I still do not believe, the > > semantics is clear. The abstractions are not adequate to eliminate > > ALGs from a middlebox. > > > ... > > > > 2. PRR is still fuzzy. The PRR reserves a maximum of two IP addresses (in > the > > case of twice-NAT) and/or several ports on an address. Depending upon what > the > > agent lists in the request parameters, this can be reservation of an > address > > bind, or reservation of a bunch of ports (from a NAPT map entry, > presumably) or > > reservation of an address each from two map entries. The middlebox returned > > rule identifier can represent any of this (Bind handle or single map > > reservation or two address map reservations). This is simply a lot of stuff > in > > a single transaction. Very difficult and confusing for a middlebox to do > this. > > > > Specifying the internal IP address helps in reserving a pool of ports in a > NAPT > > case or an address BIND in the case of basic NAT. But, that alone is not > > adequate for twice-NAT. The transaction needs to include the destinaion > > end-point. otherwise, PRR is not usable for Twice-NAT for the same reason > the > > PRR was not usable for traditional NAT in the previous rev of the draft. > The > > middlebox cannot pick up an arbitrary address from one of the map entries > for > > twice-nat, not with just A0 in the request list. > > > > [PTT] The reason PRR was not usable for traditional NAT without specifying A0 > was > because it was possible the NAT already had a mapping for A0 because of an > existing > dynamically-established session, and had to have the information to choose > it. That is not the only or main reason. Without specifying A0, NAT does know which address to assign from several of its map entries. > The > reason we added an optional interface identifier was because the NAT could be > > supporting multiple private interfaces. Yes. > > It is a fact that the application, and thus the agent, will often not know A3 > at the > time of the PRR request. Fine. I dont have a problem with it. If the PRR makes a reservation for xlation parameters for just one of the end-points, say A0, then there is no issue here. The problem is only if the PRR makes reservation for both end-points as would be the case with twice-NAT. In such a case, NAT cannot know to reserve for the second endpoint. > It is thus important to confirm what is or is not > possible > in terms of NAT technology. I assume you consider A3 necessary for the same > reason > as A0: because the NAT is unable to map the same external address to more > than one > internal address in the twice-NAT case, and the host at A3 may already be > involved > in another session operating through this middlebox. If this is true (please > > confirm), it may be that we have to accept a certain percentage of cases > where the > PER will fail because the mapping assigned by the PRR is inconsistent with > existing > configuration. > Mostly, yes, to what you say. NAT goes by the map entries when it has to carry out PRR reservations. If a PRR requires xlation address reservations for both src and dest endpoints, then it must provide the original endpoints for both src and dest. Else, the PRR request for dual reservations will fail. > > As I said earlier, I suggest, the PRR be simplified split up into doing > BIND > > reservations and MAP reservations independently. > > [PTT] I don't believe PRR does more than MAP reservations. As I mentioned in a different e-mail thread to Martin, I believe, PRR can simply be a mechanism to obtain a maximum of two BINDs. I donot believe, there is a need for map reservations in midcom protocol. Correct me, if I am wrong. regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 13 09:37:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04419 for ; Mon, 13 Oct 2003 09:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92sn-00015t-V8 for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 09:37:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DDb9tr004173 for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 09:37:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92sf-00012b-IK; Mon, 13 Oct 2003 09:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92s0-00010q-UZ for midcom@optimus.ietf.org; Mon, 13 Oct 2003 09:36:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04359 for ; Mon, 13 Oct 2003 09:36:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A92rw-0002fK-00 for midcom@ietf.org; Mon, 13 Oct 2003 09:36:16 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A92rv-0002f8-00 for midcom@ietf.org; Mon, 13 Oct 2003 09:36:16 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9DDZflR002686; Mon, 13 Oct 2003 06:35:41 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-46.cisco.com [10.32.241.46]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANB57362; Mon, 13 Oct 2003 06:35:40 -0700 (PDT) Date: Mon, 13 Oct 2003 09:35:37 -0400 Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Martin Stiemerling , midcom@ietf.org To: Pyda Srisuresh From: Melinda Shore In-Reply-To: <20031012070122.91895.qmail@web40401.mail.yahoo.com> Message-Id: <214BF70F-FD82-11D7-B68A-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Suresh: Many thanks for your detailed comments. I am somewhat concerned that we're getting later and later with this document and that the issues you're raising deal with specific NAT/firewall function while we (midcom) are dealing with abstracted (or idealized) NAT/firewall function. This is something we need to be particularly careful about in a document that describes protocol semantics. Much of what you've brought forward is more specifically the goo between the abstract machinery and the low-level device function, and as such I think needs to be treated as implementation issues in many cases. This gets back to the question of whether or not we're doing a configuration protocol, where the device specifics are reflected in the protocol itself. We're not, of course. I'd really like to see us get this wrapped up and shipped off. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 13 12:04:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12734 for ; Mon, 13 Oct 2003 12:04:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95B7-0000k8-BD for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 12:04:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DG4Dao002850 for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 12:04:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95Aw-0000iv-Re; Mon, 13 Oct 2003 12:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95AM-0000iH-8q for midcom@optimus.ietf.org; Mon, 13 Oct 2003 12:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12690 for ; Mon, 13 Oct 2003 12:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95AK-0004kl-00 for midcom@ietf.org; Mon, 13 Oct 2003 12:03:24 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A95AK-0004kZ-00 for midcom@ietf.org; Mon, 13 Oct 2003 12:03:24 -0400 Received: from [172.16.2.10] (unknown [194.209.199.6]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 3321BF5A6; Mon, 13 Oct 2003 18:07:39 +0200 (CEST) Date: Mon, 13 Oct 2003 18:03:23 +0200 From: Martin Stiemerling To: Wanqun Bao Cc: midcom@ietf.org, quittek@ccrle.nec.de Subject: RE: Fwd: [midcom] Changes in semantics (Version 05) Message-ID: <37000000.1066061003@n-stiemerling.office> In-Reply-To: <82CC1E573B94A648B87027C9419E2C05FDAC4E@LOSGATOS.netscreen.com> References: <82CC1E573B94A648B87027C9419E2C05FDAC4E@LOSGATOS.netscreen.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Sorry for the delayed answer, I'm currently on a trip. |> I see the problem your are describing. |> For each audio channel you would setup a policy rule, isn't |> it? If this |> audio channel is dead and the corresponding NAT session is going to |> timeout, the middlebox may remove the NAT session (plus a NAT |> bind) and |> sent a ARE notification to the agent indicating the deletion |> of the policy |> rule. |> But the scenario you are pointing to is when a audio channel |> is dead for |> the idle timeout, but it is from the SIP view still active |> (Hope that is |> the scenario). A solution for this is to set the policy rule |> lifetime in |> the beginning to the idle timeout for instance. The agent |> should extend the |> lifetime at the given time. |> | There're two things I can see here: | 1) Correct me if I'm wrong, current middlebox's rule is indenpendent | of the session derived from it. When a rule is timed out, the session | derived from it can still exist. I see the middlebox's policy rule is tightly related to any resource in the middlebox. So a session derived from a middlebox rule is active in the box as long as the policy rule is enabled. | If the session is timed out later, | how can the middlebox send a notification to the agent? Again, my | assumption here is that we don't want to keep rules around for the | same duration while the derived sessions exist. The assumption in the design is that rules are kept as long as the session in the middlebox must work. That again results in a tight couple between policy rules and middlebox resources such as binds and sessions. | 2) Even though if somehow the middlebox can send a notification to | the agent when a session is gone, it might be too late for the agent | to send a new PER to the middlebox since the the very session might | be alive again at any time and its packets will be dropped before the | new PER is in effect. The agent is in charge of taking care of policy rules. So the agent must track his policy rules and extend the lifetime if necessary. | | The key to this issue is that in order for application-enabled traffic | (e.g., SIP enabled media) to traverse middlebox, not only does a middlebox | rule need to have information for openning pinholes, but also it | needs to instruct a middlebox how to handle all the derived sessions as | far as timeout is concerned. The point is for instance, a session in a NAT may extend the duration of the SIP session (due to the session timeout). But when the SIP session ends the agent should remover all policy rules for this SIP session (and thus remove all sessions as well). If the agent feels to keep the policy rules alive he can keep the policy rules and even extend their lifetimes. In order to archive the tight couple between policy rules and binds/sessions, a modification to the NAT engine could be needed. | | I can see for those middleboxes that don't use sessions, they have | to keep rules all the time during a call. But for those middleboxes | that do use sessions, making rules independent of sessions does | impose problems such as decreased security and increased resource | usage. | | Again, if this has been discussed in the group before and there's a | consensus regarding this issue, I will not use this bandwidth to | discuss this further. Of course your comments are welcome and it is very useful to discuss unclear points. Cheers Martin | | Thanks! | | Wanqun | |> |> [...] |> |> Regards |> Martin |> |> |> Martin Stiemerling |> |> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de |> PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg |> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de |> Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 13 14:22:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18809 for ; Mon, 13 Oct 2003 14:22:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97Ke-00086K-4G for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 14:22:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DIMCu9031118 for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 14:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97KS-00085V-Tv; Mon, 13 Oct 2003 14:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97KM-00085J-E0 for midcom@optimus.ietf.org; Mon, 13 Oct 2003 14:21:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18793 for ; Mon, 13 Oct 2003 14:21:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97KJ-0006Qk-00 for midcom@ietf.org; Mon, 13 Oct 2003 14:21:51 -0400 Received: from web40406.mail.yahoo.com ([66.218.78.103]) by ietf-mx with smtp (Exim 4.12) id 1A97KI-0006Qc-00 for midcom@ietf.org; Mon, 13 Oct 2003 14:21:50 -0400 Message-ID: <20031013182119.91720.qmail@web40406.mail.yahoo.com> Received: from [66.224.113.194] by web40406.mail.yahoo.com via HTTP; Mon, 13 Oct 2003 11:21:19 PDT Date: Mon, 13 Oct 2003 11:21:19 -0700 (PDT) From: Pyda Srisuresh Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) To: Melinda Shore Cc: Martin Stiemerling , midcom@ietf.org In-Reply-To: <214BF70F-FD82-11D7-B68A-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Melinda, I am not raising implementation issues or suggesting that Midcom be a configuration protocol. I donot appreciate my comments being characterized that way repeatedly. The goal of my comments has been to make the transactions transparent and relate to the resources the middleboxes manage. I pointed out areas that are not clear or are not enforceable, and suggested way to fix them. It takes a tremendous amount of time and energy on my part to provide this feedback. I did not have to do this. I am doign this only for the benefit of the draft. I am trying to wrap this up. That was the essence of my last 3 e-mails. FYI. regards, suresh --- Melinda Shore wrote: > Suresh: > > Many thanks for your detailed comments. I am somewhat > concerned that we're getting later and later with this > document and that the issues you're raising deal with > specific NAT/firewall function while we (midcom) are dealing > with abstracted (or idealized) NAT/firewall function. This > is something we need to be particularly careful about in > a document that describes protocol semantics. Much of > what you've brought forward is more specifically the goo > between the abstract machinery and the low-level device > function, and as such I think needs to be treated as > implementation issues in many cases. This gets back to > the question of whether or not we're doing a configuration > protocol, where the device specifics are reflected in > the protocol itself. We're not, of course. > > I'd really like to see us get this wrapped up and shipped > off. > > Melinda > ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 13 14:34:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19355 for ; Mon, 13 Oct 2003 14:34:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97W8-0000TM-AP for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 14:34:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DIY4Sj001816 for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 14:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97W4-0000Ss-Bn; Mon, 13 Oct 2003 14:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97Vj-0000S8-4W for midcom@optimus.ietf.org; Mon, 13 Oct 2003 14:33:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19310 for ; Mon, 13 Oct 2003 14:33:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97Vg-0006Yc-00 for midcom@ietf.org; Mon, 13 Oct 2003 14:33:36 -0400 Received: from [216.52.157.170] (helo=smtp01.go2call.com) by ietf-mx with esmtp (Exim 4.12) id 1A97Vf-0006YH-00 for midcom@ietf.org; Mon, 13 Oct 2003 14:33:35 -0400 Received: from agarg (go2call-90.go2call.com [216.52.157.90]) by smtp01.go2call.com (8.12.8/8.12.8) with SMTP id h9DIX1NT002238 for ; Mon, 13 Oct 2003 13:33:02 -0500 From: "Ajay Garg" To: Subject: RE: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) Date: Mon, 13 Oct 2003 13:32:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20031013182119.91720.qmail@web40406.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please remove me. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Pyda Srisuresh Sent: Monday, October 13, 2003 1:21 PM To: Melinda Shore Cc: Martin Stiemerling; midcom@ietf.org Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) Melinda, I am not raising implementation issues or suggesting that Midcom be a configuration protocol. I donot appreciate my comments being characterized that way repeatedly. The goal of my comments has been to make the transactions transparent and relate to the resources the middleboxes manage. I pointed out areas that are not clear or are not enforceable, and suggested way to fix them. It takes a tremendous amount of time and energy on my part to provide this feedback. I did not have to do this. I am doign this only for the benefit of the draft. I am trying to wrap this up. That was the essence of my last 3 e-mails. FYI. regards, suresh --- Melinda Shore wrote: > Suresh: > > Many thanks for your detailed comments. I am somewhat > concerned that we're getting later and later with this > document and that the issues you're raising deal with > specific NAT/firewall function while we (midcom) are dealing > with abstracted (or idealized) NAT/firewall function. This > is something we need to be particularly careful about in > a document that describes protocol semantics. Much of > what you've brought forward is more specifically the goo > between the abstract machinery and the low-level device > function, and as such I think needs to be treated as > implementation issues in many cases. This gets back to > the question of whether or not we're doing a configuration > protocol, where the device specifics are reflected in > the protocol itself. We're not, of course. > > I'd really like to see us get this wrapped up and shipped > off. > > Melinda > ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 13 16:03:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24546 for ; Mon, 13 Oct 2003 16:03:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98uI-00067T-91 for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 16:03:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DK36oB023515 for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 16:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98uD-00066c-GN; Mon, 13 Oct 2003 16:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98tP-000632-1f for midcom@optimus.ietf.org; Mon, 13 Oct 2003 16:02:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24504 for ; Mon, 13 Oct 2003 16:02:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A98tN-0007g3-00 for midcom@ietf.org; Mon, 13 Oct 2003 16:02:09 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A98tM-0007fg-00 for midcom@ietf.org; Mon, 13 Oct 2003 16:02:09 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Oct 2003 13:10:54 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9DK1aeH002190; Mon, 13 Oct 2003 13:01:36 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-46.cisco.com [10.32.241.46]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANB99610; Mon, 13 Oct 2003 13:01:34 -0700 (PDT) Date: Mon, 13 Oct 2003 16:01:32 -0400 Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Martin Stiemerling , midcom@ietf.org To: Pyda Srisuresh From: Melinda Shore In-Reply-To: <20031013182119.91720.qmail@web40406.mail.yahoo.com> Message-Id: <0AD70FE7-FDB8-11D7-B68A-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, October 13, 2003, at 02:21 PM, Pyda Srisuresh wrote: > I am not raising implementation issues or suggesting that Midcom be a > configuration protocol. I realize that that's not your intent but I do think it's a consequence. So rather than describing what you're talking about as "configuration" let me amend that to say that I think you're closer to the metal than we intend to be. You describe the difference quite well towards the bottom of your message http://www.ietf.org/mail-archive/working-groups/midcom/current/ msg03332.html . I would feel far more comfortable with this discussion if there were more participants arguing for a more middlebox- centric view of the protocol. Absent that I'd really like us to move on. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 13 20:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07590 for ; Mon, 13 Oct 2003 20:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9DQw-0002ER-PY for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 20:53:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E0r6vl008555 for midcom-archive@odin.ietf.org; Mon, 13 Oct 2003 20:53:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9DQr-0002Db-4G; Mon, 13 Oct 2003 20:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9DQn-0002CX-VR for midcom@optimus.ietf.org; Mon, 13 Oct 2003 20:52:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07572 for ; Mon, 13 Oct 2003 20:52:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9DQl-0003rB-00 for midcom@ietf.org; Mon, 13 Oct 2003 20:52:55 -0400 Received: from web40401.mail.yahoo.com ([66.218.78.98]) by ietf-mx with smtp (Exim 4.12) id 1A9DQk-0003r0-00 for midcom@ietf.org; Mon, 13 Oct 2003 20:52:54 -0400 Message-ID: <20031014005225.12015.qmail@web40401.mail.yahoo.com> Received: from [66.224.113.194] by web40401.mail.yahoo.com via HTTP; Mon, 13 Oct 2003 17:52:25 PDT Date: Mon, 13 Oct 2003 17:52:25 -0700 (PDT) From: Pyda Srisuresh Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) To: Melinda Shore Cc: Martin Stiemerling , midcom@ietf.org In-Reply-To: <0AD70FE7-FDB8-11D7-B68A-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Melinda, When the abstraction is high and takes the leave-it-to-vendors-to-do-the-right-thing approach, the resulting protocol can have serious interoperability issues. That is why I believe, it is important for the semantics to state and the middlebox /agent administrators to know what has changed and why, when a command is run. This is what I am working with the authors on over the mailing list. If you view this as middlebox centric approach and is not pertinent to the document, you may certainly make the call to send the doc to the IESG as soon as you wish. regards, suresh --- Melinda Shore wrote: > On Monday, October 13, 2003, at 02:21 PM, Pyda Srisuresh wrote: > > I am not raising implementation issues or suggesting that Midcom be a > > configuration protocol. > > I realize that that's not your intent but I do think it's > a consequence. So rather than describing what you're > talking about as "configuration" let me amend that to say > that I think you're closer to the metal than we intend to > be. You describe the difference quite well towards the > bottom of your message > http://www.ietf.org/mail-archive/working-groups/midcom/current/ > msg03332.html . > > I would feel far more comfortable with this discussion if > there were more participants arguing for a more middlebox- > centric view of the protocol. Absent that I'd really like us > to move on. > > Melinda > ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Oct 14 12:34:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18347 for ; Tue, 14 Oct 2003 12:34:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S7e-00010f-44 for midcom-archive@odin.ietf.org; Tue, 14 Oct 2003 12:34:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EGYAIX003857 for midcom-archive@odin.ietf.org; Tue, 14 Oct 2003 12:34:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S7U-0000zS-L3; Tue, 14 Oct 2003 12:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S75-0000xc-S3 for midcom@optimus.ietf.org; Tue, 14 Oct 2003 12:33:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18296 for ; Tue, 14 Oct 2003 12:33:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9S73-00054k-00 for midcom@ietf.org; Tue, 14 Oct 2003 12:33:33 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A9S73-00054V-00 for midcom@ietf.org; Tue, 14 Oct 2003 12:33:33 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Oct 2003 09:42:31 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9EGX0vA018378; Tue, 14 Oct 2003 09:33:00 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-46.cisco.com [10.32.241.46]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANC81988; Tue, 14 Oct 2003 09:32:58 -0700 (PDT) Date: Tue, 14 Oct 2003 12:32:57 -0400 Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Martin Stiemerling , midcom@ietf.org To: Pyda Srisuresh From: Melinda Shore In-Reply-To: <20031014005225.12015.qmail@web40401.mail.yahoo.com> Message-Id: <1187DA61-FE64-11D7-B68A-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, October 13, 2003, at 08:52 PM, Pyda Srisuresh wrote: > When the abstraction is high and takes the > leave-it-to-vendors-to-do-the-right-thing approach, the resulting > protocol can > have serious interoperability issues. Overspecification has other drawbacks, as well (for example the use of interface identifiers in requests has implications for how routing information is passed around, which is an enormous problem). I've been thinking about how to proceed. On the one hand the concerns you've been raising really should have been brought up before or during WG last call on the document, and they aren't specifically responsive to the changes that were made as a result of last call comments. However, I don't want to allow process to trump document quality (to a point - obviously the discussion has to be bounded). Given that, you were right to raise issues that you identified. On the other hand I'm not seeing feedback from the other working group participants and it's my sense that there's either not a lot of agreement or not a lot of interest. So, I would request that the document editors close out the current discussions and if there are no changes to the current draft that result from them to let me know and I'll send the document to the IESG for review and publication. If there are substantive changes to the document based on the current discussions we will need another revision of the draft and another WG last call. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Oct 14 15:51:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27205 for ; Tue, 14 Oct 2003 15:51:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9VCJ-0005I5-Mj for midcom-archive@odin.ietf.org; Tue, 14 Oct 2003 15:51:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EJpBBr020333 for midcom-archive@odin.ietf.org; Tue, 14 Oct 2003 15:51:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9VCB-0005Fb-8J; Tue, 14 Oct 2003 15:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9VC5-0005EX-J5 for midcom@optimus.ietf.org; Tue, 14 Oct 2003 15:50:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27159 for ; Tue, 14 Oct 2003 15:50:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9VC4-00077l-00 for midcom@ietf.org; Tue, 14 Oct 2003 15:50:56 -0400 Received: from web40408.mail.yahoo.com ([66.218.78.105]) by ietf-mx with smtp (Exim 4.12) id 1A9VC3-00077a-00 for midcom@ietf.org; Tue, 14 Oct 2003 15:50:55 -0400 Message-ID: <20031014195024.34221.qmail@web40408.mail.yahoo.com> Received: from [66.224.113.194] by web40408.mail.yahoo.com via HTTP; Tue, 14 Oct 2003 12:50:24 PDT Date: Tue, 14 Oct 2003 12:50:24 -0700 (PDT) From: Pyda Srisuresh Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) To: Melinda Shore Cc: Martin Stiemerling , midcom@ietf.org In-Reply-To: <1187DA61-FE64-11D7-B68A-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Melinda Shore wrote: > On Monday, October 13, 2003, at 08:52 PM, Pyda Srisuresh wrote: > > When the abstraction is high and takes the > > leave-it-to-vendors-to-do-the-right-thing approach, the resulting > > protocol can > > have serious interoperability issues. > > Overspecification has other drawbacks, as well (for example > the use of interface identifiers in requests has implications > for how routing information is passed around, which is an > enormous problem). [Suresh] Well, I dont buy this. I dont believe including the interface in a request is ovespecifying or has implications on routing. Interface specification was necessary because NAT/FW are configured per-interface, and is independent of how the routing occurs in the box. > > I've been thinking about how to proceed. On the one hand > the concerns you've been raising really should have been > brought up before or during WG last call on the document, and > they aren't specifically responsive to the changes that were > made as a result of last call comments. [Suresh] I agree, I have not been part of the WG discussions until after the first WG last call. I simply could not spare the time before. Sorry about that. > However, I don't want > to allow process to trump document quality (to a point - obviously > the discussion has to be bounded). Given that, you were right to > raise issues that you identified. On the other hand I'm not > seeing feedback from the other working group participants and > it's my sense that there's either not a lot of agreement or > not a lot of interest. So, I would request that the document > editors close out the current discussions and if there are > no changes to the current draft that result from them to > let me know and I'll send the document to the IESG for review > and publication. If there are substantive changes to the > document based on the current discussions we will need another > revision of the draft and another WG last call. [suresh] I understand what you say. > > Melinda > regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Oct 14 20:33:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11525 for ; Tue, 14 Oct 2003 20:33:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ZbA-00079q-JD for midcom-archive@odin.ietf.org; Tue, 14 Oct 2003 20:33:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F0X8ng027513 for midcom-archive@odin.ietf.org; Tue, 14 Oct 2003 20:33:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Zb3-00079D-AW; Tue, 14 Oct 2003 20:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Zam-00078s-9b for midcom@optimus.ietf.org; Tue, 14 Oct 2003 20:32:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11489 for ; Tue, 14 Oct 2003 20:32:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Zaj-0004Dl-00 for midcom@ietf.org; Tue, 14 Oct 2003 20:32:42 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Zaj-0004Dd-00 for midcom@ietf.org; Tue, 14 Oct 2003 20:32:41 -0400 Received: from BPenfield [216.41.24.10] by acmepacket.com (SMTPD32-8.00) id A5292B1002E; Tue, 14 Oct 2003 20:30:33 -0400 Message-ID: <000b01c392b3$bc6bf9a0$2300000a@BPenfield> From: "Bob Penfield" To: "Pyda Srisuresh" , "Melinda Shore" Cc: "Martin Stiemerling" , References: <20031014195024.34221.qmail@web40408.mail.yahoo.com> Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) Date: Tue, 14 Oct 2003 20:31:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Way back during the requirements phase this issue of middlebox interfaces and topology came up, and I believe it was Scott Brim's draft (one of the 3 drafts on the topic) which suggested that the application (a.k.a. midcom agent) could pass an IP address that it knew was in the network the desired interface was connected to. For the SIP example in the framework document, this would be the next-hop SIP server that the signaling was being sent to. signaling +----+ +-----------+ +----+ +-------+ S1 +--+-----------+---+ S2 +------+ | +----+ | | +----+ | +-----+----+ | middlebox | +----+-----+ | internal | A0 A1 | | A2 A3 | external | | endpoint +==========+===========+==========+ endpoint | +----------+ media +-----------+ +----------+ The midcom agent (S1) knows A0, but does not know A3 until the external endpoint responds to the signaling request. What it does know is the next-hop signaling server (S2) which the midcom-agent believes is in the network that A2 is connected to. If the agent could pass this 'next-hop' address (S2), the middlebox can figure out which interface on which to reserve A2. This way, the midcom-agent does not need to know the middlebox interfaces or have any explicit knowledge of the topology. cheers, (-:bob ----- Original Message ----- From: "Pyda Srisuresh" > > --- Melinda Shore wrote: > > On Monday, October 13, 2003, at 08:52 PM, Pyda Srisuresh wrote: > > > When the abstraction is high and takes the > > > leave-it-to-vendors-to-do-the-right-thing approach, the resulting > > > protocol can > > > have serious interoperability issues. > > > > Overspecification has other drawbacks, as well (for example > > the use of interface identifiers in requests has implications > > for how routing information is passed around, which is an > > enormous problem). > > [Suresh] Well, I dont buy this. I dont believe including the interface in a > request is ovespecifying or has implications on routing. Interface > specification was necessary because NAT/FW are configured per-interface, and is > independent of how the routing occurs in the box. > > > > > I've been thinking about how to proceed. On the one hand > > the concerns you've been raising really should have been > > brought up before or during WG last call on the document, and > > they aren't specifically responsive to the changes that were > > made as a result of last call comments. > > [Suresh] I agree, I have not been part of the WG discussions until after the > first WG last call. I simply could not spare the time before. Sorry about that. > > > However, I don't want > > to allow process to trump document quality (to a point - obviously > > the discussion has to be bounded). Given that, you were right to > > raise issues that you identified. On the other hand I'm not > > seeing feedback from the other working group participants and > > it's my sense that there's either not a lot of agreement or > > not a lot of interest. So, I would request that the document > > editors close out the current discussions and if there are > > no changes to the current draft that result from them to > > let me know and I'll send the document to the IESG for review > > and publication. If there are substantive changes to the > > document based on the current discussions we will need another > > revision of the draft and another WG last call. > > [suresh] I understand what you say. > > > > > Melinda > > > > regards, > suresh > > ===== > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 15 08:47:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27899 for ; Wed, 15 Oct 2003 08:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9l3T-0003jc-UT for midcom-archive@odin.ietf.org; Wed, 15 Oct 2003 08:47:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FCl7lu014352 for midcom-archive@odin.ietf.org; Wed, 15 Oct 2003 08:47:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9l3O-0003iP-H7; Wed, 15 Oct 2003 08:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9l2g-0003gK-Gn for midcom@optimus.ietf.org; Wed, 15 Oct 2003 08:46:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27704; Wed, 15 Oct 2003 08:46:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9l2e-0003zX-00; Wed, 15 Oct 2003 08:46:16 -0400 Received: from protactinium.btinternet.com ([194.73.73.176]) by ietf-mx with esmtp (Exim 4.12) id 1A9l2d-0003zT-00; Wed, 15 Oct 2003 08:46:15 -0400 Received: from host213-122-132-61.in-addr.btopenworld.com ([213.122.132.61] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #23) id 1A9l2J-0003OP-00; Wed, 15 Oct 2003 13:45:56 +0100 Message-ID: <003301c3931a$781e72c0$0200000a@tkw> From: "Pete Cordell" To: "Peterson, Jon" , "Mmusic" Cc: , "Jonathan Rosenberg" References: Date: Wed, 15 Oct 2003 13:47:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] Re: [MMUSIC] Status of TURN Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Jon, I'm very surprised to see that TURN is being encouraged to be put forward as an individual submission. We believe that TURN has major security flaws, is incomplete, and there are better ways of achieving Symmetric NAT traversal. Suggesting it should become an RFC without debate and full consideration would be wrong. If you remember, TURN was just one of the candidates put forward as a pre-Midcom solution that at that time was put aside in favour of developing a consensus protocol. Despite our commitment, consensus wasn't reached, mainly due to the amount of effort that was being put into SIP (RFC3261) by other important stake holders. We feel that to arbitrarily promote TURN at this time is short cutting the consensus making process. Surely, if there is sufficient interest in a standard of this nature, the correct way forward is to assign it as a work item in a suitable group and re-start the consensus process. If so, we remain willing to help with time, resource and considerable technical know-how. Several significant developments have meant the world of Symmetric NAT traversal has advanced considerably since the pre-Midcom days. Regards, Pete. ============================================= Pete Cordell Ridgeway ============================================= ----- Original Message ----- From: "Peterson, Jon" To: "'Joel Tran'" ; "Jonathan Rosenberg" ; "Mmusic" Sent: 09 October 2003 17:08 Subject: RE: [MMUSIC] Status of TURN > > The Transport Area Directors understand that this document will proceed as > an individual submission, outside the context of any of the working groups > in the Transport Area. It is clearly of interest to a number of these > working groups. > > I gather that at least one more revision needs to be undertaken before this > document will be considered for publication as an RFC, but we're very > interested to see it go forward. > > Jon Peterson > NeuStar, Inc. > (co-AD for Transport) > > > -----Original Message----- > > From: Joel Tran [mailto:joel_tran@hotmail.com] > > Sent: Tuesday, October 07, 2003 11:08 AM > > To: Jonathan Rosenberg; Mmusic > > Subject: [MMUSIC] Status of TURN > > > > > > Hi Jonathan, > > > > I would like to ask you two little questions concerning TURN. > > > > First, I would like to know what is the exact status of TURN? > > Will it be > > adopted as a Workgroup item of MMUSIC since TURN is refeered > > in various > > documents? > > > > Second, I would like to ask you if there is a reason why the > > lastest version > > of the draft is not on the IETF web and only available throught > > http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? > > > > Thanks, > > ...J > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 15 14:56:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15751 for ; Wed, 15 Oct 2003 14:56:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9qod-0002Jb-2i for midcom-archive@odin.ietf.org; Wed, 15 Oct 2003 14:56:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FIuBHg008895 for midcom-archive@odin.ietf.org; Wed, 15 Oct 2003 14:56:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9qoT-0002Ip-Ff; Wed, 15 Oct 2003 14:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9qnf-0002GC-An for midcom@optimus.ietf.org; Wed, 15 Oct 2003 14:55:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15719 for ; Wed, 15 Oct 2003 14:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9qnc-0001hx-00 for midcom@ietf.org; Wed, 15 Oct 2003 14:55:08 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A9qnb-0001hu-00 for midcom@ietf.org; Wed, 15 Oct 2003 14:55:07 -0400 Received: from ccrle.nec.de (pD955DE2C.dip.t-dialin.net [217.85.222.44]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 901F8F5A6; Wed, 15 Oct 2003 20:59:17 +0200 (CEST) Date: Wed, 15 Oct 2003 20:49:51 +0200 Subject: Re: PRRs (was Re: Fwd: [midcom] Changes in semantics (Version 05)) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: midcom@ietf.org To: Pyda Srisuresh From: Martin Stiemerling In-Reply-To: <20031012062832.67213.qmail@web40410.mail.yahoo.com> Message-Id: <5BEC48E6-FF40-11D7-8B7C-0003936FD19E@ccrle.nec.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Suresh, Am Sonntag, 12.10.03, um 08:28 Uhr (Europe/Berlin) schrieb Pyda Srisuresh: > Hi Martin, > > My apologies for not being able to respond sooner. Please see my > comments Sorry for the delayed answer, I have been on a trip. I'll answer to all the three parts. Regards Martin > below. I am breaking up the response into 3 parts so as to close > individual > parts seperately. Hope that is OK by you. In this e-mail I am going to > simply > focus on PRR. > > regards, > suresh > > --- Martin Stiemerling wrote: >> Hi Suresh, >> >> thanks for checking the document again. More comments inline and I >> hope on >> more comments from other working group members. >> >> Martin >> >> --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh >> wrote: >> >> | Hi, >> | >> | I briefly read through the draft this weekend. I still do not >> believe, the >> | semantics is clear. The abstractions are not adequate to eliminate >> | ALGs from a middlebox. >> | >> | 1. Terminology - I do not believe, you should proliferate of >> semantics >> | for "NAT binding". This sounds like, it will be whatever you want >> it to >> | be in sessing up a session. >> >> The intention was not to proliferate, but more an approach to bring >> more >> light to issue of NAT binding. Do you think that it confuses more >> than it >> does help? > > Yes. It is confusing to redefine the term. It would be better to use > the term > as originally defined and intended. Ok, I see the point, but then we are returning to the starting point: No clear defintion of how NAT binding is used in the semantics document. > >> >> | >> | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP >> addresses (in >> | the case of twice-NAT) and/or several ports on an address. >> Depending upon >> | what the agent lists in the request parameters, this can be >> reservation >> | of an address bind, or reservation of a bunch of ports (from a NAPT >> map >> | entry, presumably) or reservation of an address each from two map >> | entries. The middlebox returned rule identifier can represent any >> of this >> | (Bind handle or single map reservation or two address map >> reservations). >> | This is simply a lot of stuff in a single transaction. Very >> difficult and >> | confusing for a middlebox to do this. >> >> Yes, that may look confusing, but pushing the task to the MIDCOM >> agent is >> more even more confusing to him. > > I wasnt suggesting pushing anything to the Midcom agent, much less > make it > confusing. All I am saying is there should be transparency between > Midcom > requests and middlebox resources. When there is transparecy, there > will be > little consfusion on the part of the agent or the middlebox. > > Here is something that might work for the agents as well as the > middleboxes. Do > let me know what you think. > > Assume, the agent knows the middlebox IP interface(for which the midcom > requests shoudl be applied). Let us say the purpose of PRR is > restricted to > reserve one of the following: > > a) Reserve translation address & port for SrcEndPOint on an > inbound session > b) Reserve translation address & port for DstEndPoint on an > inbound session > c) Reserve translation address & port for SrcEndpOint on an > outbound > session > d) Reserve translation address & port for DstEndpoint on an > outbound > session > e) (a) & (b) -- Twice NAT sessions > f) (c) & (d) -- Twice NAT sessions > g) (a) | (d) -- Bidirectional sessions > h) (b) | (c) -- Bidirectional sessions > i) Reserve translation address & portpair (for matching oddity) for > SrcEndPOint on an inbound session > j) Reserve translation address & portpair (for matching oddity) for > DstEndPoint on an inbound session > k) Reserve translation address & portpair (for matching oddity) for > SrcEndpOint on an outbound session > l) Reserve translation address & portpair (for matching oddity) for > DstEndpoint on an outbound session > It is quite late for me, but as far as I can see we agree on this above. > For these, the response will consist of a maximum of two binds. As you > know, > Bind is essentially a reserve entity. A Bind is not enforced unless > there is a > live session that uses it. The reponse in the case of (a), (b), (c) or > (d), can > be a single address bind or port Bind. In the case of (e) and (f), the > response > is two BINDs. In the case of (g) or (h), the response can be a single > BIND, but > is set to be bi-directional. In the case of (i), (j), (k) or (l), the > response > can be two port binds or a single address bind. In all cases, the > response will > indicate the BIND type(address bind or port bind), BindId and the > translation This example is quite fine, but since we are dealing with middleboxes (that includes any type of packet filters with any type of filter engine cababilites), returning a one-to-one mapping may not be possible. The goal of the semantics is to give a simple handle to the agent for acting with the middlebox. Consider a NAT with a firewall engine, first of all if you give a one-to-one handle to all resources you need to know the location of the firewall engine (side of the NAT). Second a single NAT bind may be sufficient for the NAt, but it may involve several firewall rules. For instance a single SIP call may involve up to four different firewall rules (one UDP stream in each direction, plus perhaps one RTCP in each direction). With the approach that the semantics take you have as an agent only a single handle to deal with NAT binding and firewall rules. > end points. In the case NAT is unable to assign a BIND, the response > will > indicate the same. In such a case, the agent will be advised to use PER > directly without the use of PRR. > > Essentially, I eliminated the ability to reserve a bunch of ports (> > 2). That Reserving a bunch of ports is required by the MIDCOM protocol requirements. > would remove the need for address map entry partial/full ownership > connotation. > > > Hope this will work for you. > >> >> | >> | Specifying the internal IP address helps in reserving a pool of >> ports in >> | a NAPT case or an address BIND in the case of basic NAT. But, that >> alone >> | is not adequate for twice-NAT. The transaction needs to include the >> | destinaion end-point. otherwise, PRR is not usable for Twice-NAT >> for the >> | same reason the PRR was not usable for traditional NAT in the >> previous >> | rev of the draft. The middlebox cannot pick up an arbitrary address >> from >> | one of the map entries for twice-nat, not with just A0 in the >> request >> | list. >> >> The idea behind PRR is that the agent does not know the destination >> address. > > If this is twice-NAT and the agent doesnt know the destination > address, how do > you propose to reserve an address? > >> >> This is the case for example in SIP call set-up. Only the data >> receiver in >> the private address realm is known on the first INVITE, if the caller >> is in >> this private address realm. This is a very tricky thing and PRR does >> provide a good mean to cope with that, even when it looks somehow >> strange. >> I could offer a powerpoint presentation from one of the IETF meetings >> explaining the need for PRR if you like. >> > I donot know what you are refering to (i.e, where the caller, callee, > midcom > agent and middlebox arelocated relative to each other). You might want > to refer > the SIP example in the framework RFC-3303 (section 7.2, 7.3). In this > example, > the midcom agent on SIP-Proxy creates/queries binds to permit the > application > through. > > Basically, unless the parameters in the request are clear, the > middlebox cannot > do magic. If this is tricky for the agent, likely it is undoable for > the > middlebox. > >> | >> | As I said earlier, I suggest, the PRR be simplified split up into >> doing >> | BIND reservations and MAP reservations independently. > > Please seem my earlier comment. I think, we can get rid of map > reservations and > establish transparency between PRR and Binds. > > <... stuff deleted> > > regards, > suresh > > > ===== > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 15 15:10:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16405 for ; Wed, 15 Oct 2003 15:10:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9r23-00034o-Pk for midcom-archive@odin.ietf.org; Wed, 15 Oct 2003 15:10:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FJA3kB011774 for midcom-archive@odin.ietf.org; Wed, 15 Oct 2003 15:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9r22-00033U-Dj; Wed, 15 Oct 2003 15:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9r1j-00032e-Ny for midcom@optimus.ietf.org; Wed, 15 Oct 2003 15:09:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16337 for ; Wed, 15 Oct 2003 15:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9r1g-0001pT-00 for midcom@ietf.org; Wed, 15 Oct 2003 15:09:40 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A9r1f-0001pQ-00 for midcom@ietf.org; Wed, 15 Oct 2003 15:09:39 -0400 Received: from ccrle.nec.de (pD955D4F3.dip.t-dialin.net [217.85.212.243]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 2293EF5A6; Wed, 15 Oct 2003 21:13:57 +0200 (CEST) Date: Wed, 15 Oct 2003 21:04:45 +0200 Subject: Re: Group Ids (part 3 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: midcom@ietf.org To: Pyda Srisuresh From: Martin Stiemerling In-Reply-To: <20031012071046.55728.qmail@web40406.mail.yahoo.com> Message-Id: <7102D345-FF42-11D7-8B7C-0003936FD19E@ccrle.nec.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit here comes number 3! Am Sonntag, 12.10.03, um 09:10 Uhr (Europe/Berlin) schrieb Pyda Srisuresh: > > --- Martin Stiemerling wrote: > <... snipped> >> | >> | 4. I still have an issue with GroupId assignment being mandated on >> the >> | middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 does not >> madate >> | this. >> >> Right the protocol requirements do not mandate this, but as a lot of >> other >> points this is a design issue. > > If you are saying the semantics design team opted for this approach, > while > either approach is acceptable, I understand that. The document should, > however, > state this explicitly. Otherwise, the reader gets the impression that > the > semantics document is mandating this on the Midcom protocol designer, > as it did > with everything else in the document. Yes, the design team has chosen the approach. Unfortunately, I do not see the opportunity to justify every design choice within the document. Every protocol description has some implicit design choices that are not explicitly stated within the specific document. Martin > >> So far nobody else has any objection >> about >> this. > > Neither have i heard objections to not madating this on the middlebox. > >> >> >> | >> | That's all for now. >> >> Thanks for the comments. >> Martin >> >> [... cut by Martin ] > > regards, > suresh > > > ===== > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 15 15:56:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16406 for ; Wed, 15 Oct 2003 15:10:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9r23-00034p-QB for midcom-archive@odin.ietf.org; Wed, 15 Oct 2003 15:10:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FJA3cs011776 for midcom-archive@odin.ietf.org; Wed, 15 Oct 2003 15:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9r21-00033M-GA; Wed, 15 Oct 2003 15:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9r1h-00032Z-Ed for midcom@optimus.ietf.org; Wed, 15 Oct 2003 15:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16330 for ; Wed, 15 Oct 2003 15:09:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9r1e-0001pM-00 for midcom@ietf.org; Wed, 15 Oct 2003 15:09:38 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A9r1d-0001pJ-00 for midcom@ietf.org; Wed, 15 Oct 2003 15:09:37 -0400 Received: from ccrle.nec.de (pD955D4F3.dip.t-dialin.net [217.85.212.243]) by ftp.ccrle.nec.de (Postfix) with ESMTP id AC0BAF5A6; Wed, 15 Oct 2003 21:13:54 +0200 (CEST) Date: Wed, 15 Oct 2003 21:01:23 +0200 Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: midcom@ietf.org To: Pyda Srisuresh From: Martin Stiemerling In-Reply-To: <20031012070122.91895.qmail@web40401.mail.yahoo.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Am Sonntag, 12.10.03, um 09:01 Uhr (Europe/Berlin) schrieb Pyda Srisuresh: > > --- Martin Stiemerling wrote: > <... stuff deleted> >> | 3. PER should simply be labelled as session creation request. The >> text in >> | the draft that refers this as BIND in some cases shoudl simply be >> | eliminated. PER essentially boils down to setting up NAT >> sessions/flows >> | using pre-established binds or pre-reserved map entries or simply >> | creating a new session. When the session is created, the response >> should >> | indicate the BINDs used, if any, and the translation end-points for >> the >> | session. >> >> You are right in saying that with PER a NAT session is created. But >> for >> instance consider this scenario: >> >> A PER request with an internal address (A0) and a wildcarded external >> sender (A3) (dataflow from outside to inside). The external sender is >> not >> known (One example is SIP early media). For that case you can not >> start a >> NAT session, since the NAT must create a NAT bind. Via this NAT bind >> several UDP/RTP flows from several destinations may traverse the >> middlebox >> to A0. > > If a BIND can be created ahead of time, PRR shoudl be used. Any number > of > sessions can use that BIND (for the directionality supported by the > BIND). The intention is of PRR is just reservation of resources at the middlebox. A PRR does not enable any BIND in the NAT. > The > second half of the session is irrelevant to the BIND. However, if the > PRR is > unsuccessful, PER maybe used by the agent to setup a NAT session (with > wildcard > match for external source and port) & the PER response will return > back the > session Id. When the actual session occurs, that session parameters > will be > used to plug the holes in the NAT session. Middlebox may be instructed > to > notify the agent when the holes are plugged by the actual session. > >> >> | >> | The twice-NAT example doesn't make sense. If the session is between >> A0 & >> | A1 (as would be in the case of twice-NAT) the agent cannot know A3 >> ahead >> | of time. However, that is what the PER request parametere >> description >> | indicates. >> >> Hmm, I don't see the issue you raise immediately. >> > > Basically, in a twice-NAT scenario, both source and destination > end-points are > in the same address realm on both end-points. So, A session between A0 > and A1 > would be translated as a session between A2 & A3. OK, I see. > >> A3 is the external end point and A1 the inside IP address/port number >> at >> the twice-NAT. The application level session is between A0 and A3, >> but the >> IP/transport 'sessions' are between A0/A1 and A2/A3. > > Right. So, if the agent is located on A0, the agent only knows A0 and > A1. Agent > cannot know A3, right? The agent is the ALG which is not on A0. Of course it is possible to run MIDCOM between A0 (the host inside the private address realm). In this case (agent = A0) it cannot know A3. The agent (agent != A0) can know A3, since he intercepts and receives the signalling messages. >> >> Could you give me some more hints? >> > > Basically, what I am saying is that PER request parameters ought to > indicate > the session parameters as it knows. When I see it right, PER does. PER returns to the agent A1 and A2. But PER requires that the agent knows A3. > This is irrespective of whether the agent > is inside private domain or outside private domain; whether the agent > is > resident on one of the end-hosts or on a proxy in-between. > >> >> | 3. The document says in several places that the NAT is one of >> traditional >> | NAT or Twice-NAT. What about bi-directional NAT? I saw this >> mentioned >> | just once in PER description. When you support bi-directional NAT, >> it is >> | important for the PRR and PERs to support sessions initiated from >> the >> | outside, in additiona to sessions initiated from the private realm. >> The >> | request parameters in PRR and PER are not adequate to support this. >> >> That's not true. For PRR the direction is not relevant, since only a >> resource reservation is made at the NAT. > > Not true. BIND direction determines which sessions are allowed to use > the BIND. You are right that BIND direction determines the sessions that are allowed to use the BIND. But PRR does not create necessarily a BIND, PRR does a resource reservation at the middlebox. If a BIND is created it must be blocked by any mean, so it is not used through any packet. > >> In PER there is the flow >> direction >> parameter that indicates the flow direction (inbound, outbound, or >> bi-directional). So with this it is possible to allow even sessions >> initiated from the outside. > <... snipped> > > regards, > suresh > > ===== > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 16 01:20:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07556 for ; Thu, 16 Oct 2003 01:20:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA0YQ-0004Nm-BR for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 01:20:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G5K69R016822 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 01:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA0YM-0004Mj-PC; Thu, 16 Oct 2003 01:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA0Y9-0004M4-Qh for midcom@optimus.ietf.org; Thu, 16 Oct 2003 01:19:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07513 for ; Thu, 16 Oct 2003 01:19:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA0Y6-0000SC-00 for midcom@ietf.org; Thu, 16 Oct 2003 01:19:46 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AA0Y6-0000S9-00 for midcom@ietf.org; Thu, 16 Oct 2003 01:19:46 -0400 Received: from ccrle.nec.de (p50840F97.dip.t-dialin.net [80.132.15.151]) by ftp.ccrle.nec.de (Postfix) with ESMTP id D9921F5A6 for ; Thu, 16 Oct 2003 07:24:03 +0200 (CEST) Date: Thu, 16 Oct 2003 07:15:04 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Martin Stiemerling To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [midcom] New Semantics ID Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have posted an updated version of the MIDCOM semantics. You can find the I-D here in advance: http://www.stiemerling.org/id/draft-ietf-midcom-semantics-06.txt we have added the text attached below, based on a comment of Wanqun. Martin Change in semantics: Additionally the request message of PER and reply message of PRS contains a direction of flow parameter. This direction of flow parameter indicates for UDP and IP the direction of packets traversing the middlebox. For 'inbound' the UDP packets are traversing from outside to inside, for 'outbound' the UDP packets are traversing from inside to the outside. In both cases of 'inbound' and 'outbound' the packets can traverse the middelbox only uni- directional. A bi-directional flow is enabled through 'bi- directional' as direction of flow parameter. In the case of TCP the packet flow is always bi-directional, but the direction of flow parameter is defined as: - inbound: bi-directional TCP packet flow. First packet, with TCP SYN flag set, must arrive at the middlebox at the outside interface. - outbound: bi-directional TCP packet flow. First packet, with TCP SYN flag set, must arrive at the middlebox at the inside interface. - bi-directional: bi-directional TCP packet flow. First packet, with TCP SYN flag set, may arrive at inside or outside interface. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 16 05:03:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25301 for ; Thu, 16 Oct 2003 05:03:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA42P-0001gS-Et for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 05:03:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G93GpY006473 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 05:03:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA42D-0001fd-Do; Thu, 16 Oct 2003 05:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA41k-0001ek-UI for midcom@optimus.ietf.org; Thu, 16 Oct 2003 05:02:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25267 for ; Thu, 16 Oct 2003 05:02:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA41g-0002Kj-00 for midcom@ietf.org; Thu, 16 Oct 2003 05:02:32 -0400 Received: from einsteinium.btinternet.com ([194.73.73.147]) by ietf-mx with esmtp (Exim 4.12) id 1AA41g-0002KY-00 for midcom@ietf.org; Thu, 16 Oct 2003 05:02:32 -0400 Received: from host213-122-32-198.in-addr.btopenworld.com ([213.122.32.198] helo=tkw) by einsteinium.btinternet.com with smtp (Exim 3.22 #23) id 1AA41T-0005Bs-00; Thu, 16 Oct 2003 10:02:19 +0100 Message-ID: <006501c393c4$66b33700$0200000a@tkw> From: "Pete Cordell" To: "Paul Francis" , "Peterson, Jon" Cc: References: <003301c3931a$781e72c0$0200000a@tkw> <004901c39322$cf8e0c70$ec615480@cs.cornell.edu> Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Thu, 16 Oct 2003 09:49:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul, Yes - I think it would be worth capturing this sort of thing as part of starting a work item. We would be happy to create an appropriate draft. Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Paul Francis" To: "Pete Cordell" ; "Peterson, Jon" Cc: Sent: 15 October 2003 14:46 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN > Could you briefly list these significant developments in Symmetric NAT > traversal? > > Thanks, > > PF > > > ----- Original Message ----- > From: "Pete Cordell" > To: "Peterson, Jon" ; "Mmusic" > Cc: ; "Jonathan Rosenberg" > Sent: Wednesday, October 15, 2003 8:47 AM > Subject: [midcom] Re: [MMUSIC] Status of TURN > > > > Dear Jon, > > > > I'm very surprised to see that TURN is being encouraged to be put forward > as > > an individual submission. We believe that TURN has major security flaws, > is > > incomplete, and there are better ways of achieving Symmetric NAT > traversal. > > Suggesting it should become an RFC without debate and full consideration > > would be wrong. > > > > If you remember, TURN was just one of the candidates put forward as a > > pre-Midcom solution that at that time was put aside in favour of > developing > > a consensus protocol. Despite our commitment, consensus wasn't reached, > > mainly due to the amount of effort that was being put into SIP (RFC3261) > by > > other important stake holders. > > > > We feel that to arbitrarily promote TURN at this time is short cutting the > > consensus making process. Surely, if there is sufficient interest in a > > standard of this nature, the correct way forward is to assign it as a work > > item in a suitable group and re-start the consensus process. If so, we > > remain willing to help with time, resource and considerable technical > > know-how. Several significant developments have meant the world of > Symmetric > > NAT traversal has advanced considerably since the pre-Midcom days. > > > > Regards, > > > > Pete. > > > > ============================================= > > Pete Cordell > > Ridgeway > > ============================================= > > > > ----- Original Message ----- > > From: "Peterson, Jon" > > To: "'Joel Tran'" ; "Jonathan Rosenberg" > > ; "Mmusic" > > Sent: 09 October 2003 17:08 > > Subject: RE: [MMUSIC] Status of TURN > > > > > > > > > > The Transport Area Directors understand that this document will proceed > as > > > an individual submission, outside the context of any of the working > groups > > > in the Transport Area. It is clearly of interest to a number of these > > > working groups. > > > > > > I gather that at least one more revision needs to be undertaken before > > this > > > document will be considered for publication as an RFC, but we're very > > > interested to see it go forward. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > (co-AD for Transport) > > > > > > > -----Original Message----- > > > > From: Joel Tran [mailto:joel_tran@hotmail.com] > > > > Sent: Tuesday, October 07, 2003 11:08 AM > > > > To: Jonathan Rosenberg; Mmusic > > > > Subject: [MMUSIC] Status of TURN > > > > > > > > > > > > Hi Jonathan, > > > > > > > > I would like to ask you two little questions concerning TURN. > > > > > > > > First, I would like to know what is the exact status of TURN? > > > > Will it be > > > > adopted as a Workgroup item of MMUSIC since TURN is refeered > > > > in various > > > > documents? > > > > > > > > Second, I would like to ask you if there is a reason why the > > > > lastest version > > > > of the draft is not on the IETF web and only available throught > > > > http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? > > > > > > > > Thanks, > > > > ...J > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 16 05:56:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26372 for ; Thu, 16 Oct 2003 05:56:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA4rV-0003xW-U7 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 05:56:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G9u5Dp015204 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 05:56:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA4rR-0003wI-RK; Thu, 16 Oct 2003 05:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA4ql-0003sl-J9 for midcom@optimus.ietf.org; Thu, 16 Oct 2003 05:55:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26327 for ; Thu, 16 Oct 2003 05:55:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA4qh-0002ia-00 for midcom@ietf.org; Thu, 16 Oct 2003 05:55:15 -0400 Received: from web40403.mail.yahoo.com ([66.218.78.100]) by ietf-mx with smtp (Exim 4.12) id 1AA4qg-0002i2-00 for midcom@ietf.org; Thu, 16 Oct 2003 05:55:15 -0400 Message-ID: <20031016095444.11828.qmail@web40403.mail.yahoo.com> Received: from [67.164.29.130] by web40403.mail.yahoo.com via HTTP; Thu, 16 Oct 2003 02:54:44 PDT Date: Thu, 16 Oct 2003 02:54:44 -0700 (PDT) From: Pyda Srisuresh Subject: Re: Group Ids (part 3 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) To: Martin Stiemerling Cc: midcom@ietf.org In-Reply-To: <7102D345-FF42-11D7-8B7C-0003936FD19E@ccrle.nec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > > If you are saying the semantics design team opted for this approach, > > while > > either approach is acceptable, I understand that. The document should, > > however, > > state this explicitly. Otherwise, the reader gets the impression that > > the > > semantics document is mandating this on the Midcom protocol designer, > > as it did > > with everything else in the document. > > Yes, the design team has chosen the approach. Unfortunately, I do not > see the opportunity to justify every design choice within the document. > Every protocol description has some implicit design choices that are > not explicitly stated within the specific document. > Well, the problem is that the semantics document states "the semantics below provide a minimum necessary subset of what must be implemented". I.e., there is a mandating tone on the midcom protocol designer throughout the document. Yet, from what you say above, the Midcom protocol designer need not go with the design choice you made and still meet the midcom requirements. The document should state what really is mandatory and what is not. regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 16 06:31:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27278 for ; Thu, 16 Oct 2003 06:31:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5PP-0005gl-Kw for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 06:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GAV7va021860 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 06:31:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5PJ-0005fi-Lr; Thu, 16 Oct 2003 06:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5Ol-0005dA-Pf for midcom@optimus.ietf.org; Thu, 16 Oct 2003 06:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27168 for ; Thu, 16 Oct 2003 06:30:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA5Oh-000318-00 for midcom@ietf.org; Thu, 16 Oct 2003 06:30:23 -0400 Received: from web40402.mail.yahoo.com ([66.218.78.99]) by ietf-mx with smtp (Exim 4.12) id 1AA5Og-00030b-00 for midcom@ietf.org; Thu, 16 Oct 2003 06:30:22 -0400 Message-ID: <20031016102855.28038.qmail@web40402.mail.yahoo.com> Received: from [67.164.29.130] by web40402.mail.yahoo.com via HTTP; Thu, 16 Oct 2003 03:28:55 PDT Date: Thu, 16 Oct 2003 03:28:55 -0700 (PDT) From: Pyda Srisuresh Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in semantics (Version 05)) To: Martin Stiemerling Cc: midcom@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Martin, Please see my comments inline below. regards, suresh --- Martin Stiemerling wrote: > > Am Sonntag, 12.10.03, um 09:01 Uhr (Europe/Berlin) schrieb Pyda > Srisuresh: > > > > > --- Martin Stiemerling wrote: > > <... stuff deleted> > >> | 3. PER should simply be labelled as session creation request. The > >> text in > >> | the draft that refers this as BIND in some cases shoudl simply be > >> | eliminated. PER essentially boils down to setting up NAT > >> sessions/flows > >> | using pre-established binds or pre-reserved map entries or simply > >> | creating a new session. When the session is created, the response > >> should > >> | indicate the BINDs used, if any, and the translation end-points for > >> the > >> | session. > >> > >> You are right in saying that with PER a NAT session is created. But > >> for > >> instance consider this scenario: > >> > >> A PER request with an internal address (A0) and a wildcarded external > >> sender (A3) (dataflow from outside to inside). The external sender is > >> not > >> known (One example is SIP early media). For that case you can not > >> start a > >> NAT session, since the NAT must create a NAT bind. Via this NAT bind > >> several UDP/RTP flows from several destinations may traverse the > >> middlebox > >> to A0. > > > > If a BIND can be created ahead of time, PRR shoudl be used. Any number > > of > > sessions can use that BIND (for the directionality supported by the > > BIND). > > The intention is of PRR is just reservation of resources at the > middlebox. A PRR does not enable any BIND in the NAT. > [suresh] A newly created Bind without an active NAT session is merely a reservation of a resource. > > The > > second half of the session is irrelevant to the BIND. However, if the > > PRR is > > unsuccessful, PER maybe used by the agent to setup a NAT session (with > > wildcard > > match for external source and port) & the PER response will return > > back the > > session Id. When the actual session occurs, that session parameters > > will be > > used to plug the holes in the NAT session. Middlebox may be instructed > > to > > notify the agent when the holes are plugged by the actual session. > > > >> > >> | > >> | The twice-NAT example doesn't make sense. If the session is between > >> A0 & > >> | A1 (as would be in the case of twice-NAT) the agent cannot know A3 > >> ahead > >> | of time. However, that is what the PER request parametere > >> description > >> | indicates. > >> > >> Hmm, I don't see the issue you raise immediately. > >> > > > > Basically, in a twice-NAT scenario, both source and destination > > end-points are > > in the same address realm on both end-points. So, A session between A0 > > and A1 > > would be translated as a session between A2 & A3. > > OK, I see. > > > > >> A3 is the external end point and A1 the inside IP address/port number > >> at > >> the twice-NAT. The application level session is between A0 and A3, > >> but the > >> IP/transport 'sessions' are between A0/A1 and A2/A3. > > > > Right. So, if the agent is located on A0, the agent only knows A0 and > > A1. Agent > > cannot know A3, right? > > The agent is the ALG which is not on A0. Of course it is possible to > run MIDCOM between A0 (the host inside the private address realm). In > this case (agent = A0) it cannot know A3. > > The agent (agent != A0) can know A3, since he intercepts and receives > the signalling messages. > [Suresh] Sounds like, that the document makes assumptions on where the agent should be. > > >> > >> Could you give me some more hints? > >> > > > > Basically, what I am saying is that PER request parameters ought to > > indicate > > the session parameters as it knows. > > When I see it right, PER does. PER returns to the agent A1 and A2. But > PER requires that the agent knows A3. > [suresh] OK. Is this the case where the the agent knows the end-2-end session to be A0-to-A3 or A3-to-A0? What if the the agent knew just A0 and A1. What transaction would the agent use to obtain the S2 and A3? That woudlnt be PER, right? It seems to me, the semantics document is defined for a specific application, and asuming a specific location of where the agent might be located. Is this the case? > > > This is irrespective of whether the agent > > is inside private domain or outside private domain; whether the agent > > is > > resident on one of the end-hosts or on a proxy in-between. > > > >> > >> | 3. The document says in several places that the NAT is one of > >> traditional > >> | NAT or Twice-NAT. What about bi-directional NAT? I saw this > >> mentioned > >> | just once in PER description. When you support bi-directional NAT, > >> it is > >> | important for the PRR and PERs to support sessions initiated from > >> the > >> | outside, in additiona to sessions initiated from the private realm. > >> The > >> | request parameters in PRR and PER are not adequate to support this. > >> > >> That's not true. For PRR the direction is not relevant, since only a > >> resource reservation is made at the NAT. > > > > Not true. BIND direction determines which sessions are allowed to use > > the BIND. > > You are right that BIND direction determines the sessions that are > allowed to use the BIND. But PRR does not create necessarily a BIND, > PRR does a resource reservation at the middlebox. If a BIND is created > it must be blocked by any mean, so it is not used through any packet. > [suresh] This does not make sense. If an address is reserved by an agent for a private end-host (A0); and, another agent representing the same end host (but for a diferent application) needs to use a BIND for that end-host, what do you supoose the middlebox should do? > > > >> In PER there is the flow > >> direction > >> parameter that indicates the flow direction (inbound, outbound, or > >> bi-directional). So with this it is possible to allow even sessions > >> initiated from the outside. > > <... snipped> > > > > regards, > > suresh > > > > ===== > > > ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 16 06:48:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27855 for ; Thu, 16 Oct 2003 06:48:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5fm-0006Zh-4i for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 06:48:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GAm2Ro025270 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 06:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5fk-0006Z7-RZ; Thu, 16 Oct 2003 06:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5fI-0006Yi-6J for midcom@optimus.ietf.org; Thu, 16 Oct 2003 06:47:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27826 for ; Thu, 16 Oct 2003 06:47:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA5fD-0003DT-00 for midcom@ietf.org; Thu, 16 Oct 2003 06:47:27 -0400 Received: from web40403.mail.yahoo.com ([66.218.78.100]) by ietf-mx with smtp (Exim 4.12) id 1AA5fD-0003Cn-00 for midcom@ietf.org; Thu, 16 Oct 2003 06:47:27 -0400 Message-ID: <20031016104658.22464.qmail@web40403.mail.yahoo.com> Received: from [67.164.29.130] by web40403.mail.yahoo.com via HTTP; Thu, 16 Oct 2003 03:46:58 PDT Date: Thu, 16 Oct 2003 03:46:58 -0700 (PDT) From: Pyda Srisuresh Subject: Re: PRRs (was Re: Fwd: [midcom] Changes in semantics (Version 05)) To: Martin Stiemerling Cc: midcom@ietf.org In-Reply-To: <5BEC48E6-FF40-11D7-8B7C-0003936FD19E@ccrle.nec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Martin, My comments inline below. regards, suresh <... stuff deleted> --- Martin Stiemerling wrote: > Hi Suresh, > > > Am Sonntag, 12.10.03, um 08:28 Uhr (Europe/Berlin) schrieb Pyda > Srisuresh: > > > Hi Martin, > > > > My apologies for not being able to respond sooner. Please see my > > comments > > Sorry for the delayed answer, I have been on a trip. I'll answer to all > the three parts. > > Regards > Martin > > > below. I am breaking up the response into 3 parts so as to close > > individual > > parts seperately. Hope that is OK by you. In this e-mail I am going to > > simply > > focus on PRR. > > > > regards, > > suresh > > > > --- Martin Stiemerling wrote: > >> Hi Suresh, > >> > >> thanks for checking the document again. More comments inline and I > >> hope on > >> more comments from other working group members. > >> > >> Martin > >> > >> --On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh > >> wrote: > >> > >> | Hi, > >> | > >> | I briefly read through the draft this weekend. I still do not > >> believe, the > >> | semantics is clear. The abstractions are not adequate to eliminate > >> | ALGs from a middlebox. > >> | > >> | 1. Terminology - I do not believe, you should proliferate of > >> semantics > >> | for "NAT binding". This sounds like, it will be whatever you want > >> it to > >> | be in sessing up a session. > >> > >> The intention was not to proliferate, but more an approach to bring > >> more > >> light to issue of NAT binding. Do you think that it confuses more > >> than it > >> does help? > > > > Yes. It is confusing to redefine the term. It would be better to use > > the term > > as originally defined and intended. > > Ok, I see the point, but then we are returning to the starting point: > No clear defintion of how NAT binding is used in the semantics document. > [suresh] I am suggesting that the usage of bind in the document be changed to adhere to the definition of the term as it is used by NAT middleboxes. > > > >> > >> | > >> | 2. PRR is still fuzzy. The PRR reserves a maximum of two IP > >> addresses (in > >> | the case of twice-NAT) and/or several ports on an address. > >> Depending upon > >> | what the agent lists in the request parameters, this can be > >> reservation > >> | of an address bind, or reservation of a bunch of ports (from a NAPT > >> map > >> | entry, presumably) or reservation of an address each from two map > >> | entries. The middlebox returned rule identifier can represent any > >> of this > >> | (Bind handle or single map reservation or two address map > >> reservations). > >> | This is simply a lot of stuff in a single transaction. Very > >> difficult and > >> | confusing for a middlebox to do this. > >> > >> Yes, that may look confusing, but pushing the task to the MIDCOM > >> agent is > >> more even more confusing to him. > > > > I wasnt suggesting pushing anything to the Midcom agent, much less > > make it > > confusing. All I am saying is there should be transparency between > > Midcom > > requests and middlebox resources. When there is transparecy, there > > will be > > little consfusion on the part of the agent or the middlebox. > > > > Here is something that might work for the agents as well as the > > middleboxes. Do > > let me know what you think. > > > > Assume, the agent knows the middlebox IP interface(for which the midcom > > requests shoudl be applied). Let us say the purpose of PRR is > > restricted to > > reserve one of the following: > > > > a) Reserve translation address & port for SrcEndPOint on an > > inbound session > > b) Reserve translation address & port for DstEndPoint on an > > inbound session > > c) Reserve translation address & port for SrcEndpOint on an > > outbound > > session > > d) Reserve translation address & port for DstEndpoint on an > > outbound > > session > > e) (a) & (b) -- Twice NAT sessions > > f) (c) & (d) -- Twice NAT sessions > > g) (a) | (d) -- Bidirectional sessions > > h) (b) | (c) -- Bidirectional sessions > > i) Reserve translation address & portpair (for matching oddity) for > > SrcEndPOint on an inbound session > > j) Reserve translation address & portpair (for matching oddity) for > > DstEndPoint on an inbound session > > k) Reserve translation address & portpair (for matching oddity) for > > SrcEndpOint on an outbound session > > l) Reserve translation address & portpair (for matching oddity) for > > DstEndpoint on an outbound session > > > > It is quite late for me, but as far as I can see we agree on this above. > [suresh] OK. > > For these, the response will consist of a maximum of two binds. As you > > know, > > Bind is essentially a reserve entity. A Bind is not enforced unless > > there is a > > live session that uses it. The reponse in the case of (a), (b), (c) or > > (d), can > > be a single address bind or port Bind. In the case of (e) and (f), the > > response > > is two BINDs. In the case of (g) or (h), the response can be a single > > BIND, but > > is set to be bi-directional. In the case of (i), (j), (k) or (l), the > > response > > can be two port binds or a single address bind. In all cases, the > > response will > > indicate the BIND type(address bind or port bind), BindId and the > > translation > > This example is quite fine, but since we are dealing with middleboxes > (that includes any type of packet filters with any type of filter > engine cababilites), returning a one-to-one mapping may not be > possible. The goal of the semantics is to give a simple handle to the > agent for acting with the middlebox. > [suresh] You can still have a single handle back in response. > Consider a NAT with a firewall engine, first of all if you give a > one-to-one handle to all resources you need to know the location of the > firewall engine (side of the NAT). Second a single NAT bind may be > sufficient for the NAt, but it may involve several firewall rules. For > instance a single SIP call may involve up to four different firewall > rules (one UDP stream in each direction, plus perhaps one RTCP in each > direction). With the approach that the semantics take you have as an > agent only a single handle to deal with NAT binding and firewall rules. > [Suresh] I understand the need for 2 RTP sessions and 2 RTCP sessions. These sessions are not reserved using a PRR. PRR is only for NAT. With PER, sessions can be made as restrictive as you like. > > end points. In the case NAT is unable to assign a BIND, the response > > will > > indicate the same. In such a case, the agent will be advised to use PER > > directly without the use of PRR. > > > > Essentially, I eliminated the ability to reserve a bunch of ports (> > > 2). That > > Reserving a bunch of ports is required by the MIDCOM protocol > requirements. > [suresh] I looked up RFC 3304. I could find just two requirements listed concerning port reservation. These are 2.2.9 and 2.2.10. I am quoting these below for every one's benefit. 2.2.9. When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that the external port number have the same oddity as the internal port. This requirement is to support RTP and RTCP [RFC1889] "oddity" requirements. 2.2.10. When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that a consecutive range of external port numbers be mapped to consecutive internal ports. This requirement is to support RTP and RTCP "sequence" requirements 2.2.9 and 2.2.10 refer to preserving oddity requirement for consecutive ports as required by RTP and RTCP (RFC 1889}. This is no more than 2 ports at a time. In other words, Reserving a bunch of ports (> 2) is not required by RFC 3304. Sound to me, we can establish transparency between PRR and Binds. <... stuff deleted> ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 16 08:35:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00566 for ; Thu, 16 Oct 2003 08:35:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7LN-0003hD-FS for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 08:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GCZ593014183 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 08:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7LJ-0003gI-Lh; Thu, 16 Oct 2003 08:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7L9-0003fv-Lu for midcom@optimus.ietf.org; Thu, 16 Oct 2003 08:34:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00560 for ; Thu, 16 Oct 2003 08:34:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7L8-0004EM-00 for midcom@ietf.org; Thu, 16 Oct 2003 08:34:50 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AA7Kx-0004E8-00 for midcom@ietf.org; Thu, 16 Oct 2003 08:34:39 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2003 05:31:03 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9GCY4eH026735; Thu, 16 Oct 2003 05:34:04 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANE92264; Thu, 16 Oct 2003 05:34:02 -0700 (PDT) Date: Thu, 16 Oct 2003 08:34:00 -0400 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Paul Francis" , "Peterson, Jon" , To: "Pete Cordell" From: Melinda Shore In-Reply-To: <006501c393c4$66b33700$0200000a@tkw> Message-Id: <051409D4-FFD5-11D7-B3E6-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, October 16, 2003, at 04:49 AM, Pete Cordell wrote: > Yes - I think it would be worth capturing this sort of thing as part of > starting a work item. We would be happy to create an appropriate > draft. We've been around this track a few times and I think it would be a mistake to take a few more laps. I would oppose revisiting it yet again unless there's been substantial progress in the arguments for taking this on. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 16 09:09:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01746 for ; Thu, 16 Oct 2003 09:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7sI-0006KW-G4 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 09:09:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GD966X024326 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 09:09:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7sD-0006JW-L3; Thu, 16 Oct 2003 09:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7jn-0005Bu-4O for midcom@optimus.ietf.org; Thu, 16 Oct 2003 09:00:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01429 for ; Thu, 16 Oct 2003 09:00:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7jZ-0004Ub-00 for midcom@ietf.org; Thu, 16 Oct 2003 09:00:05 -0400 Received: from simon.cs.cornell.edu ([128.84.154.10]) by ietf-mx with esmtp (Exim 4.12) id 1AA7jY-0004UY-00 for midcom@ietf.org; Thu, 16 Oct 2003 09:00:04 -0400 Received: from sundial.cs.cornell.edu (sundial.cs.cornell.edu [128.84.96.115]) by simon.cs.cornell.edu (8.11.7/8.11.7/R-3.10) with ESMTP id h9GCxCR19370; Thu, 16 Oct 2003 08:59:27 -0400 (EDT) Received: from FrancisOffice (dhcp97-236.cs.cornell.edu [128.84.97.236]) by sundial.cs.cornell.edu (8.11.7/8.11.7/M-3.12a) with SMTP id h9GCxB614471; Thu, 16 Oct 2003 08:59:12 -0400 (EDT) Message-ID: <014401c393e5$4a4cb200$ec615480@cs.cornell.edu> From: "Paul Francis" To: "Pete Cordell" , "Peterson, Jon" Cc: References: <003301c3931a$781e72c0$0200000a@tkw> <004901c39322$cf8e0c70$ec615480@cs.cornell.edu> <006501c393c4$66b33700$0200000a@tkw> Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Thu, 16 Oct 2003 08:59:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I wasn't suggesting a draft...I was just hoping you'd answer with an email containing a list of these significant developments. PF ----- Original Message ----- From: "Pete Cordell" To: "Paul Francis" ; "Peterson, Jon" Cc: Sent: Thursday, October 16, 2003 4:49 AM Subject: Re: [midcom] Re: [MMUSIC] Status of TURN > Paul, > > Yes - I think it would be worth capturing this sort of thing as part of > starting a work item. We would be happy to create an appropriate draft. > > Pete. > > ============================================= > Pete Cordell > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: "Paul Francis" > To: "Pete Cordell" ; "Peterson, Jon" > > Cc: > Sent: 15 October 2003 14:46 > Subject: Re: [midcom] Re: [MMUSIC] Status of TURN > > > > Could you briefly list these significant developments in Symmetric NAT > > traversal? > > > > Thanks, > > > > PF > > > > > > ----- Original Message ----- > > From: "Pete Cordell" > > To: "Peterson, Jon" ; "Mmusic" > > Cc: ; "Jonathan Rosenberg" > > Sent: Wednesday, October 15, 2003 8:47 AM > > Subject: [midcom] Re: [MMUSIC] Status of TURN > > > > > > > Dear Jon, > > > > > > I'm very surprised to see that TURN is being encouraged to be put > forward > > as > > > an individual submission. We believe that TURN has major security > flaws, > > is > > > incomplete, and there are better ways of achieving Symmetric NAT > > traversal. > > > Suggesting it should become an RFC without debate and full consideration > > > would be wrong. > > > > > > If you remember, TURN was just one of the candidates put forward as a > > > pre-Midcom solution that at that time was put aside in favour of > > developing > > > a consensus protocol. Despite our commitment, consensus wasn't > reached, > > > mainly due to the amount of effort that was being put into SIP (RFC3261) > > by > > > other important stake holders. > > > > > > We feel that to arbitrarily promote TURN at this time is short cutting > the > > > consensus making process. Surely, if there is sufficient interest in a > > > standard of this nature, the correct way forward is to assign it as a > work > > > item in a suitable group and re-start the consensus process. If so, we > > > remain willing to help with time, resource and considerable technical > > > know-how. Several significant developments have meant the world of > > Symmetric > > > NAT traversal has advanced considerably since the pre-Midcom days. > > > > > > Regards, > > > > > > Pete. > > > > > > ============================================= > > > Pete Cordell > > > Ridgeway > > > ============================================= > > > > > > ----- Original Message ----- > > > From: "Peterson, Jon" > > > To: "'Joel Tran'" ; "Jonathan Rosenberg" > > > ; "Mmusic" > > > Sent: 09 October 2003 17:08 > > > Subject: RE: [MMUSIC] Status of TURN > > > > > > > > > > > > > > The Transport Area Directors understand that this document will > proceed > > as > > > > an individual submission, outside the context of any of the working > > groups > > > > in the Transport Area. It is clearly of interest to a number of these > > > > working groups. > > > > > > > > I gather that at least one more revision needs to be undertaken before > > > this > > > > document will be considered for publication as an RFC, but we're very > > > > interested to see it go forward. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > (co-AD for Transport) > > > > > > > > > -----Original Message----- > > > > > From: Joel Tran [mailto:joel_tran@hotmail.com] > > > > > Sent: Tuesday, October 07, 2003 11:08 AM > > > > > To: Jonathan Rosenberg; Mmusic > > > > > Subject: [MMUSIC] Status of TURN > > > > > > > > > > > > > > > Hi Jonathan, > > > > > > > > > > I would like to ask you two little questions concerning TURN. > > > > > > > > > > First, I would like to know what is the exact status of TURN? > > > > > Will it be > > > > > adopted as a Workgroup item of MMUSIC since TURN is refeered > > > > > in various > > > > > documents? > > > > > > > > > > Second, I would like to ask you if there is a reason why the > > > > > lastest version > > > > > of the draft is not on the IETF web and only available throught > > > > > http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? > > > > > > > > > > Thanks, > > > > > ...J > > > > > > > > > > _______________________________________________ > > > > > mmusic mailing list > > > > > mmusic@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > _______________________________________________ > > > midcom mailing list > > > midcom@ietf.org > > > https://www1.ietf.org/mailman/listinfo/midcom > > > > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 16 15:30:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19042 for ; Thu, 16 Oct 2003 15:30:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AADp4-00058P-BH for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 15:30:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GJUAKe019717 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 15:30:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AADow-00054h-IU; Thu, 16 Oct 2003 15:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AADob-00053n-2k for midcom@optimus.ietf.org; Thu, 16 Oct 2003 15:29:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18814; Thu, 16 Oct 2003 15:29:30 -0400 (EDT) Message-Id: <200310161929.PAA18814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 16 Oct 2003 15:29:30 -0400 Subject: [midcom] I-D ACTION:draft-stiemerling-midcom-mib-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for Middlebox Communication Author(s) : J. Quittek, M. Stiemerling Filename : draft-stiemerling-midcom-mib-00.txt Pages : 52 Date : 2003-10-16 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follows closely the MIDCOM semantics defined in RFC XXXX. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-stiemerling-midcom-mib-00.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-stiemerling-midcom-mib-00.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: <2003-10-16143544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-midcom-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-stiemerling-midcom-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-16143544.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 16 21:18:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02266 for ; Thu, 16 Oct 2003 21:18:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJFq-0005qI-Cx for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 21:18:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H1IA42022456 for midcom-archive@odin.ietf.org; Thu, 16 Oct 2003 21:18:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJFh-0005oy-77; Thu, 16 Oct 2003 21:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJEz-0005oF-44 for midcom@optimus.ietf.org; Thu, 16 Oct 2003 21:17:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02229; Thu, 16 Oct 2003 21:17:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAJEw-0004tT-00; Thu, 16 Oct 2003 21:17:14 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AAJEv-0004tD-00; Thu, 16 Oct 2003 21:17:13 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9H1Geca001145; Thu, 16 Oct 2003 21:16:41 -0400 (EDT) Message-ID: <3F8F42F2.6030402@dynamicsoft.com> Date: Thu, 16 Oct 2003 21:16:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: "Peterson, Jon" , Mmusic , midcom@ietf.org References: <003301c3931a$781e72c0$0200000a@tkw> In-Reply-To: <003301c3931a$781e72c0$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: [MMUSIC] Status of TURN Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just because its an individual submission does not mean that comments and criticisms are not welcome. Please feel free to send me a note. Thanks, Jonathan R. Pete Cordell wrote: > Dear Jon, > > I'm very surprised to see that TURN is being encouraged to be put forward as > an individual submission. We believe that TURN has major security flaws, is > incomplete, and there are better ways of achieving Symmetric NAT traversal. > Suggesting it should become an RFC without debate and full consideration > would be wrong. > > If you remember, TURN was just one of the candidates put forward as a > pre-Midcom solution that at that time was put aside in favour of developing > a consensus protocol. Despite our commitment, consensus wasn't reached, > mainly due to the amount of effort that was being put into SIP (RFC3261) by > other important stake holders. > > We feel that to arbitrarily promote TURN at this time is short cutting the > consensus making process. Surely, if there is sufficient interest in a > standard of this nature, the correct way forward is to assign it as a work > item in a suitable group and re-start the consensus process. If so, we > remain willing to help with time, resource and considerable technical > know-how. Several significant developments have meant the world of Symmetric > NAT traversal has advanced considerably since the pre-Midcom days. > > Regards, > > Pete. > > ============================================= > Pete Cordell > Ridgeway > ============================================= > > ----- Original Message ----- > From: "Peterson, Jon" > To: "'Joel Tran'" ; "Jonathan Rosenberg" > ; "Mmusic" > Sent: 09 October 2003 17:08 > Subject: RE: [MMUSIC] Status of TURN > > > >>The Transport Area Directors understand that this document will proceed as >>an individual submission, outside the context of any of the working groups >>in the Transport Area. It is clearly of interest to a number of these >>working groups. >> >>I gather that at least one more revision needs to be undertaken before > > this > >>document will be considered for publication as an RFC, but we're very >>interested to see it go forward. >> >>Jon Peterson >>NeuStar, Inc. >>(co-AD for Transport) >> >> >>>-----Original Message----- >>>From: Joel Tran [mailto:joel_tran@hotmail.com] >>>Sent: Tuesday, October 07, 2003 11:08 AM >>>To: Jonathan Rosenberg; Mmusic >>>Subject: [MMUSIC] Status of TURN >>> >>> >>>Hi Jonathan, >>> >>>I would like to ask you two little questions concerning TURN. >>> >>>First, I would like to know what is the exact status of TURN? >>>Will it be >>>adopted as a Workgroup item of MMUSIC since TURN is refeered >>>in various >>>documents? >>> >>>Second, I would like to ask you if there is a reason why the >>>lastest version >>>of the draft is not on the IETF web and only available throught >>>http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? >>> >>>Thanks, >>>...J >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 17 11:05:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05563 for ; Fri, 17 Oct 2003 11:05:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWA6-0000np-QH for midcom-archive@odin.ietf.org; Fri, 17 Oct 2003 11:05:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HF567U003086 for midcom-archive@odin.ietf.org; Fri, 17 Oct 2003 11:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWA2-0000n8-D4; Fri, 17 Oct 2003 11:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAW9P-0000mA-OA for midcom@optimus.ietf.org; Fri, 17 Oct 2003 11:04:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05533 for ; Fri, 17 Oct 2003 11:04:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAW9L-0004CL-00 for midcom@ietf.org; Fri, 17 Oct 2003 11:04:19 -0400 Received: from gadolinium.btinternet.com ([194.73.73.111]) by ietf-mx with esmtp (Exim 4.12) id 1AAW9K-0004Bu-00 for midcom@ietf.org; Fri, 17 Oct 2003 11:04:19 -0400 Received: from host213-122-18-176.in-addr.btopenworld.com ([213.122.18.176] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #23) id 1AAW91-0003BT-00; Fri, 17 Oct 2003 16:03:59 +0100 Message-ID: <001801c394c0$16be2e60$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: "Peterson, Jon" , References: <051409D4-FFD5-11D7-B3E6-000A95E35274@cisco.com> Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Fri, 17 Oct 2003 16:04:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Melinda, I don't think we really did that many laps. There was a bit of debate while we were trying to understand what we wanted to do and people were tuning into the same wavelength, but once we decided to move forward on a common objective, we put a lot of material out and received hardly any comments back. I put that down to the SIP RFC being finalised at that time. Key players in the pre-midcom work were also key players in the SIP work and just didn't have the spare cycles. So I certainly don't think that we have done enough laps to say that we can't reach consensus here (the SIP user=phone debate alone has probably had more discussion!), and if there is interest in a solution we should do it via the proper consensus making process rather than arbitrarily picking one of the initial candidate solutions. Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Melinda Shore" To: "Pete Cordell" Cc: "Paul Francis" ; "Peterson, Jon" ; Sent: 16 October 2003 13:34 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN > On Thursday, October 16, 2003, at 04:49 AM, Pete Cordell wrote: > > Yes - I think it would be worth capturing this sort of thing as part of > > starting a work item. We would be happy to create an appropriate > > draft. > > We've been around this track a few times and I think it > would be a mistake to take a few more laps. I would oppose > revisiting it yet again unless there's been substantial > progress in the arguments for taking this on. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 17 15:26:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17876 for ; Fri, 17 Oct 2003 15:26:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaEe-0005jY-4J for midcom-archive@odin.ietf.org; Fri, 17 Oct 2003 15:26:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HJQ4Mq022016 for midcom-archive@odin.ietf.org; Fri, 17 Oct 2003 15:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaEa-0005ig-Vv; Fri, 17 Oct 2003 15:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaDf-0005gs-T7 for midcom@optimus.ietf.org; Fri, 17 Oct 2003 15:25:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17842 for ; Fri, 17 Oct 2003 15:24:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAaDe-0007LV-00 for midcom@ietf.org; Fri, 17 Oct 2003 15:25:02 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AAaDd-0007L8-00 for midcom@ietf.org; Fri, 17 Oct 2003 15:25:02 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HJOFd23207; Fri, 17 Oct 2003 15:24:15 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4S6YN1B4; Fri, 17 Oct 2003 15:24:15 -0400 Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5N1XW; Fri, 17 Oct 2003 15:24:15 -0400 Message-ID: <3F9041DB.8010209@nortelnetworks.com> Date: Fri, 17 Oct 2003 15:24:11 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Pyda Srisuresh CC: Martin Stiemerling , midcom@ietf.org Subject: Re: PRRs (was Re: Fwd: [midcom] Changes in semantics (Version 05)) References: <20031016104658.22464.qmail@web40403.mail.yahoo.com> In-Reply-To: <20031016104658.22464.qmail@web40403.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit For heaven's sake, stop equating PRR with BINDs. You keep creating that same straw man only to knock it over. PRR at most creates address map entries. PER creates BINDs. Pyda Srisuresh wrote: [snip] > > 2.2.9 and 2.2.10 refer to preserving oddity requirement for consecutive ports > as required by RTP and RTCP (RFC 1889}. This is no more than 2 ports at a time. > In other words, Reserving a bunch of ports (> 2) is not required by RFC 3304. > Sound to me, we can establish transparency between PRR and Binds. > > <... stuff deleted> > > > ===== > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 20 10:02:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26598 for ; Mon, 20 Oct 2003 10:02:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABabl-0003OB-JI for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 10:02:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KE25CK013023 for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 10:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABabh-0003MT-DE; Mon, 20 Oct 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABabM-0003HL-8V for midcom@optimus.ietf.org; Mon, 20 Oct 2003 10:01:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26581; Mon, 20 Oct 2003 10:01:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABabK-0000Us-00; Mon, 20 Oct 2003 10:01:38 -0400 Received: from zinc.btinternet.com ([194.73.73.148]) by ietf-mx with esmtp (Exim 4.12) id 1ABabJ-0000Up-00; Mon, 20 Oct 2003 10:01:37 -0400 Received: from host213-122-136-104.in-addr.btopenworld.com ([213.122.136.104] helo=tkw) by zinc.btinternet.com with smtp (Exim 3.22 #23) id 1ABaaS-0004Wo-00; Mon, 20 Oct 2003 15:00:44 +0100 Message-ID: <001c01c39712$c4427100$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: "Peterson, Jon" , "Mmusic" , References: <003301c3931a$781e72c0$0200000a@tkw> <3F8F42F2.6030402@dynamicsoft.com> Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Mon, 20 Oct 2003 15:01:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jonathan, That's generous of you, but I basically feel that there is either a need for this work, in which case it should be done as part of the normal open IETF process, or there isn't a need, in which case it should go no further. As I've said elsewhere, I think the reason the effort failed last time was because people were working on the SIP RFC. I know you're superhuman (I am impressed by your output), but I think even you were saturated at that time. And I actually agree with your prioritisation at the time (there's no point in having a traversal solution if there is nothing that needs traversing!) However, to put it bluntly, I would feel aggrieved if those circumstances were later used to justify fast tracking a proposal that did not represent consensus of the interested parties involved. Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Jonathan Rosenberg" To: "Pete Cordell" Cc: "Peterson, Jon" ; "Mmusic" ; Sent: 17 October 2003 02:16 Subject: [midcom] Re: [MMUSIC] Status of TURN > Just because its an individual submission does not mean that comments > and criticisms are not welcome. Please feel free to send me a note. > > Thanks, > Jonathan R. > > Pete Cordell wrote: > > > Dear Jon, > > > > I'm very surprised to see that TURN is being encouraged to be put forward as > > an individual submission. We believe that TURN has major security flaws, is > > incomplete, and there are better ways of achieving Symmetric NAT traversal. > > Suggesting it should become an RFC without debate and full consideration > > would be wrong. > > > > If you remember, TURN was just one of the candidates put forward as a > > pre-Midcom solution that at that time was put aside in favour of developing > > a consensus protocol. Despite our commitment, consensus wasn't reached, > > mainly due to the amount of effort that was being put into SIP (RFC3261) by > > other important stake holders. > > > > We feel that to arbitrarily promote TURN at this time is short cutting the > > consensus making process. Surely, if there is sufficient interest in a > > standard of this nature, the correct way forward is to assign it as a work > > item in a suitable group and re-start the consensus process. If so, we > > remain willing to help with time, resource and considerable technical > > know-how. Several significant developments have meant the world of Symmetric > > NAT traversal has advanced considerably since the pre-Midcom days. > > > > Regards, > > > > Pete. > > > > ============================================= > > Pete Cordell > > Ridgeway > > ============================================= > > > > ----- Original Message ----- > > From: "Peterson, Jon" > > To: "'Joel Tran'" ; "Jonathan Rosenberg" > > ; "Mmusic" > > Sent: 09 October 2003 17:08 > > Subject: RE: [MMUSIC] Status of TURN > > > > > > > >>The Transport Area Directors understand that this document will proceed as > >>an individual submission, outside the context of any of the working groups > >>in the Transport Area. It is clearly of interest to a number of these > >>working groups. > >> > >>I gather that at least one more revision needs to be undertaken before > > > > this > > > >>document will be considered for publication as an RFC, but we're very > >>interested to see it go forward. > >> > >>Jon Peterson > >>NeuStar, Inc. > >>(co-AD for Transport) > >> > >> > >>>-----Original Message----- > >>>From: Joel Tran [mailto:joel_tran@hotmail.com] > >>>Sent: Tuesday, October 07, 2003 11:08 AM > >>>To: Jonathan Rosenberg; Mmusic > >>>Subject: [MMUSIC] Status of TURN > >>> > >>> > >>>Hi Jonathan, > >>> > >>>I would like to ask you two little questions concerning TURN. > >>> > >>>First, I would like to know what is the exact status of TURN? > >>>Will it be > >>>adopted as a Workgroup item of MMUSIC since TURN is refeered > >>>in various > >>>documents? > >>> > >>>Second, I would like to ask you if there is a reason why the > >>>lastest version > >>>of the draft is not on the IETF web and only available throught > >>>http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? > >>> > >>>Thanks, > >>>...J > >>> > >>>_______________________________________________ > >>>mmusic mailing list > >>>mmusic@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/mmusic > >>> > >> > >>_______________________________________________ > >>mmusic mailing list > >>mmusic@ietf.org > >>https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 20 10:29:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28563 for ; Mon, 20 Oct 2003 10:29:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABb1s-0001UM-Lj for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 10:29:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KET44H005698 for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 10:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABb1p-0001T3-2V; Mon, 20 Oct 2003 10:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABb13-0001H7-6d for midcom@optimus.ietf.org; Mon, 20 Oct 2003 10:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28378; Mon, 20 Oct 2003 10:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABb10-0000j2-00; Mon, 20 Oct 2003 10:28:10 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ABb0z-0000gO-00; Mon, 20 Oct 2003 10:28:09 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2003 16:25:40 +0200 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9KERTiw028439; Mon, 20 Oct 2003 07:27:29 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANH70641; Mon, 20 Oct 2003 07:27:27 -0700 (PDT) Date: Mon, 20 Oct 2003 10:27:25 -0400 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , To: "Pete Cordell" From: Melinda Shore In-Reply-To: <001c01c39712$c4427100$0200000a@tkw> Message-Id: <86BB4302-0309-11D8-A84F-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, October 20, 2003, at 10:01 AM, Pete Cordell wrote: > That's generous of you, but I basically feel that there is either a > need for > this work, in which case it should be done as part of the normal open > IETF > process, or there isn't a need, in which case it should go no further. I hope it's understood that the publication of individual submissions (i.e. not working group output) is in fact part of the normal open IETF process, available to anybody who wishes to jump through the various hoops to do it. RFC 2026 mentions it but probably doesn't make it as clear as it should. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 20 11:47:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01309 for ; Mon, 20 Oct 2003 11:47:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcFO-0004H5-Kc for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 11:47:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KFl6pn016386 for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 11:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcFK-0004E6-Iu; Mon, 20 Oct 2003 11:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcEP-0003zv-Oe for midcom@optimus.ietf.org; Mon, 20 Oct 2003 11:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01274; Mon, 20 Oct 2003 11:45:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcEO-0001ZN-00; Mon, 20 Oct 2003 11:46:04 -0400 Received: from protactinium.btinternet.com ([194.73.73.176]) by ietf-mx with esmtp (Exim 4.12) id 1ABcEN-0001ZK-00; Mon, 20 Oct 2003 11:46:03 -0400 Received: from dial81-135-11-42.in-addr.btopenworld.com ([81.135.11.42] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #23) id 1ABcE6-0000bu-00; Mon, 20 Oct 2003 16:45:47 +0100 Message-ID: <003a01c39721$709a9640$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , References: <86BB4302-0309-11D8-A84F-000A95E35274@cisco.com> Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Mon, 20 Oct 2003 16:47:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, I would argue that individual submissions are part of the IETF process, but are not necessarily open. If we and Jonathan were to evolve TURN (or something similar) outside of a working group item, that would effectively be a behind closed doors effort, and would not be open in the sense that most IETF working group work is. Publishing TURN as an individual submission would also set a bad precedent. There's been a significant boom in the number of traversal solution providers lately. Publishing TURN would set the precedent that it is OK to bypass the open process (at least in the traversal space) and use the individual submission process to get that attractive RFC number (marketing people and buyers don't really care what type it is). True, the individual process requires a lot of patience. However, the open process requires a thick skin, a willingness to compromise, re-writing code, possibly delayed launch dates and ... a lot of patience! Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Melinda Shore" To: "Pete Cordell" Cc: "Jonathan Rosenberg" ; "Peterson, Jon" ; "Mmusic" ; Sent: 20 October 2003 15:27 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN > On Monday, October 20, 2003, at 10:01 AM, Pete Cordell wrote: > > That's generous of you, but I basically feel that there is either a > > need for > > this work, in which case it should be done as part of the normal open > > IETF > > process, or there isn't a need, in which case it should go no further. > > I hope it's understood that the publication of individual > submissions (i.e. not working group output) is in fact part of > the normal open IETF process, available to anybody who wishes > to jump through the various hoops to do it. RFC 2026 mentions > it but probably doesn't make it as clear as it should. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 20 12:13:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02193 for ; Mon, 20 Oct 2003 12:13:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABceV-0002nM-I4 for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 12:13:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KGD3Rn010721 for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 12:13:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABceT-0002mD-KJ; Mon, 20 Oct 2003 12:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcdV-0002bJ-8l for midcom@optimus.ietf.org; Mon, 20 Oct 2003 12:12:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02166; Mon, 20 Oct 2003 12:11:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcdT-0001qq-00; Mon, 20 Oct 2003 12:11:59 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ABcdT-0001ql-00; Mon, 20 Oct 2003 12:11:59 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2003 18:09:31 +0200 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9KGBJiw001237; Mon, 20 Oct 2003 09:11:19 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANH79877; Mon, 20 Oct 2003 09:11:17 -0700 (PDT) Date: Mon, 20 Oct 2003 12:11:15 -0400 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , To: "Pete Cordell" From: Melinda Shore In-Reply-To: <003a01c39721$709a9640$0200000a@tkw> Message-Id: <07AB2C20-0318-11D8-A84F-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, October 20, 2003, at 11:47 AM, Pete Cordell wrote: > I would argue that individual submissions are part of the IETF > process, but > are not necessarily open. If we and Jonathan were to evolve TURN (or > something similar) outside of a working group item, that would > effectively > be a behind closed doors effort, and would not be open in the sense > that > most IETF working group work is. That's one way to look at it, I suppose, but the point really is that publication of individual submissions is a route open to anybody and that there's no process subversion here. Note as well that it's being published in draft form and he's solicited input. I'm actually not very happy about this, myself, and would oppose pretty much any relaying technology. Aside from the technical issues, among the unfortunate consequences of all this pre-midcom stuff has been that it's taken the pressure off of firewall/NAT vendors to do something useful. That's not good. But regardless of how I feel personally about all this stuff I really think that advancing an individual draft towards publication is not even remotely an abuse of IETF process. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 20 13:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04175 for ; Mon, 20 Oct 2003 13:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdac-0007aU-Po for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 13:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHD607029160 for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 13:13:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdaY-0007YS-CK; Mon, 20 Oct 2003 13:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdZY-0007GY-Ui for midcom@optimus.ietf.org; Mon, 20 Oct 2003 13:12:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04083; Mon, 20 Oct 2003 13:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdZW-0002Np-00; Mon, 20 Oct 2003 13:11:58 -0400 Received: from carbon.btinternet.com ([194.73.73.92]) by ietf-mx with esmtp (Exim 4.12) id 1ABdZW-0002Nm-00; Mon, 20 Oct 2003 13:11:58 -0400 Received: from host213-122-128-105.in-addr.btopenworld.com ([213.122.128.105] helo=tkw) by carbon.btinternet.com with smtp (Exim 3.22 #23) id 1ABdZB-0002Q6-00; Mon, 20 Oct 2003 18:11:37 +0100 Message-ID: <000b01c3972d$6e4a6e40$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , References: <07AB2C20-0318-11D8-A84F-000A95E35274@cisco.com> Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Mon, 20 Oct 2003 18:13:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree that the process allows this. However, I believe it would be unwise to take this route. The IESG can recommend that a draft not be published if (among other reasons) it conflicts with work in the IETF. The effort was stopped because people were too busy doing other things, rather than it was not possible to reach consensus, hence it is not a failed effort in that sense. Now that people have more time, it seems that there is still interest in it from more than one group. Hence the correct thing to do is see whether the work should be resumed. (If you like, the work should have been considered paused rather than stopped.) It seems an act of considerable bad faith to stop a piece of work going forward because you are busy, and then later claim that your individual submission should be adopted because the work was stopped. There seems only two options: the work item is re-started, or all work is stopped. To do otherwise would be an abuse of the spirit of the IETF even if it is not in violation of the written rules. Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Melinda Shore" To: "Pete Cordell" Cc: "Jonathan Rosenberg" ; "Peterson, Jon" ; "Mmusic" ; Sent: 20 October 2003 17:11 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN > On Monday, October 20, 2003, at 11:47 AM, Pete Cordell wrote: > > I would argue that individual submissions are part of the IETF > > process, but > > are not necessarily open. If we and Jonathan were to evolve TURN (or > > something similar) outside of a working group item, that would > > effectively > > be a behind closed doors effort, and would not be open in the sense > > that > > most IETF working group work is. > > That's one way to look at it, I suppose, but the point really > is that publication of individual submissions is a route open > to anybody and that there's no process subversion here. Note > as well that it's being published in draft form and he's > solicited input. > > I'm actually not very happy about this, myself, and would > oppose pretty much any relaying technology. Aside from the > technical issues, among the unfortunate consequences of all > this pre-midcom stuff has been that it's taken the pressure > off of firewall/NAT vendors to do something useful. That's > not good. But regardless of how I feel personally about all > this stuff I really think that advancing an individual draft > towards publication is not even remotely an abuse of IETF > process. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 20 15:28:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17085 for ; Mon, 20 Oct 2003 15:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfhD-0004Ol-2b for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 15:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KJS3DD016901 for midcom-archive@odin.ietf.org; Mon, 20 Oct 2003 15:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfhB-0004Nq-E0; Mon, 20 Oct 2003 15:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfgu-0004Fn-Vg for midcom@optimus.ietf.org; Mon, 20 Oct 2003 15:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16831; Mon, 20 Oct 2003 15:27:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfgt-0004iV-00; Mon, 20 Oct 2003 15:27:43 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1ABfgs-0004gL-00; Mon, 20 Oct 2003 15:27:42 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 20 Oct 2003 12:27:11 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Oct 2003 12:27:11 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 20 Oct 2003 12:27:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Oct 2003 12:26:42 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 20 Oct 2003 12:27:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] Re: [MMUSIC] Status of TURN Date: Mon, 20 Oct 2003 12:27:06 -0700 Message-ID: Thread-Topic: [midcom] Re: [MMUSIC] Status of TURN thread-index: AcOXLYb7Mf07MWqPSTKNyEE9RIqPAAAEcP7g From: "Christian Huitema" To: "Pete Cordell" , "Melinda Shore" Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , X-OriginalArrivalTime: 20 Oct 2003 19:27:10.0367 (UTC) FILETIME=[28243AF0:01C39740] Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Individual submissions are a well established part of the process, and should be considered a fine way to make progress when a working group would not. There is a catch, however. Individual contributions are very seldom published as proposed standards -- they normally end up as either experimental or informational. The criteria for publishing something as informational ought to be, demonstration of at least some significant interest in the community -- but not necessarily demonstration of consensus. The bar for refusing publication in the presence of enough interest has to be somewhat high -- basically, the group has to be convinced that implementing the proposal as is would damage the Internet.=20 Obviously, publication as a proposed standard would require the equivalent of WG consensus. I don't believe there is such consensus on TURN. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Oct 21 07:17:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13491 for ; Tue, 21 Oct 2003 07:17:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuVf-0000FM-Da for midcom-archive@odin.ietf.org; Tue, 21 Oct 2003 07:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LBH7fl000907 for midcom-archive@odin.ietf.org; Tue, 21 Oct 2003 07:17:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuVZ-0000D7-Uo; Tue, 21 Oct 2003 07:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuUl-0008Sm-Fk for midcom@optimus.ietf.org; Tue, 21 Oct 2003 07:16:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13432 for ; Tue, 21 Oct 2003 07:16:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABuUk-0002Jq-00 for midcom@ietf.org; Tue, 21 Oct 2003 07:16:10 -0400 Received: from gadolinium.btinternet.com ([194.73.73.111]) by ietf-mx with esmtp (Exim 4.12) id 1ABuUk-0002Jm-00 for midcom@ietf.org; Tue, 21 Oct 2003 07:16:10 -0400 Received: from host213-122-110-125.in-addr.btopenworld.com ([213.122.110.125] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #23) id 1ABuUZ-0003jJ-00; Tue, 21 Oct 2003 12:16:00 +0100 Message-ID: <006601c397c4$ebabe0c0$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: References: <07AB2C20-0318-11D8-A84F-000A95E35274@cisco.com> Subject: Aside to: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Tue, 21 Oct 2003 12:11:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I'm actually not very happy about this, myself, and would > oppose pretty much any relaying technology. Aside from the > technical issues, among the unfortunate consequences of all > this pre-midcom stuff has been that it's taken the pressure > off of firewall/NAT vendors to do something useful. That's > not good. But regardless of how I feel personally about all > this stuff I really think that advancing an individual draft > towards publication is not even remotely an abuse of IETF > process. > > Melinda Just to answer to the point you raised here Melinda, I think one of the reasons FW/NAT vendors have not done useful things is that there isn't much VoIP traffic out there. There's not much VoIP traffic out there because it doesn't go through FW/NAT very well! My hope is that pre-midcom solutions will break that cycle. They have their limitations and that's what will move the technology on. In other words, it might not be where you want to end up, but it's a necessary stop on the way. Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Oct 21 16:01:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04992 for ; Tue, 21 Oct 2003 16:01:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2gw-0001M6-Ky for midcom-archive@odin.ietf.org; Tue, 21 Oct 2003 16:01:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LK1I2k005206 for midcom-archive@odin.ietf.org; Tue, 21 Oct 2003 16:01:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2gj-0001F8-Pi; Tue, 21 Oct 2003 16:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2g4-0000rX-Lw for midcom@optimus.ietf.org; Tue, 21 Oct 2003 16:00:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04605; Tue, 21 Oct 2003 16:00:13 -0400 (EDT) Message-Id: <200310212000.QAA04605@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 Oct 2003 16:00:13 -0400 Subject: [midcom] I-D ACTION:draft-shore-midcom-protos-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Talking to Stuff In The Network: Middlebox Communication Models Author(s) : M. Shore Filename : draft-shore-midcom-protos-00.txt Pages : 11 Date : 2003-10-21 It is increasingly common for applications to want to influence the behavior of equipment in the network, in violation of various tenets underpinning the the design of IP. A number of different mechanisms and architectures have been proposed, and this very drafty draft is a hoped to be a start at discussing some of the issues related to protocols used for middlebox communication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shore-midcom-protos-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-shore-midcom-protos-00.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-shore-midcom-protos-00.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: <2003-10-21153916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shore-midcom-protos-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shore-midcom-protos-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21153916.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 22 01:16:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27968 for ; Wed, 22 Oct 2003 01:16:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBLn-0006xv-FR for midcom-archive@odin.ietf.org; Wed, 22 Oct 2003 01:16:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M5G3kH026769 for midcom-archive@odin.ietf.org; Wed, 22 Oct 2003 01:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBLl-0006wG-Bm; Wed, 22 Oct 2003 01:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBLg-0006um-AL for midcom@optimus.ietf.org; Wed, 22 Oct 2003 01:15:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27958; Wed, 22 Oct 2003 01:15:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACBLc-0000An-00; Wed, 22 Oct 2003 01:15:52 -0400 Received: from rhenium.btinternet.com ([194.73.73.93]) by ietf-mx with esmtp (Exim 4.12) id 1ACBLb-0000Aj-00; Wed, 22 Oct 2003 01:15:52 -0400 Received: from host213-122-34-206.in-addr.btopenworld.com ([213.122.34.206] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #23) id 1ACBL7-000235-00; Wed, 22 Oct 2003 06:15:22 +0100 Message-ID: <004d01c3985b$b1f25340$0200000a@tkw> From: "Pete Cordell" To: "Christian Huitema" , "Melinda Shore" Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , References: Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Wed, 22 Oct 2003 06:14:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What you say Christian is technically absolutely correct. However this communities appetite for implementing and labelling their products with even -00 draft material suggests to me that many implementers (and probably their customers) are not bothered by these subtleties of IETF process. Certainly it would help to know whether informational or proposed standard is being sought for this draft. Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Christian Huitema" To: "Pete Cordell" ; "Melinda Shore" Cc: "Jonathan Rosenberg" ; "Peterson, Jon" ; "Mmusic" ; Sent: 20 October 2003 20:27 Subject: RE: [midcom] Re: [MMUSIC] Status of TURN Individual submissions are a well established part of the process, and should be considered a fine way to make progress when a working group would not. There is a catch, however. Individual contributions are very seldom published as proposed standards -- they normally end up as either experimental or informational. The criteria for publishing something as informational ought to be, demonstration of at least some significant interest in the community -- but not necessarily demonstration of consensus. The bar for refusing publication in the presence of enough interest has to be somewhat high -- basically, the group has to be convinced that implementing the proposal as is would damage the Internet. Obviously, publication as a proposed standard would require the equivalent of WG consensus. I don't believe there is such consensus on TURN. -- Christian Huitema _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 22 19:59:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07697 for ; Wed, 22 Oct 2003 19:59:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSsi-0001s2-JU for midcom-archive@odin.ietf.org; Wed, 22 Oct 2003 19:59:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MNxCrZ007186 for midcom-archive@odin.ietf.org; Wed, 22 Oct 2003 19:59:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSsW-0001mq-Ll; Wed, 22 Oct 2003 19:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSrh-0001g4-Ro for midcom@optimus.ietf.org; Wed, 22 Oct 2003 19:58:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07494 for ; Wed, 22 Oct 2003 19:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACSrf-00050T-00 for midcom@ietf.org; Wed, 22 Oct 2003 19:58:07 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ACSrf-00050B-00 for midcom@ietf.org; Wed, 22 Oct 2003 19:58:07 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9MNvWC21241 for ; Wed, 22 Oct 2003 19:57:32 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VJ2AYV0D; Wed, 22 Oct 2003 19:57:33 -0400 Received: from nortelnetworks.com (acart1dz.ca.nortel.com [47.129.129.108]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NGFK; Wed, 22 Oct 2003 19:57:33 -0400 Message-ID: <3F97196B.3030303@nortelnetworks.com> Date: Wed, 22 Oct 2003 19:57:31 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Comments on PRR in draft-ietf-midcom-semantics-06.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit These comments come about because of my increased understanding of NATs as a result of study of the NAT MIB. 1. According to the NAT MIB, the NAT type is a configured property of the interface and therefore cannot be arbitrarily chosen. It is for this reason that I think the service type parameter should not be present in the PRR. 2. The internal interface parameter should only be needed if the MIDCOM agent is acting on behalf of an internal endpoint which is served by a different interface. Otherwise I would expect that the middlebox would use the internal interface on which the PRR arrived. Text should be added to indicate this default behaviour. I have no idea how the MIDCOM agent would know the applicable interface identifier and whether it has to use it. It seems to me there is a good argument for expecting that the MIDCOM agent and the internal endpoint are served by the same internal interface, simply because the MIDCOM agent is, by assumption, on the signalling path for the application. 3. I don't see the value of having the external interface parameter. Either the internal address-port A0 is already covered by a binding or it is not. If it is, the external address is determined by the existing bind. If it is not, it should be up to the middlebox to choose the external interface, based on existing mapping table entries, load balancing considerations, etc. 4. The possibility that A0 is a range of addresses rather than a single address is problematic. The problem comes about if different addresses within the range are covered by different existing bindings or map entries pointing to different external addresses. I suppose it will be necessary to have a return code indicating that assignment could not be made due to conflict. Alternatively we can disallow wildcarding of A0 -- something that would make sense to me in terms of application requirements. 5. We have to accept the possibility that a PER following a PRR may fail. This may be because the middlebox has selected an external interface at the PRR stage through which the external endpoint address A3 turns out to be unreachable. The second possibility is in the twice-NAT case and has been discussed already: A3 may turn out to be contained in a binding that conflicts with the mapping to internal address A1 provided as a result of the PRR. Text should be added to the PRR description to indicate this. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Oct 23 09:17:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17595 for ; Thu, 23 Oct 2003 09:17:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfKo-0007L8-3a for midcom-archive@odin.ietf.org; Thu, 23 Oct 2003 09:17:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NDH2vr028208 for midcom-archive@odin.ietf.org; Thu, 23 Oct 2003 09:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfKm-0007Kn-Ot; Thu, 23 Oct 2003 09:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfJy-0007DE-5A for midcom@optimus.ietf.org; Thu, 23 Oct 2003 09:16:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17559; Thu, 23 Oct 2003 09:15:59 -0400 (EDT) Message-Id: <200310231315.JAA17559@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 23 Oct 2003 09:15:59 -0400 Subject: [midcom] I-D ACTION:draft-srisuresh-midcom-mib-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SNMP managed objects for Middlebox Communications (MIDCOM) Author(s) : P. Srisuresh Filename : draft-srisuresh-midcom-mib-00.txt Pages : 48 Date : 2003-10-22 Middlebox communication (midcom) was conceived to move application level gateway (ALG) intelligence out of middleboxes into application specific midcom agents. Midcom agents will be assumed to use midcom to control middlebox resources so as to permit applications to traverse a middlebox. The scope of the middleboxes is limited to NAT and firewall devices. This document defines SNMP managed midcom objects to control middlebox resources and justifies adapting SNMPv3 as the midcom protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-srisuresh-midcom-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-srisuresh-midcom-mib-00.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-srisuresh-midcom-mib-00.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: <2003-10-22183652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-srisuresh-midcom-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-srisuresh-midcom-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183652.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Oct 24 21:48:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08880 for ; Fri, 24 Oct 2003 21:48:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADDXC-0003m2-Ev for midcom-archive@odin.ietf.org; Fri, 24 Oct 2003 21:48:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P1m6AL014502 for midcom-archive@odin.ietf.org; Fri, 24 Oct 2003 21:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADDX7-0003lO-Ag; Fri, 24 Oct 2003 21:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADDWp-0003kC-26 for midcom@optimus.ietf.org; Fri, 24 Oct 2003 21:47:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08862 for ; Fri, 24 Oct 2003 21:47:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADDWm-0007QO-00 for midcom@ietf.org; Fri, 24 Oct 2003 21:47:40 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1ADDWl-0007QL-00 for midcom@ietf.org; Fri, 24 Oct 2003 21:47:39 -0400 Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9P1l8N01388 for ; Fri, 24 Oct 2003 18:47:08 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9P1l6r16166 for ; Fri, 24 Oct 2003 20:47:06 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Oct 2003 20:47:07 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578D86@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 24 Oct 2003 20:47:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39A99.E52B6ACC" Subject: [midcom] Updated MIDCOM MIB analysis document submitted Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39A99.E52B6ACC Content-Type: text/plain; charset="iso-8859-1" Hi all, I have submitted an updated version of the MIDCOM MIB analysis document. Until it becomes available in the repository, you can retrieve it from: http://home.comcast.net/~mary.barnes/IETF/draft-ietf-midcom-mib-analysis-01. txt So for folks that have been wondering why there are two individual MIDCOM MIB documents, the details are covered in the document, which identifies some of the fundamental issues that have come up during design team discussions. Feedback from the WG on the issues would be appreciated. The authors of the two MIBs (and other members of the design team) will be working to come up with a consolidated MIDCOM MIB once the issues are resolved, but WG views on the issues would help to influence the direction. Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 ------_=_NextPart_001_01C39A99.E52B6ACC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Updated MIDCOM MIB analysis document submitted

Hi all,

I have submitted an updated version of the MIDCOM MIB = analysis document.  Until it becomes available in the repository, = you can retrieve it from:

http://home.comcast.net/~mary.barnes/IETF/draft-ietf-m= idcom-mib-analysis-01.txt

So for folks that have been wondering why there are = two individual MIDCOM MIB documents, the details are covered in the = document, which identifies some of the fundamental issues that have = come up during design team discussions.  Feedback from the WG on = the issues would be appreciated.  The authors of the two MIBs (and = other members of the design team) will be working to come up with a = consolidated MIDCOM MIB once the issues are resolved, but WG views on = the issues would help to influence the direction.

Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com
972-684-5432


------_=_NextPart_001_01C39A99.E52B6ACC-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 27 16:54:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16558 for ; Mon, 27 Oct 2003 16:54:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFJP-0005hg-Ah for midcom-archive@odin.ietf.org; Mon, 27 Oct 2003 16:54:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RLs7X4021921 for midcom-archive@odin.ietf.org; Mon, 27 Oct 2003 16:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFJJ-0005h2-9I; Mon, 27 Oct 2003 16:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFIS-0005a8-9Y for midcom@optimus.ietf.org; Mon, 27 Oct 2003 16:53:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16237; Mon, 27 Oct 2003 16:52:55 -0500 (EST) Message-Id: <200310272152.QAA16237@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 16:52:55 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-06.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling Filename : draft-ietf-midcom-semantics-06.txt Pages : 65 Date : 2003-10-24 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-midcom-semantics-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171331.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Oct 27 17:11:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19681 for ; Mon, 27 Oct 2003 17:11:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFZw-0007kw-AQ for midcom-archive@odin.ietf.org; Mon, 27 Oct 2003 17:11:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RMBCiV029814 for midcom-archive@odin.ietf.org; Mon, 27 Oct 2003 17:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFZq-0007jW-NA; Mon, 27 Oct 2003 17:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFZI-0007Z2-TY for midcom@optimus.ietf.org; Mon, 27 Oct 2003 17:10:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19241; Mon, 27 Oct 2003 17:10:19 -0500 (EST) Message-Id: <200310272210.RAA19241@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 17:10:19 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-06.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling Filename : draft-ietf-midcom-semantics-06.txt Pages : 65 Date : 2003-10-24 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-midcom-semantics-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171331.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Oct 28 09:10:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21105 for ; Tue, 28 Oct 2003 09:10:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUXs-0000ED-LQ for midcom-archive@odin.ietf.org; Tue, 28 Oct 2003 09:10:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SEA4hQ000851 for midcom-archive@odin.ietf.org; Tue, 28 Oct 2003 09:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUXp-0000Cz-Ld; Tue, 28 Oct 2003 09:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUX7-0008Rn-L5 for midcom@optimus.ietf.org; Tue, 28 Oct 2003 09:09:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20905 for ; Tue, 28 Oct 2003 09:09:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUX5-0003Cu-00 for midcom@ietf.org; Tue, 28 Oct 2003 09:09:15 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AEUWx-0003Ca-00 for midcom@ietf.org; Tue, 28 Oct 2003 09:09:08 -0500 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2003 15:06:29 +0100 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9SE8Viw009089 for ; Tue, 28 Oct 2003 06:08:32 -0800 (PST) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANP13457; Tue, 28 Oct 2003 06:08:31 -0800 (PST) Date: Tue, 28 Oct 2003 09:08:29 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <34A1EA66-0950-11D8-8EB9-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [midcom] midcom agenda for IETF 58 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here's the proposed agenda for the upcoming IETF meeting. The discussion of the current MIB work will constitute the bulk of the meeting. Note that while there are currently two MIB drafts, they are not competitive with each other. The MIB team will be working from both of them, and what this means in practice will be discussed in Minneapolis and can be discussed here, as well. > Middlebox Communication WG (midcom) > > Tuesday, November 11 at 15:45-16:45 > ================================ > > CHAIR: Melinda Shore > > Agenda-bashing > > Status update > Semantics document > Protocol evaluation > > MIB work > draft-ietf-midcom-mib-analysis-01.txt > draft-srisuresh-midcom-mib-01.txt > draft-stiemerling-midcom-mib-00.txt > > Wrap-up > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Oct 28 09:16:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21566 for ; Tue, 28 Oct 2003 09:16:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUdj-000171-Ah for midcom-archive@odin.ietf.org; Tue, 28 Oct 2003 09:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SEG7pc004258 for midcom-archive@odin.ietf.org; Tue, 28 Oct 2003 09:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUdg-00016I-Eg; Tue, 28 Oct 2003 09:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUdZ-00013d-CV for midcom@optimus.ietf.org; Tue, 28 Oct 2003 09:15:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21530; Tue, 28 Oct 2003 09:15:45 -0500 (EST) Message-Id: <200310281415.JAA21530@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 09:15:45 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-analysis-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communications (MIDCOM) Protocol Managed Objects Analysis Author(s) : M. Barnes Filename : draft-ietf-midcom-mib-analysis-01.txt Pages : 26 Date : 2003-10-27 This document provides an analysis and identification of the managed objects for dynamic configuration of middleboxes. The scope of the middleboxes to which these managed objects apply is limited to NATs and Firewalls. However, the managed objects as identified in this document are intended to provide a baseline for the dynamic configuration of other types of middleboxes. The applicability of existing Management Information Base (MIB) modules to the MIDCOM requirements, framework and semantics is described. Additional managed objects are identified to satisfy the entirety of the MIDCOM requirements, framework and semantics and to provide a complete MIDCOM MIB for NATs and Firewalls to fully realize the requirements of the MIDCOM protocol. The actual definition of any new managed objects is provided in a separate document [MDCMIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-analysis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-midcom-mib-analysis-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-midcom-mib-analysis-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: <2003-10-28093642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-mib-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-mib-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28093642.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Oct 28 09:22:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22572 for ; Tue, 28 Oct 2003 09:22:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUjU-0002Bx-3D for midcom-archive@odin.ietf.org; Tue, 28 Oct 2003 09:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SEM3O2008399 for midcom-archive@odin.ietf.org; Tue, 28 Oct 2003 09:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUjS-0002A2-8K; Tue, 28 Oct 2003 09:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUik-000269-HT for midcom@optimus.ietf.org; Tue, 28 Oct 2003 09:21:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22286; Tue, 28 Oct 2003 09:21:06 -0500 (EST) Message-Id: <200310281421.JAA22286@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 09:21:06 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-analysis-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communications (MIDCOM) Protocol Managed Objects Analysis Author(s) : M. Barnes Filename : draft-ietf-midcom-mib-analysis-01.txt Pages : 26 Date : 2003-10-27 This document provides an analysis and identification of the managed objects for dynamic configuration of middleboxes. The scope of the middleboxes to which these managed objects apply is limited to NATs and Firewalls. However, the managed objects as identified in this document are intended to provide a baseline for the dynamic configuration of other types of middleboxes. The applicability of existing Management Information Base (MIB) modules to the MIDCOM requirements, framework and semantics is described. Additional managed objects are identified to satisfy the entirety of the MIDCOM requirements, framework and semantics and to provide a complete MIDCOM MIB for NATs and Firewalls to fully realize the requirements of the MIDCOM protocol. The actual definition of any new managed objects is provided in a separate document [MDCMIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-analysis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-midcom-mib-analysis-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-midcom-mib-analysis-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: <2003-10-28094034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-mib-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-mib-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28094034.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 29 11:57:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18945 for ; Wed, 29 Oct 2003 11:57:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtd1-0008RT-Rd for midcom-archive@odin.ietf.org; Wed, 29 Oct 2003 11:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TGv3in032435 for midcom-archive@odin.ietf.org; Wed, 29 Oct 2003 11:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtd0-0008QS-Nd; Wed, 29 Oct 2003 11:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtcl-0008OP-9y for midcom@optimus.ietf.org; Wed, 29 Oct 2003 11:56:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18898 for ; Wed, 29 Oct 2003 11:56:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtck-0004tm-00 for midcom@ietf.org; Wed, 29 Oct 2003 11:56:46 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AEtcj-0004sj-00 for midcom@ietf.org; Wed, 29 Oct 2003 11:56:45 -0500 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2003 17:54:30 +0100 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9TGuYiw028993 for ; Wed, 29 Oct 2003 08:56:34 -0800 (PST) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANQ43757; Wed, 29 Oct 2003 08:56:33 -0800 (PST) Date: Wed, 29 Oct 2003 11:56:31 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [midcom] Semantics document Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The document has been submitted to the IESG for review for publication as an informational RFC. Many thanks to everybody who read the document and provided feedback, and special thanks to the document editors: Martin Stiemerling, Juergen Quittek, and Tom Taylor. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Oct 29 14:43:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00831 for ; Wed, 29 Oct 2003 14:43:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwDl-0002gS-4Y for midcom-archive@odin.ietf.org; Wed, 29 Oct 2003 14:43:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TJh9D3010116 for midcom-archive@odin.ietf.org; Wed, 29 Oct 2003 14:43:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwDc-0002Yh-LL; Wed, 29 Oct 2003 14:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwCf-0002HZ-EV for midcom@optimus.ietf.org; Wed, 29 Oct 2003 14:42:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00652 for ; Wed, 29 Oct 2003 14:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwCc-0001al-00 for midcom@ietf.org; Wed, 29 Oct 2003 14:41:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEwCc-0001aN-00 for midcom@ietf.org; Wed, 29 Oct 2003 14:41:58 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 29 Oct 2003 11:41:39 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9TJfQQY005491 for ; Wed, 29 Oct 2003 11:41:26 -0800 (PST) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANQ69836; Wed, 29 Oct 2003 11:41:25 -0800 (PST) Date: Wed, 29 Oct 2003 14:41:23 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [midcom] Fwd: permanent home for ietf text conferencing Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As many of you know, the IETF has been experimenting with using Jabber-based text conferencing during meetings as a way of allowing remote participation. It's been a success and so there's now a permanent home for the chats (and their logs). I hope to be able to find a volunteer for the upcoming meeting to act as a scribe, which basically entails typing in what's going on in the room at the time and letting us know if a remote participant has a question. If it's well-done I've found that it can be an excellent basis for meeting minutes. I've appended the server information. Melinda Begin forwarded message: > From: Marshall Rose > Date: Wed Oct 29, 2003 1:38:59 PM US/Eastern > To: IETF-Announce: ; > Subject: permanent home for ietf text conferencing > > http://www.xmpp.org/ietf-chat.html > > rather than having to deal with setting up a server prior to each > IETF, > there is now a permanent, year-round server set-up. > > please go to the above URL to see the instructions, etc. > > any questions, let me know. > > thanks, > > /mtr > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom