From midcom-admin@ietf.org Thu Mar 1 07:36:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01483 for ; Thu, 1 Mar 2001 07:36:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19609; Thu, 1 Mar 2001 07:21:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19576 for ; Thu, 1 Mar 2001 07:21:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01027; Thu, 1 Mar 2001 07:21:41 -0500 (EST) Message-Id: <200103011221.HAA01027@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, 01 Mar 2001 07:21:41 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-requirements-00.txt,.ps Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --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 : Requirements for the MIDCOM architecture and control language Author(s) : R. Swale et al. Filename : draft-ietf-midcom-requirements-00.txt,.ps Pages : 12 Date : 28-Feb-01 This document presents the requirements for the MIDCOM Architecture and the associated control language. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-00.txt 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-requirements-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-ietf-midcom-requirements-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: <20010228150334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010228150334.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 1 13:45:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16474 for ; Thu, 1 Mar 2001 13:45:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26151; Thu, 1 Mar 2001 13:37:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26121 for ; Thu, 1 Mar 2001 13:37:56 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15919 for ; Thu, 1 Mar 2001 13:37:55 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA09442 for ; Thu, 1 Mar 2001 10:37:44 -0800 (PST) Received: from spandex (rtp-vpn-87.cisco.com [10.82.192.87]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AFV57713; Thu, 1 Mar 2001 10:37:06 -0800 (PST) Message-ID: <03e101c0a27e$db885d60$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Thu, 1 Mar 2001 13:38:48 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Drafts out Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit By now you should have received notice that the requirements drafts is available. That means that drafts of both documents are now available. Note that there are substantial differences between them and that you may disagree with both - let the games begin! Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 1 21:21:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01883 for ; Thu, 1 Mar 2001 21:21:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03379; Thu, 1 Mar 2001 21:06:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03351 for ; Thu, 1 Mar 2001 21:06:13 -0500 (EST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01466 for ; Thu, 1 Mar 2001 21:06:10 -0500 (EST) Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with ESMTP id CAA28566 for ; Fri, 2 Mar 2001 02:06:10 GMT Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Mar 2001 18:06:09 -0800 Message-ID: <4148FEAAD879D311AC5700A0C969E8904E959B@orsmsx35.jf.intel.com> From: "Hegde, Shriharsha" To: midcom@ietf.org Date: Thu, 1 Mar 2001 18:06:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A2BD.58360E61" Subject: [midcom] FW: I-D ACTION:draft-hegde-load-balancing-pib-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_000_01C0A2BD.58360E61 Content-Type: text/plain; charset="iso-8859-1" Hi, This internet draft is a PIB for configuring/managing a load balancer using COPS-PR protocol. I understand that this draft does not fit in MIDCOM right now, but the PIB and COPS approach could be used in some parts of the MIDCOM framework. regards, harsha -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 28, 2001 3:57 AM Subject: I-D ACTION:draft-hegde-load-balancing-pib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Load Balancing Policy Information Base Author(s) : H. Hegde, B. Stone Filename : draft-hegde-load-balancing-pib-00.txt Pages : 17 Date : 27-Feb-01 This document specifies a set of provisioning classes (PRC) for configuring load balancing at load balancing devices. Instances of these classes reside in a virtual information store called Load Balancing Policy Information Base (PIB). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hegde-load-balancing-pib-00.txt 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-hegde-load-balancing-pib-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-hegde-load-balancing-pib-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_000_01C0A2BD.58360E61 Content-Type: message/rfc822 To: Subject: Date: Thu, 1 Mar 2001 18:06:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0A2BD.58360E61" ------_=_NextPart_002_01C0A2BD.58360E61 Content-Type: text/plain ------_=_NextPart_002_01C0A2BD.58360E61 Content-Type: application/octet-stream; name="ATT35283" Content-Disposition: attachment; filename="ATT35283" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010227123658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hegde-load-balancing-pib-00.txt ------_=_NextPart_002_01C0A2BD.58360E61 Content-Type: message/external-body; site="internet-drafts"; dir="draft-hegde-load-balancing-pib-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0A2BD.58360E61-- ------_=_NextPart_000_01C0A2BD.58360E61-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Mar 6 08:56:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11856 for ; Tue, 6 Mar 2001 08:56:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00498; Tue, 6 Mar 2001 08:38:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00469 for ; Tue, 6 Mar 2001 08:38:46 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11279 for ; Tue, 6 Mar 2001 08:38:44 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA18934 for ; Tue, 6 Mar 2001 05:38:34 -0800 (PST) Received: from spandex (rtp-vpn-61.cisco.com [10.82.192.61]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AGH03875; Tue, 6 Mar 2001 05:38:13 -0800 (PST) Message-ID: <01b701c0a642$f097b3a0$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Tue, 6 Mar 2001 08:39:59 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Issues Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Greetings from snowy Ithaca, I'll be sending in the agenda this afternoon, but it's really very simple - we have the first drafts of our two documents (framework and requirements) and differences/conflicts between them must be resolved. If there is material that you disagree with that needs to be addressed as well. I'm making my own list, but I hope that people are going through these documents on their own in preparation for the meeting. It would be particularly useful if any questions/issues/ comments/etc. could be raised on the mailing list prior to the meeting. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 9 19:20:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11712 for ; Fri, 9 Mar 2001 19:20:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04902; Fri, 9 Mar 2001 19:08:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04871 for ; Fri, 9 Mar 2001 19:08:01 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11462 for ; Fri, 9 Mar 2001 19:07:55 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA18518 for ; Fri, 9 Mar 2001 16:07:30 -0800 (PST) Received: from localhost.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id AIA17512; Fri, 9 Mar 2001 16:07:25 -0800 (PST) Received: by localhost.cisco.com (Postfix, from userid 500) id 968644816D; Fri, 9 Mar 2001 19:07:24 -0500 (EST) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.91 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15017.28727.673779.865252@localhost.localdomain> Date: Fri, 9 Mar 2001 19:07:19 -0500 To: midcom@ietf.org Content-Transfer-Encoding: 7bit Subject: [midcom] some comments on the framework draft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Suresh: The draft is a great start but needs some cleaning up. I have an immediate fairly small question and then I'll mention just the big issues. There are lots more smaller ones where these came from :-). You say: ALGs are different from proxies, in that, ALGs are transparent to end hosts, unlike the proxies. Proxies terminate sessions with both end-hosts. ALGs, on the other hand, do not terminate session with either end-host. Instead, proxies examine and optionally modify application payload content to facilitate the flow of application traffic through a middlebox. The objective of an ALG is to assist middleboxes in carrying out their function. Whereas, the objective of a proxy is to act as a relay agent between application clients and servers. I want to be sure about the sentence beginning on the 4th line. Where you say "Instead, proxies", do you mean "Instead, ALGs"? OK, now to some comments ... * I don't think proxies as described above should be in this architecture at all. A proxy, as described above, terminates connections from clients and originates new sessions on their behalf. They might modify content, but they are not modifying packets, they are generating new packets. In essence, from the point of view of midcom agents and middleboxes, proxies are clients. Just as with any other client, a proxy might have a midcom agent closely associated with it, even sharing the same CPU. Given the concept of proxy as described in this framework, from the point of view of midcom there is nothing that distinguishes a proxy from any other client. Let's treat them as such. Note that something which "proxies" only the signaling session is probably best classified as a kind of agent. Also note that the use of proxy here is very different from the use of "proxy" in SOCKS, which is fine -- I think we have a better definition. * "ALG" is a midcom agent function. "An ALG" is not an entity in and of itself. As you say, "MIDCOM agents are entities performing ALG function external to a middlebox" -- i.e. midcom agents have an ALG function, by definition. An agent exercises application intelligence, and if it's not exercising that application intelligence, then it's not an agent. Therefore, I think you should eliminate the big section on ALGs and describe the ALG function under "agent". Where you describe the difference between the ALG function and proxy function, compare and contrast proxies and agents instead. * > The policy server must determine trust guidelines for controlling > middleboxes according to the level of (presumed) security of the > host making the request. First, this should also be per-function. Second, which policies are per-client and which are per-agent? We need to poke into the security model in more detail once we have our concepts down. See you soon ... Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Mar 11 20:59:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16644 for ; Sun, 11 Mar 2001 20:59:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16423; Sun, 11 Mar 2001 20:50:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16394 for ; Sun, 11 Mar 2001 20:50:49 -0500 (EST) Received: from web1406.mail.yahoo.com (web1406.mail.yahoo.com [128.11.23.170]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16618 for ; Sun, 11 Mar 2001 20:50:47 -0500 (EST) Received: (qmail 20658 invoked by uid 60001); 12 Mar 2001 01:50:48 -0000 Message-ID: <20010312015048.20657.qmail@web1406.mail.yahoo.com> Received: from [63.116.202.66] by web1406.mail.yahoo.com; Sun, 11 Mar 2001 17:50:48 PST Date: Sun, 11 Mar 2001 17:50:48 -0800 (PST) From: Pyda Srisuresh Subject: Re: [midcom] some comments on the framework draft To: Scott Brim , midcom@ietf.org In-Reply-To: <15017.28727.673779.865252@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Scott Brim wrote: > Suresh: The draft is a great start but needs some cleaning up. I have > an immediate fairly small question and then I'll mention just the big > issues. There are lots more smaller ones where these came from :-). > Thanks, Scott. My comments below. > You say: > > ALGs are different from proxies, in that, ALGs are transparent to > end hosts, unlike the proxies. Proxies terminate sessions with > both end-hosts. ALGs, on the other hand, do not terminate session > with either end-host. Instead, proxies examine and optionally > modify application payload content to facilitate the flow of > application traffic through a middlebox. The objective of > an ALG is to assist middleboxes in carrying out their function. > Whereas, the objective of a proxy is to act as a relay agent > between application clients and servers. > > I want to be sure about the sentence beginning on the 4th line. Where > you say "Instead, proxies", do you mean "Instead, ALGs"? Yes. Sorry about the typo. > > OK, now to some comments ... > > * I don't think proxies as described above should be in this > architecture at all. A proxy, as described above, terminates > connections from clients and originates new sessions on their behalf. > They might modify content, but they are not modifying packets, they > are generating new packets. In essence, from the point of view of > midcom agents and middleboxes, proxies are clients. Just as with any > other client, a proxy might have a midcom agent closely associated > with it, even sharing the same CPU. Given the concept of proxy as > described in this framework, from the point of view of midcom there is > nothing that distinguishes a proxy from any other client. Let's treat > them as such. Note that something which "proxies" only the signaling > session is probably best classified as a kind of agent. Also note > that the use of proxy here is very different from the use of "proxy" > in SOCKS, which is fine -- I think we have a better definition. > Scott - I believe, it is useful to make the distinction between proxy and and end-host. > * "ALG" is a midcom agent function. "An ALG" is not an entity in and of > itself. As you say, "MIDCOM agents are entities performing ALG > function external to a middlebox" -- i.e. midcom agents have an ALG > function, by definition. An agent exercises application intelligence, > and if it's not exercising that application intelligence, then it's > not an agent. Therefore, I think you should eliminate the big > section on ALGs and describe the ALG function under "agent". Where > you describe the difference between the ALG function and proxy > function, compare and contrast proxies and agents instead. > It is important to preserve the distinction between ALGs and "MIDCOM agents" because ALGs can exist on a middlebox (as they do today) and neednt be present just on the MIDCOM agents. > * > The policy server must determine trust guidelines for controlling > > middleboxes according to the level of (presumed) security of the > > host making the request. > > First, this should also be per-function. Second, which policies are > per-client and which are per-agent? We need to poke into the security > model in more detail once we have our concepts down. > I believe, this is covered in some detail in section 5.1. > > See you soon ... Scott > Sure. regards, suresh ===== __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Mar 14 16:00:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04188 for ; Wed, 14 Mar 2001 16:00:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04672; Wed, 14 Mar 2001 15:44:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04641 for ; Wed, 14 Mar 2001 15:44:55 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03900 for ; Wed, 14 Mar 2001 15:44:53 -0500 (EST) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GA7006C7G9GQD@firewall.mcit.com> for midcom@ietf.org; Wed, 14 Mar 2001 20:44:04 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0GA700601G96TZ@dgismtp04.wcomnet.com>; Wed, 14 Mar 2001 20:44:02 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GA700601G7XHF@dgismtp04.wcomnet.com>; Wed, 14 Mar 2001 20:43:53 +0000 (GMT) Received: from Steveb1 ([166.44.244.85]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GA700550G6HI3@dgismtp04.wcomnet.com>; Wed, 14 Mar 2001 20:42:55 +0000 (GMT) Date: Wed, 14 Mar 2001 14:42:13 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] some comments on the framework draft In-reply-to: <20010312015048.20657.qmail@web1406.mail.yahoo.com> To: "'Pyda Srisuresh'" , "'Scott Brim'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <002001c0acc7$40a37f20$29e023a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit comments inline > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Pyda Srisuresh > Sent: Sunday, March 11, 2001 7:51 PM > To: Scott Brim; midcom@ietf.org > Subject: Re: [midcom] some comments on the framework draft > > > > --- Scott Brim wrote: > > Suresh: The draft is a great start but needs some cleaning > up. I have > > an immediate fairly small question and then I'll mention > just the big > > issues. There are lots more smaller ones where these came from :-). > > > Thanks, Scott. My comments below. > > > You say: > > > > ALGs are different from proxies, in that, ALGs are transparent to > > end hosts, unlike the proxies. Proxies terminate sessions with > > both end-hosts. ALGs, on the other hand, do not terminate session > > with either end-host. Instead, proxies examine and optionally > > modify application payload content to facilitate the flow of > > application traffic through a middlebox. The objective of > > an ALG is to assist middleboxes in carrying out their function. > > Whereas, the objective of a proxy is to act as a relay agent > > between application clients and servers. > > > > I want to be sure about the sentence beginning on the 4th > line. Where > > you say "Instead, proxies", do you mean "Instead, ALGs"? > > Yes. Sorry about the typo. > > > > > OK, now to some comments ... > > > > * I don't think proxies as described above should be in this > > architecture at all. A proxy, as described above, terminates > > connections from clients and originates new sessions on > their behalf. In the case of SIP this is half true, when compared to traditional firewall-like proxies. SIP proxies forward internal information in the form of via, record route, route, etc... in this case it is not truly only acting on behalf of the client, it is also revealing the internal path and topology, true proxies do not reveal this type of snesitive information. I believe that it is necessary to include proxy behavoir in order to address this aspect of SIP proxy behavoir. In this instance it may be better to utilize an ALG than a true proxy function when traversing firewalls, especially in the case of NAT. > > They might modify content, but they are not modifying > packets, they > > are generating new packets. In essence, from the point of view of > > midcom agents and middleboxes, proxies are clients. Just > as with any > > other client, a proxy might have a midcom agent closely associated > > with it, even sharing the same CPU. Given the concept of proxy as > > described in this framework, from the point of view of > midcom there is > > nothing that distinguishes a proxy from any other client. > Let's treat > > them as such. Note that something which "proxies" only > the signaling > > session is probably best classified as a kind of agent. Also note > > that the use of proxy here is very different from the use > of "proxy" > > in SOCKS, which is fine -- I think we have a better definition. > > > > Scott - I believe, it is useful to make the distinction > between proxy and > and end-host. > > > * "ALG" is a midcom agent function. "An ALG" is not an > entity in and of > > itself. As you say, "MIDCOM agents are entities performing ALG > > function external to a middlebox" -- i.e. midcom agents > have an ALG > > function, by definition. An agent exercises application > intelligence, > > and if it's not exercising that application intelligence, > then it's > > not an agent. Therefore, I think you should eliminate the big > > section on ALGs and describe the ALG function under > "agent". Where > > you describe the difference between the ALG function and proxy > > function, compare and contrast proxies and agents instead. > > > > It is important to preserve the distinction between ALGs > and "MIDCOM agents" because ALGs can exist on a middlebox (as they > do today) and neednt be present just on the MIDCOM agents. > > > * > The policy server must determine trust guidelines for > controlling > > > middleboxes according to the level of (presumed) > security of the > > > host making the request. > > > > First, this should also be per-function. Second, which > policies are > > per-client and which are per-agent? We need to poke into > the security > > model in more detail once we have our concepts down. > > > > I believe, this is covered in some detail in section 5.1. > > > > > See you soon ... Scott > > > Sure. > > regards, > suresh > > > ===== > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Auctions - Buy the things you want at great prices. > http://auctions.yahoo.com/ > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Mar 14 17:08:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05492 for ; Wed, 14 Mar 2001 17:08:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05739; Wed, 14 Mar 2001 16:59:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05710 for ; Wed, 14 Mar 2001 16:59:41 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05343 for ; Wed, 14 Mar 2001 16:59:38 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA11439; Wed, 14 Mar 2001 13:59:13 -0800 (PST) Received: from spandex (rtp-vpn-140.cisco.com [10.82.192.140]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AAO04249; Wed, 14 Mar 2001 13:59:06 -0800 (PST) Message-ID: <029901c0acd2$400bd200$d45904d1@cisco.com> From: "Melinda Shore" To: , "'Pyda Srisuresh'" , "'Scott Brim'" , References: <002001c0acc7$40a37f20$29e023a6@mcit.com> Subject: Re: [midcom] some comments on the framework draft Date: Wed, 14 Mar 2001 17:00:57 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > > > * I don't think proxies as described above should be in this > > > architecture at all. A proxy, as described above, terminates > > > connections from clients and originates new sessions on > > their behalf. > In the case of SIP this is half true, when compared to traditional > firewall-like proxies. SIP proxies forward internal information in the form > of via, record route, route, etc... in this case it is not truly only acting > on behalf of the client, it is also revealing the internal path and > topology, true proxies do not reveal this type of snesitive information. I > believe that it is necessary to include proxy behavoir in order to address > this aspect of SIP proxy behavoir. In this instance it may be better to > utilize an ALG than a true proxy function when traversing firewalls, > especially in the case of NAT. The use of the word "proxy" to describe what's evolved into a call control/mediation function in SIP has, I think, introduced some muddle around the word "proxy" and we need to get that cleaned up and nailed down. I believe that you and Scott are talking about two different things - a SIP proxy is much more than a relay. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Mar 14 17:11:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05539 for ; Wed, 14 Mar 2001 17:11:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05699; Wed, 14 Mar 2001 16:59:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05668 for ; Wed, 14 Mar 2001 16:59:23 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05340 for ; Wed, 14 Mar 2001 16:59:21 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA10675 for ; Wed, 14 Mar 2001 13:59:10 -0800 (PST) Received: from localhost.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id AIC18322; Wed, 14 Mar 2001 13:58:50 -0800 (PST) Received: by localhost.cisco.com (Postfix, from userid 500) id EF0D24818D; Wed, 14 Mar 2001 16:58:48 -0500 (EST) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.91 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15023.59800.343752.127211@localhost.localdomain> Date: Wed, 14 Mar 2001 16:58:48 -0500 To: midcom@ietf.org Subject: RE: [midcom] some comments on the framework draft In-Reply-To: <002001c0acc7$40a37f20$29e023a6@mcit.com> References: <20010312015048.20657.qmail@web1406.mail.yahoo.com> <002001c0acc7$40a37f20$29e023a6@mcit.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 14 Mar 2001 at 14:42 -0600, Christopher A. Martin apparently wrote: > > --- Scott Brim wrote: > > > * I don't think proxies as described above should be in this > > > architecture at all. A proxy, as described above, terminates > > > connections from clients and originates new sessions on > > their behalf. > In the case of SIP this is half true, when compared to traditional > firewall-like proxies. SIP proxies forward internal information in the form > of via, record route, route, etc... in this case it is not truly only acting > on behalf of the client, it is also revealing the internal path and > topology, true proxies do not reveal this type of snesitive information. I > believe that it is necessary to include proxy behavoir in order to address > this aspect of SIP proxy behavoir. In this instance it may be better to > utilize an ALG than a true proxy function when traversing firewalls, > especially in the case of NAT. I believe we're in agreement. I think classic proxies are more like hosts acting on behalf of other hosts than anything with midcom intelligence, while those "proxies" which have more elaborate behavior, including signaling extra control information or separating signaling from data, are best thought of as a kind of agent. The difference between the types of "proxies" is clearly significant enough to make it worth splitting them in our model. Once you do that, dumb proxies are very close to hosts and (imho) worth separating from them only in passing mention. Whether the cleverer proxies are similar enough to the other midcom agents covered in the framework is an issue we can talk about later. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 15 10:09:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00851 for ; Thu, 15 Mar 2001 10:09:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26966; Thu, 15 Mar 2001 09:52:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26937 for ; Thu, 15 Mar 2001 09:52:49 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00578 for ; Thu, 15 Mar 2001 09:52:46 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id GAA04733 for ; Thu, 15 Mar 2001 06:52:22 -0800 (PST) Received: from spandex (rtp-vpn-92.cisco.com [10.82.192.92]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AAQ06829; Thu, 15 Mar 2001 06:52:17 -0800 (PST) Message-ID: <01d401c0ad5f$ca8fe460$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Thu, 15 Mar 2001 09:54:08 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Fw: (NAT) draft-ietf-nat-natmib-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit FYI. Melinda ----- Original Message ----- From: Rajiv Raghunarayan To: NAT-WG Sent: Thursday, March 15, 2001 9:26 AM Subject: (NAT) draft-ietf-nat-natmib-00.txt > Hello Folks, > > We have recently submitted a draft on NAT MIB, which can be > accessed at > http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-00.txt > > We would appreciate your feedback/comments/questions on it, so we > can work on improving it, as may be necessary. > > Thanks and Regards, > Rajiv. > - > To unsubscribe, email 'majordomo@portmasters.com' with > 'unsubscribe nat' in the body of the message. > List archive: _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 22 19:41:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27843 for ; Thu, 22 Mar 2001 19:41:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01474; Thu, 22 Mar 2001 19:29:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01449 for ; Thu, 22 Mar 2001 19:29:54 -0500 (EST) Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27510 for ; Thu, 22 Mar 2001 19:29:52 -0500 (EST) Received: from fokus.gmd.de (pcp001020pcs.wireless.meeting.ietf.org [135.222.66.8]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with ESMTP id f2N0Tnt16808 for ; Thu, 22 Mar 2001 18:29:49 -0600 (CST) Message-ID: <3ABA98EF.33579FF5@fokus.gmd.de> Date: Fri, 23 Mar 2001 01:29:35 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Notion of Flow Direction Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi, let me kick the issue we put off-line during the meeting: direction of packet flows. I think there are cases in which a middlebox is happy to know expected direction of a flow. The question is whether the direction determination logic should reside 1) in the middlebox or 2) in midcom client and be communicated to middlebox via the midcom protocol. At least in SIP scenarios, the logic seems to lend itself to live in the middlebox: The middlebox operates on IP layer as opposed to a midcom client living in application space. And I would not prefer putting the burden of topological logic on applications. Can someone name a scenario in which it is desirable for the logic to live in a midcom client? Jiri _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 22 20:26:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29158 for ; Thu, 22 Mar 2001 20:26:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02191; Thu, 22 Mar 2001 20:16:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02163 for ; Thu, 22 Mar 2001 20:16:23 -0500 (EST) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28896 for ; Thu, 22 Mar 2001 20:16:21 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id D2BC58118 for ; Thu, 22 Mar 2001 19:13:25 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id TAA10990 for ; Thu, 22 Mar 2001 19:16:31 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 22 Mar 2001 19:16:31 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Notion of Flow Direction In-Reply-To: <3ABA98EF.33579FF5@fokus.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 23 Mar 2001, Jiri Kuthan wrote: > Hi, > > let me kick the issue we put off-line during the meeting: > direction of packet flows. > > I think there are cases in which a middlebox is happy to know > expected direction of a flow. > > The question is whether the direction determination logic should > reside 1) in the middlebox or 2) in midcom client and be communicated > to middlebox via the midcom protocol. I don't understand the question! > At least in SIP scenarios, the logic seems to lend itself to live in the > middlebox: The middlebox operates on IP layer as opposed to a midcom > client living in application space. And I would not prefer putting > the burden of topological logic on applications. There are at least two things going on here: the midcom client may or may not have a notion of which way the session initiation will happen (which end will send or receive the FIRST packet with a given 5-tuple) the middlebox may or may not a) care what the direction of session initiation is and/or b) have a way to enforce this direction. Let me invent a phrase: 'transport session', to denote a bunch of related packets with the same 5-tuple in either direction. This is synonymous with TCP connection if the packets happen to be TCP, and an RTP media stream also counts. If there's a better word, let me know? > Can someone name a scenario in which it is desirable for the logic to > live in a midcom client? In every scenario I have thought up the following is true: 1) the midcom client knows the direction in which every transport session it cares about will initiate. 2) NAT middleboxes care deeply about this information (NAT will not in general work without this information). 3) firewall middleboxes can enforce this transport-session-initiation-direction In some cases: 4) the midcom client has a firm idea of packet direction as well (e.g. RTP flows are unidirectional) 5) the middlebox can enforce this too I propose that directionality be a required element of the protocol, both for session initiation and for packet-flow. My experience is, to put it mildly, not universal, so certainly there may be cases where 1-3 do not obtain. The protocol should probably allow a "don't care" for direction, where applicable (not NAT). To be precise: - the protocol should allow the midcom client to specify the expected directions of both transport session initiation and packet flow, and allow values of 'don't care' and 'bidirectional' as valid directions (I guess 'bidirectionsl' makes no sense for transport session initiation direction?) - clients should send this information along to the extent that they know it - servers should parse and understand direction information, and require it where, well, required - middleboxes should enforce it, as far as they are capable of it Some scenarios in which directionality appears, expressed as operations desirable in MIDCOM protocol ("I" am a midcom client, "you" are a midcom server): a) I have an address/port off interface A of you, please give me an address/port good on interface B which will translate to the set I gave you. E.G. A phone "inside" at 192.168.1.22 is waiting for media at port 5000, I need a public address and a port I can stuff in the SIP invite which I send to a phone on the "outside." When the outside phone sends media to interfaces B bound to whatever the returned address/port is, the media packets get translated and sent out A to 192.168.1.22/5000. Outbound active FTP is isomorphic. b) I am expecting a TCP stream to come from some host at address X, to address Y, and these are the ports. Let it through. E.G. An H.245 stream from one entity to another. c) I am expecting a bunch of UDP packets from somewhere, I don't know where, going to this address and port. Let them in. E.G. SIP media (you know the destination, but not the source). In case a), you need to know that the session will initiate from the outside. NAT bindings MUST be attached to an interface, otherwise the NAT doesn't support overlapping addresses spaces. That is, if the binding was global to the box, and we were connecting two private networks both using 10.0.0.0, it would be easy to create ambiguous bindings. Which 10.0.1.92 did you mean? I have two of them! Aig! Note that it makes a lot of sense bind in both directions. Aravox (my employer) accordingly has implemented both 'bind local address to an "outside" address' and 'bind remote address to an "inside" address' to allow transport sessions to initiate in either direction and yet to still enjoy all the pleasures of dynamic NAT binding. With >2 interfaces, "remote" versus "local" becomes useless, but you still can speak of NAT bindings on a per interface level. In case b) it makes a LOT of sense to enforce the transport session initiation direction, and even cisco ACLs can do it, so I assume any device with pretensions of firewallhood can do it too. Without this enforcement, certain nasty attacks become possible: if you can fool something into a state in which it thinks something at some unknown address INSIDE is about to connect TO port X on OUTSIDE host Y (think H.245), and you don't enforce transport session initiation direction, you have just let host Y into your network, with total access. Ooo, but only if Y uses port X locally. Since Y probably picked X out, this is not a problem. In case c) we have both transport session initiation and actual packet flow direction (note that packet flow is either bidirection or agrees with the transport session initiation direction). It makes sense, if possible, to enforce this direction, just because, hey, the tighter you can screw things down, the better. Things get more amusing when you start to combine NAT with pinholing. Which of the 4 possible sets of addresses do you use for the pinholes? Whee! Was that helpful, or just very damn long? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 23 11:37:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23222 for ; Fri, 23 Mar 2001 11:37:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19245; Fri, 23 Mar 2001 11:25:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19214 for ; Fri, 23 Mar 2001 11:25:30 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22399 for ; Fri, 23 Mar 2001 11:25:28 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA28899; Fri, 23 Mar 2001 08:25:15 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2NGOrP10059; Fri, 23 Mar 2001 08:24:54 -0800 (PST) Message-ID: <3ABB78D5.79C918AF@cisco.com> Date: Fri, 23 Mar 2001 08:24:53 -0800 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Molitor CC: midcom@ietf.org Subject: Re: [midcom] Notion of Flow Direction References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Andrew, Here is the case I mentioned during the meeting. An internal server wants to receive flows (that is the word you were looking for, I think) from the outside (where outside is some place outside a domain). __________ _________ | |-----[DNS Query]-------->| | ___________ | external |<---[DNS Response]------<| N.S. | | | | host | |_________| | Internal | |__________| | Host | v |___________| v __________ v ^ v | |<--midcom -----/ ^ v | firewall | ^ \>>>Connection Attempt>>>>| / NAT |>>>>>>>>>>>>>>>>>>^ |__________| You'll note that I have not drawn arrows to the name server. That's because they can be drawn to and from the Internal Host or to and from the firewall/NAT. This boils down to whether you believe that communication is a midcom function or a NAT function. While the Internal Host initiates the midcom protocol in this case, someone else could do it on its behalf (like a MEGACO controller or some such). I've made the assumption that the midcom protocol would initiate from the Internal Host. This doesn't mean that it shouldn't be prepared to receive unsolicited midcom protocol messages thereafter (although I'm dubious of that). In this case, it is clear that two things MUST happen and two things may need to happen (the framework must support them): 1. The server or something acting on its behalf must alert the middle box that it is interested in such flows. 2. Somehow or another a DNS server must be told to return responses to the outside with valid information for that outside domain. 3. NAT forwarding bindings may need to be made. 4. Firewall pinholes may need to be opened. At *EACH* of these points the entities acting may need to query a policy server of some form. Note that it is conceivably possible that each of these would require some sort of protocol exchange. Regards, -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 23 17:19:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05142 for ; Fri, 23 Mar 2001 17:19:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23899; Fri, 23 Mar 2001 17:08:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23868 for ; Fri, 23 Mar 2001 17:08:13 -0500 (EST) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04993 for ; Fri, 23 Mar 2001 17:08:10 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 78B11818D for ; Fri, 23 Mar 2001 16:05:15 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA10651 for ; Fri, 23 Mar 2001 16:08:21 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 23 Mar 2001 16:08:21 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Notion of Flow Direction In-Reply-To: <3ABB78D5.79C918AF@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 23 Mar 2001, Eliot Lear wrote: > Andrew, > > Here is the case I mentioned during the meeting. > > An internal server wants to receive flows (that is the word you were > looking for, I think) from the outside (where outside is some place > outside a domain). > > __________ _________ > | |-----[DNS Query]-------->| | ___________ > | external |<---[DNS Response]------<| N.S. | | | > | host | |_________| | Internal | > |__________| | Host | > v |___________| > v __________ v ^ > v | |<--midcom -----/ ^ > v | firewall | ^ > \>>>Connection Attempt>>>>| / NAT |>>>>>>>>>>>>>>>>>>^ > |__________| > > > You'll note that I have not drawn arrows to the name server. That's > because they can be drawn to and from the Internal Host or to and from the > firewall/NAT. This boils down to whether you believe that communication > is a midcom function or a NAT function. While the Internal Host initiates > the midcom protocol in this case, someone else could do it on its behalf > (like a MEGACO controller or some such). > > I've made the assumption that the midcom protocol would initiate from the > Internal Host. This doesn't mean that it shouldn't be prepared to receive > unsolicited midcom protocol messages thereafter (although I'm dubious of > that). > > In this case, it is clear that two things MUST happen and two things may > need to happen (the framework must support them): > > 1. The server or something acting on its behalf must alert the middle box > that it is interested in such flows. > > 2. Somehow or another a DNS server must be told to return responses to > the outside with valid information for that outside domain. > > 3. NAT forwarding bindings may need to be made. > > 4. Firewall pinholes may need to be opened. I think this is all absolutely correct. The variations on the theme differ mostly in how frequently and how quickly these things happen. In the normal case, today, all these steps happen more or less once, and are done manually. For the "site web server" case, for example, we at Aravox use a proto-midcom protocol implemented over audio channels with commands like "John, I stuck this web server up at this address, can you stick something in the NAT and firewall so people can get it, and fix DNS too? Thanks, man." Obviously, it would simplify things if a web server could be simply configured with credentials and the address of a MIDCOM box, and it could self-configure the firewall every time it came up, or got a new address from DHCP. There are apparently some amazing DNS things that could make the DNS registrations happen at the same time, I know nothing of these things except that my guys say 'Oh yeah, something-something does that already, no problem!' so I know it's true. Of course, DNS is just one of many ways to publish a globally useful identifier people can use in well-formed requests of the form "Connect me to ." SIP and H.323 registrations are, from the right angle, isomorphic to DNS entries (obviously for the purposes of other discussions they are totally different -- here, I think they are basically the same). In the SIP version, things get even more complicated. Parts of 2 occur both before and after 1. In this case we replace DNS server with the SIP proxy's registrar function, and the server with a phone and the proxy part of the SIP proxy: 2a: The SIP proxy is told that a "potential" server exists inside at a phone (note that it IS NOT YET a server, since it's not currently listening for media). This potential server has a well defined identity like '651-256-2675' or 'amolitor@aravox.com' and some way of contacting it. 1. Upon instantiation of a phone call, in either direction, the proxy server alerts the middle box that the (now actual, not potential) server is interested in such flows (the actual media traffic). 2b. The SIP proxy server (registrar function, more or less?) returns information to the outside world about the server, per the results of step 1 (the NAT binding) 3. The NAT bindings are made (in practical terms, they're probably made in step 1, but they COULD be computed for use in step 1, and then activated here) 4. Firewall pinholes are opened. I think the issue of advertising higher level names (URLs, phone numbers, etc etc) is well outside the scope of MIDCOM. The essential common theme is, I think: - infrastructure always has a binding of some externally useful "high level" name (URLs, E.164 address etc) to a private IP address/port. - MIDCOM must provide a way to bind, dynamically, an externally useful IP address/port to internal IP address/port - thereby producing, by transitivity, a binding of the high level name to the externally useful IP address/port > At *EACH* of these points the entities acting may need to query a policy > server of some form. I agree, at least with the 'may' caveat. It might be fair to say that 3 doesn't really need further policy decision, on the grounds that this decision has been made in steps 1 and 2. That's just in aid of simplifying the model without, in practical terms, losing functionality. From where I sit, there are two big policy decisions: 1) does that entity have the right to advertise/publish this high level name? 2) does that entity have the right to these NAT bindings and firewall pinholes? The first is out of scope. The second is at least related to the scope of MIDCOM. We don't have to solve it, simply ensure that reasonable solutions are not precluded by some accidental stupid thing in MIDCOM. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Mar 24 04:55:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29383 for ; Sat, 24 Mar 2001 04:55:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06862; Sat, 24 Mar 2001 04:46:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06831 for ; Sat, 24 Mar 2001 04:46:31 -0500 (EST) Received: from exchange_03.2wire.com (exchange_03 [63.203.253.73] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29279 for ; Sat, 24 Mar 2001 04:46:28 -0500 (EST) Received: by exchange.2wire.com with Internet Mail Service (5.5.2650.21) id ; Sat, 24 Mar 2001 01:46:38 -0800 Message-ID: <91CDB24C5FCDD31198A2009027E7902102AA2774@exchange.2wire.com> From: Randy Turner To: Andrew Molitor , midcom@ietf.org Subject: RE: [midcom] Notion of Flow Direction Date: Sat, 24 Mar 2001 01:46:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Regarding the missing line from internal host to name server, the internal host could automatically update the name server using dynamic DNS (DDNS), with security (DNSSEC). Within this same zone update, the internal host could include SRV records indicating port number info as well. But the SRV stuff would not strictly be necessary for the external host to "find" it on the network. Randy -----Original Message----- From: Andrew Molitor [mailto:amolitor@visi.com] Sent: Friday, March 23, 2001 2:08 PM To: midcom@ietf.org Subject: Re: [midcom] Notion of Flow Direction On Fri, 23 Mar 2001, Eliot Lear wrote: > Andrew, > > Here is the case I mentioned during the meeting. > > An internal server wants to receive flows (that is the word you were > looking for, I think) from the outside (where outside is some place > outside a domain). > > __________ _________ > | |-----[DNS Query]-------->| | ___________ > | external |<---[DNS Response]------<| N.S. | | | > | host | |_________| | Internal | > |__________| | Host | > v |___________| > v __________ v ^ > v | |<--midcom -----/ ^ > v | firewall | ^ > \>>>Connection Attempt>>>>| / NAT |>>>>>>>>>>>>>>>>>>^ > |__________| > > > You'll note that I have not drawn arrows to the name server. That's > because they can be drawn to and from the Internal Host or to and from the > firewall/NAT. This boils down to whether you believe that communication > is a midcom function or a NAT function. While the Internal Host initiates > the midcom protocol in this case, someone else could do it on its behalf > (like a MEGACO controller or some such). > > I've made the assumption that the midcom protocol would initiate from the > Internal Host. This doesn't mean that it shouldn't be prepared to receive > unsolicited midcom protocol messages thereafter (although I'm dubious of > that). > > In this case, it is clear that two things MUST happen and two things may > need to happen (the framework must support them): > > 1. The server or something acting on its behalf must alert the middle box > that it is interested in such flows. > > 2. Somehow or another a DNS server must be told to return responses to > the outside with valid information for that outside domain. > > 3. NAT forwarding bindings may need to be made. > > 4. Firewall pinholes may need to be opened. I think this is all absolutely correct. The variations on the theme differ mostly in how frequently and how quickly these things happen. In the normal case, today, all these steps happen more or less once, and are done manually. For the "site web server" case, for example, we at Aravox use a proto-midcom protocol implemented over audio channels with commands like "John, I stuck this web server up at this address, can you stick something in the NAT and firewall so people can get it, and fix DNS too? Thanks, man." Obviously, it would simplify things if a web server could be simply configured with credentials and the address of a MIDCOM box, and it could self-configure the firewall every time it came up, or got a new address from DHCP. There are apparently some amazing DNS things that could make the DNS registrations happen at the same time, I know nothing of these things except that my guys say 'Oh yeah, something-something does that already, no problem!' so I know it's true. Of course, DNS is just one of many ways to publish a globally useful identifier people can use in well-formed requests of the form "Connect me to ." SIP and H.323 registrations are, from the right angle, isomorphic to DNS entries (obviously for the purposes of other discussions they are totally different -- here, I think they are basically the same). In the SIP version, things get even more complicated. Parts of 2 occur both before and after 1. In this case we replace DNS server with the SIP proxy's registrar function, and the server with a phone and the proxy part of the SIP proxy: 2a: The SIP proxy is told that a "potential" server exists inside at a phone (note that it IS NOT YET a server, since it's not currently listening for media). This potential server has a well defined identity like '651-256-2675' or 'amolitor@aravox.com' and some way of contacting it. 1. Upon instantiation of a phone call, in either direction, the proxy server alerts the middle box that the (now actual, not potential) server is interested in such flows (the actual media traffic). 2b. The SIP proxy server (registrar function, more or less?) returns information to the outside world about the server, per the results of step 1 (the NAT binding) 3. The NAT bindings are made (in practical terms, they're probably made in step 1, but they COULD be computed for use in step 1, and then activated here) 4. Firewall pinholes are opened. I think the issue of advertising higher level names (URLs, phone numbers, etc etc) is well outside the scope of MIDCOM. The essential common theme is, I think: - infrastructure always has a binding of some externally useful "high level" name (URLs, E.164 address etc) to a private IP address/port. - MIDCOM must provide a way to bind, dynamically, an externally useful IP address/port to internal IP address/port - thereby producing, by transitivity, a binding of the high level name to the externally useful IP address/port > At *EACH* of these points the entities acting may need to query a policy > server of some form. I agree, at least with the 'may' caveat. It might be fair to say that 3 doesn't really need further policy decision, on the grounds that this decision has been made in steps 1 and 2. That's just in aid of simplifying the model without, in practical terms, losing functionality. From where I sit, there are two big policy decisions: 1) does that entity have the right to advertise/publish this high level name? 2) does that entity have the right to these NAT bindings and firewall pinholes? The first is out of scope. The second is at least related to the scope of MIDCOM. We don't have to solve it, simply ensure that reasonable solutions are not precluded by some accidental stupid thing in MIDCOM. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Mar 24 08:30:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02363 for ; Sat, 24 Mar 2001 08:30:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08511; Sat, 24 Mar 2001 08:14:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08482 for ; Sat, 24 Mar 2001 08:14:53 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02135 for ; Sat, 24 Mar 2001 08:14:50 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA19902; Sat, 24 Mar 2001 05:14:41 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2ODEJl12768; Sat, 24 Mar 2001 05:14:19 -0800 (PST) Received: from NAUGA (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id FAA24329; Sat, 24 Mar 2001 05:14:18 -0800 (PST) Message-ID: <03ac01c0b464$32c95b00$d65904d1@NAUGA> From: "Melinda Shore" To: Cc: References: <3ABB78D5.79C918AF@cisco.com> Subject: Re: [midcom] Notion of Flow Direction Date: Sat, 24 Mar 2001 08:10:27 -0500 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > 2. Somehow or another a DNS server must be told to return responses to > the outside with valid information for that outside domain. Or some other kind of directory server - there are several ways to do this, and other ways that won't work at all. In the VoIP case we assume that 1) the terminal or user has registered with some sort of call control server and therefore the server knows where the endpoint is, 2) the call control server *is* visible to the rest the network, and 3) a calling party or its call control server has some way of finding the called party's call control server (and that may well *not* be DNS). It all kind of flows from there. Clearly some other sort of "call" establishment mechanisms need to be documented for simpler, more end-to-endish applications. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Mar 24 08:33:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02446 for ; Sat, 24 Mar 2001 08:33:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08557; Sat, 24 Mar 2001 08:20:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08526 for ; Sat, 24 Mar 2001 08:20:51 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02210 for ; Sat, 24 Mar 2001 08:20:49 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id FAA08045 for ; Sat, 24 Mar 2001 05:20:22 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2ODKKK13769 for ; Sat, 24 Mar 2001 05:20:20 -0800 (PST) Received: from NAUGA (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id FAA24639 for ; Sat, 24 Mar 2001 05:20:14 -0800 (PST) Message-ID: <03db01c0b465$06c3dd90$d65904d1@NAUGA> From: "Melinda Shore" To: Date: Sat, 24 Mar 2001 08:19:15 -0500 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Subject: [midcom] Fw: minutes Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I've appended Ted's meeting minutes. Please send any corrections, etc. to the mailing list. Once again, many thanks to Ted for taking this on. Melinda ----- Original Message ----- From: To: Cc: "Ted Hardie" Sent: Thursday, March 22, 2001 5:14 PM Subject: minutes > MIDCOM Meeting Minutes, 50th IETF > Chair: Melinda Shore > Minutes: Ted Hardie > March 22, 2001 > > Agenda: > > Agenda Bashing > Update on Working Group Status > Discussion of Framework Draft > Discussion of Requirements Draft > AOB > Agree on next steps. > > Resulting Action Items: > > Both sets of document authors will present new versions of their > drafts on the most aggressive schedule they can support. Those > documents will eliminate references to the functions inside the > middlebox and focus on the use of the midcom protocol. > > Members of the mailing list will send scenarios (use cases) for midcom > to the authors of the framework document, who will incorporate > appropriate scenarios into their document. Christian Huitema has > volunteered to compose scenarios for the document. > > No resolution was reached on the inconsistent usage of definitions > between the drafts; working members should propose specific text for > the definition to the mailing list, which will need to resolve the > inconsistencies. > > An interim meeting has been proposed in conjunction with the SIP > summit in Richardson, TX. The SIP meeting is May 1 & May 2nd, 2001. > The chair and ADs will discuss the scheduling of an interim meeting. > The interim meeting will be focused on eliminating any remaining > confusion on models, and attendees will be expected to volunteer to > produce text for working group documents based on the results. > > The Chair reminded the working group that early review and objection > was critical to meeting the time lines of the working group and urged > working group members to make objections known as early as possible. > > > Meeting Recap: > > The Chair began the meeting by saying that most important aim for the > morning was to work through the drafts and eliminate any conflicts > between them. She then began reviewing the status of the drafts. The > deadline for both in the current milestones is August 2001, but the > Chair hopes quicker progress can be made within the working group, in > order to incorporate potential delay time at the IESG review stage. > > The Chair then stated that the group needs to resolve some > definitions, both for the clarity of its own discussions and in order > to assist the IETF as a whole. Among the terms which need clear > definitions are: middlebox, proxy, Application Layer Gateway, and the > various participants in a Midcom protocol exchange. > > Pyda Srisuresh then presented the framework draft. > > The main goal for the draft is to create an architecture for > middleboxes needing to externalize application intelligence. That > framework should guide the development of the midcom protocol, with > especial guidance for the security necessary when connecting midcom > agents to middlebox. The architecture is restricted to firewalls and > NATs, in accordance with the group's charter, and it does not discuss > discovery. > > The architecture presumes that there is a single midcom protocol > interface, no matter what middlebox function or functions are in the > midbox (i.e., the same interface for firewalls and nats). The current > draft creates a taxonomy, however, for the midcom agents, dividing > in-path midcom agents and out-of path midcom agents. A great deal of > discussion from the floor challenged the distinction as written. > Christian Huitema asked that "enterprise boundary" be eliminated from > the description, as the use of "enterprise" might carry the wrong > implication to some readers; he suggested "domain" as a possible > replacement. It was suggested that a reference to Brian Carpenters > Middlebox taxonomy document would be useful in clarifying the > difference between in path and out-of path systems. Others felt that > the basic distinction was flawed, as the functions were the same > whether there were multiple boxes implementing those functions or > note. The draft author asked for further review of the draft and > asked for proposed language from those raising objections. The chair > indicated that further examples would be useful, especially for > out-of-path middlebox agents as the only example available appeared to > be the decomposed NAT, where the ALG functions are diverted to > external software processing boxes. > > A question on the floor asked for clarification between the > middleboxes treated in this draft and those examined in OPES; the > Chair responded that this is the transport layer, where OPES is > application layer. Michael Condry suggested that further language in > the draft to clarify which middle boxes are at issue would be useful. > The author agreed to add such language. > > Christian Huitema pointed out that SIP proxies are in path for SIP > messages, but out of path for media stream; he said that this seems to > create confusion in the application of the in-path midcom agents. > Author agreed to clarify that the signaling message path is meant in > the existing distinction. > > Christian asked whether outsourced agents for some of these > middleboxes would affect the architecture. In particular, he noted > you lose implicit knowledge of the path if you have something like a > sip proxy which may need to talk to firewalls in multiple exit points. > Chair noted that the discovery of which firewall is salient is out of > scope. Christian agreed that this was fine, but that there was a > design implication that the signaling cannot assume anything about > whether its messages will take the same path as the packet flows. > Author agreed that this was a design implication.. > > After further discussion of the distinctions among packet flows, the > AD asked to remember that we were not here to define the > characteristics of a middle box, but to design a communication system > to cope with them. Elements of the middlebox operation (like packet > diversion) are out of scope except as related to midcom protocol > signaling. > > Christian then indicated his belief that the confusion around some of > these issues derived from the draft's never making clear the > fundamental requirement of midcom, that we need a mechanism for > allowing a client to open a tcp_listen in the presence of a NAT or a > firewall. > > The group then moved on to a discussion of the requirements draft, > presented by Richard Swale. He first noted that the document as > developed in parallel with the framework, so there have been some > cases in which the two have diverged in terminology and architecture. > > Discussion of the draft began with questions around the use of > specific terms, such as "application client" and "application server", > but moved quickly to a question of whether the draft serves the > purpose of a requirements document at all. In particular, it was > agreed that the document needs a set of scenarios or uses cases. The > AD (Scott Bradner) noted that the draft contains descriptions of the > middlebox functions which are valuable, but not appropriate for this > draft. He asked that this draft focus more specifically on > communication *to* the middlebox rather than the function within it. > > It was proposed that the current requirements draft be abandoned and > the requirements should be redrafted with the caveat that the > requirements draft should use only terms that are in the framework > document, with a strong focus on service scenarios. The focus on > scenarios was strongly supported, but it was not clear that the draft > needed to be scrapped. > > After a suggestion from the floor that work on the requirements be > suspended until the framework is completed, it was agreed that the > working needed to work on both in parallel to achieve its milestones. > The Chair asked both sets of document authors to eliminate text in > their drafts that describes middlebox functioning unless that function > is explicitly related to the processing of midcom messages. > > The Chair then asked that as part of their re-write, both sets of > document author expand their security sections and examine the current > text, as she believes it not correct. > > Eliot then asserted that flow direction is creating a problem in our > understanding of these. He put forward an example derived from peer > to peer communication (Gnutella). Some device with a fully public IP > address A, initiates a communication with a device B, which is behind > a firewall. How does device B get a publically addressable IP/PORT in > order to be addressed by A? Scott Bradner asserted that a FQDN from a > two faced DNS is the external binding, so that the original message > goes to the client's inside address, at which point it requests an > outside address. > > After a complain from the floor that none of the scenarios were > written down in the drafts. Christian volunteered to writes > scenarios. He then went back to Eliot's case, noting the case of a > home network where an external port is mapped to an internal service; > he wants a common way to do that mapping as it is currently being done > in a proprietary way, using a very weak security model > (inside/outside). He believes we need scenarios and an inventory of > existing mechanisms (in use in home gateways, socks, etc.). Chair > rules the second out of scope. Agreement among volunteer, chair, and > AD on scenarios as use cases for the protocol, not of the middleboxes. > > Question from the floor about binding to ports; answer was that since > it is not related to midcom function, it is a not issue. In a > discussion about whether "inbound and outbound" do not have to be > separate, the Chair noted that you might have a midcom policy on a per > interface basis. After a further discussion of how complex the > interface mappings might be, the Chair indicated that in this problem > domain (firewalls and nats), that the inside/outside dual interface is > a reasonable description. You might not want to see it not in > interface terms, but in terms of source and destination address. > Andrew noted that this might not be sufficient if the charter is to > deal with what is actually out there, because there are firewalls that > have multiple interfaces and there are NATs that care deeply about who > session direction as well as interface direction. > > The Chair then concluded the meeting by reviewing the action items, > noted above. > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Mar 24 20:21:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15775 for ; Sat, 24 Mar 2001 20:21:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14620; Sat, 24 Mar 2001 19:56:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14593 for ; Sat, 24 Mar 2001 19:56:49 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15340 for ; Sat, 24 Mar 2001 19:56:47 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id QAA24840 for ; Sat, 24 Mar 2001 16:56:21 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2P0uHe10803 for ; Sat, 24 Mar 2001 16:56:17 -0800 (PST) Message-ID: <3ABD4231.96BE54EC@cisco.com> Date: Sat, 24 Mar 2001 16:56:17 -0800 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] on "diversion" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Do people need to be convinced that diversion is not necessary to discuss in ANY midcom work? -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Mar 25 00:43:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23501 for ; Sun, 25 Mar 2001 00:43:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17179; Sun, 25 Mar 2001 00:31:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17149 for ; Sun, 25 Mar 2001 00:31:41 -0500 (EST) Received: from exchange_03.2wire.com (exchange_03 [63.203.253.73] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23232 for ; Sun, 25 Mar 2001 00:31:34 -0500 (EST) Received: by exchange.2wire.com with Internet Mail Service (5.5.2650.21) id ; Sat, 24 Mar 2001 21:31:52 -0800 Message-ID: <91CDB24C5FCDD31198A2009027E79021011BD9CE@exchange.2wire.com> From: Randy Turner To: "'Eliot Lear '" , "'midcom@ietf.org '" Subject: RE: [midcom] on "diversion" Date: Sat, 24 Mar 2001 21:31:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At the plenary meeting of MIDCOM, I don't remember anyone actually "defining" what diversion meant. I think some folks thought just rewriting IP addresses meant diversion, while others seem to think that actually moving a packet to another entity, and then getting back a response, prior to forwarding (kinda like a remote ALG), was diversion. Can we agree on what diversion is before we decide if it's necessary. Thanks! Randy -----Original Message----- From: Eliot Lear To: midcom@ietf.org Sent: 3/24/01 4:56 PM Subject: [midcom] on "diversion" Do people need to be convinced that diversion is not necessary to discuss in ANY midcom work? -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Mar 25 03:15:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01388 for ; Sun, 25 Mar 2001 03:15:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25023; Sun, 25 Mar 2001 03:04:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24994 for ; Sun, 25 Mar 2001 03:04:42 -0500 (EST) Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09765 for ; Sun, 25 Mar 2001 03:04:35 -0500 (EST) Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81Bd8013083 for ; Sun, 25 Mar 2001 02:02:44 -0600 Message-Id: <200103250802.f2P81Bd8013083@sm10.texas.rr.com> X-Sender: hermag@excite.com From: "hermag@excite.com" To: midcom@ietf.org Date: Sun, 25 Mar 2001 01:59:26 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__18522311_7166.84" Subject: [midcom] Would you like to recieve information on how to register your pet online for free? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a Multipart MIME message. ------=_NextPart_000_001__18522311_7166.84 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__18522311_7166.84 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4 dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93 IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0 IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i b2R5Pg0KPC9odG1sPg0K ------=_NextPart_000_001__18522311_7166.84-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Mar 25 04:09:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07584 for ; Sun, 25 Mar 2001 04:09:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26069; Sun, 25 Mar 2001 03:58:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26038 for ; Sun, 25 Mar 2001 03:58:43 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06143 for ; Sun, 25 Mar 2001 03:58:42 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id AAA28467; Sun, 25 Mar 2001 00:56:56 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2P8wBY22940; Sun, 25 Mar 2001 00:58:11 -0800 (PST) Message-ID: <3ABDB471.1060307@cisco.com> Date: Sun, 25 Mar 2001 01:03:45 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0 i686; en-US; 0.8) Gecko/20010217 X-Accept-Language: en MIME-Version: 1.0 To: Randy Turner CC: midcom@ietf.org Subject: Re: [midcom] on "diversion" References: <91CDB24C5FCDD31198A2009027E79021011BD9CE@exchange.2wire.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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit To me, diversion means the following (the numbers next to the lines indicate the data flow): __________ | | | External | | Host | |__________| v | | |1 | | ___v______ 2 ______________ | |>---------->| | | NAT / | | Application | | Firewall |<----------<| Controller | |__________| 3 |______________| v | | |4 | | ___v______ | | | Internal | | Host | |__________| Although I indicate flow direction from external to internal, the opposite flow direction would also be considered a diversion. Note that (3) is optional. It's quite possible that the application controller could conceivably consume the flow in its entirety (like in the case of a transparent cache). Requiring this sort of capability, and even mentioning it, is a rathole. I'm not arguing that we should go out of our way to prevent it, but let's not go out of our way to do that either. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Mar 25 07:44:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13113 for ; Sun, 25 Mar 2001 07:44:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28189; Sun, 25 Mar 2001 07:38:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28158 for ; Sun, 25 Mar 2001 07:38:40 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12994 for ; Sun, 25 Mar 2001 07:38:37 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA09428; Sun, 25 Mar 2001 04:38:30 -0800 (PST) Received: from SBRIM-NT.cisco.com (rtp-vpn-35.cisco.com [10.82.192.35]) by airborne.cisco.com (Mirapoint) with ESMTP id AAD05011; Sun, 25 Mar 2001 04:38:06 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.91 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15037.59051.243000.874560@gargle.gargle.HOWL> Date: Sun, 25 Mar 2001 07:38:03 -0500 To: lear@cisco.com Cc: midcom@ietf.org Subject: Re: [midcom] on "diversion" In-Reply-To: <3ABD4231.96BE54EC@cisco.com> References: <3ABD4231.96BE54EC@cisco.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 24 Mar 2001 at 16:56 -0800, Eliot Lear apparently wrote: > Do people need to be convinced that diversion is not necessary to discuss > in ANY midcom work? It's certainly not in scope for requirements or protocol work. I like having it in the conceptual framework, just as we do e.g. simple proxies, just so we all have the same context. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Mar 26 03:53:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09786 for ; Mon, 26 Mar 2001 03:53:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17347; Mon, 26 Mar 2001 03:42:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17319 for ; Mon, 26 Mar 2001 03:42:28 -0500 (EST) Received: from exchange_03.2wire.com (exchange_03 [63.203.253.73] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08064 for ; Mon, 26 Mar 2001 03:42:23 -0500 (EST) Received: by exchange.2wire.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 00:42:46 -0800 Message-ID: <91CDB24C5FCDD31198A2009027E7902102AA2786@exchange.2wire.com> From: Randy Turner To: midcom@ietf.org Subject: RE: [midcom] on "diversion" Date: Mon, 26 Mar 2001 00:42:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Ok, I believe that's really what diversion means to me as well. If this is out-of-scope, then this leaves out the ability to "outboard" an ALG processor from the firewall/NAT device, which I guess is ok with me. (I"m assuming that we're on the same page with the definition of an ALG ;) Randy -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: Sunday, March 25, 2001 1:04 AM To: Randy Turner Cc: midcom@ietf.org Subject: Re: [midcom] on "diversion" To me, diversion means the following (the numbers next to the lines indicate the data flow): __________ | | | External | | Host | |__________| v | | |1 | | ___v______ 2 ______________ | |>---------->| | | NAT / | | Application | | Firewall |<----------<| Controller | |__________| 3 |______________| v | | |4 | | ___v______ | | | Internal | | Host | |__________| Although I indicate flow direction from external to internal, the opposite flow direction would also be considered a diversion. Note that (3) is optional. It's quite possible that the application controller could conceivably consume the flow in its entirety (like in the case of a transparent cache). Requiring this sort of capability, and even mentioning it, is a rathole. I'm not arguing that we should go out of our way to prevent it, but let's not go out of our way to do that either. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Mar 26 08:02:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12284 for ; Mon, 26 Mar 2001 08:02:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20573; Mon, 26 Mar 2001 07:54:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20544 for ; Mon, 26 Mar 2001 07:54:14 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10449 for ; Mon, 26 Mar 2001 07:54:13 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA29535; Mon, 26 Mar 2001 04:54:03 -0800 (PST) Received: from spandex (rtp-vpn-24.cisco.com [10.82.192.24]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AAC12018; Mon, 26 Mar 2001 04:53:39 -0800 (PST) Message-ID: <029201c0b5f4$0ec1bf40$d45904d1@cisco.com> From: "Melinda Shore" To: "Randy Turner" , References: <91CDB24C5FCDD31198A2009027E7902102AA2786@exchange.2wire.com> Subject: Re: [midcom] on "diversion" Date: Mon, 26 Mar 2001 07:55:38 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > Ok, I believe that's really what diversion means to me as well. > > If this is out-of-scope, then this leaves out the ability to "outboard" > an ALG processor from the firewall/NAT device, which I guess is ok with me. Actually, it doesn't - it just means that it wouldn't be done in midcom. Here's where I think we are with this: 1) a packet of "known" provenance or disposition arrives on a middlebox and is diverted to some sort of application or network proxy/ALG/auxiliary thing: definitely out of scope. 2) a packet of unknown provenance or disposition arrives on a middlebox and we don't know what to do with it: policy consultation to make a determination could be part of the policy component, but diverting the packet itself to some sort of application or network proxy/ ALG/auxiliary thing is definitely out of scope. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Mar 26 20:13:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23635 for ; Mon, 26 Mar 2001 20:13:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03994; Mon, 26 Mar 2001 19:53:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03961 for ; Mon, 26 Mar 2001 19:53:03 -0500 (EST) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23115 for ; Mon, 26 Mar 2001 19:53:03 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 19E968109 for ; Mon, 26 Mar 2001 17:35:14 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA00845 for ; Mon, 26 Mar 2001 17:36:27 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 26 Mar 2001 17:36:27 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [midcom] Protocol Requirements - Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Since the issue of what goes IN to a requirements document has been resolved to 'requirements for a middlebox control protocol' I will now trot out the bullet list of protocol requirements I have. Feel free to shoot at it. If/when I peceive rough consensus having been acheived, I will more carefully format and submit more formally to the editor. Throughout, I use this terminology: Client - something that requests pinholes pinholes and NAT bindings. For example, a MIDCOM aware ALG or SIP proxy. Server - something which is spoken to by a client. By implication, a Server resides in (logically, if not literally) a Middlebox, and exposes the services of that Middlebox to Clients. Middlebox - a firewall or NAT device which is coupled to a MIDCOM server, which offers the firewall/NAT services to Clients. Do we want to require a 1-to-1 relationship between Servers and Middleboxes? Protocol requirements in no particular order: General Stuff ============= - must operate over standard IP transports, UDP required, TCP optional. - should be transport independent, a la SIP. - must support high transaction throughput over highish latency networks (read: must support message streaming.) - must support one or more strong authentication models. - should support one or more privacy models (I am weak on this because, in general, not much you are saying is a big secret -- traffic flows will pretty much reveal the state of the box anyways) - must support client-to-server request/response transactions. - must support server-to-client informational messages (or transactions?) - must support models in which multiple clients talk to multiple servers. Specific Operations/Scenarios Note that these are protocol requirements, not box requirements. So, while the protocol must support the ability of a client to ask for a pinhole, the protocol also allows for a middlebox to return 'NO - I am a NAT, dummy.' - must support a client-to-server transaction which returns the middlebox capabilities to the client. These capabilities should include, but not be restricted to: - firewalling - NAT (including port translations) - QoS - Plumbing information (where does NAT fit relative to other elements, specifically, THIS MATTERS!) - must support a client-to-server transaction to open a "pinhole" in the middlebox's traffic policy. - must support a client-to-server transaction to request a NAT binding, associating an IP address/port pair on one interface with an IP address/port pair on another. - it would sure be nice if these binding requests could specify information about the expected source of the flow initiator. E.G. 'I have a server on the inside at 192.168.1.99 port 5000, and I think someone on the outside at address 209.46.41.61, I don't know the port' will be connecting to my server -- please give me an address/port I can advertise to the remote as the phone's address/port' - must support a method for mirroring an existing NAT binding allocated by one middlebox into another middlebox, for redundancy. There are a few ways to build this, I don't know or care how the protocol does it, but this capability must be supported. - must support a client-to-server transation to release an individual NAT binding. - must support a client-to-server transation to release an individual pinhole. - should support a way to identify bundles of state (pinholes and NAT) as belonging to the same group (a "session ID" specified by the client in a set of requests) - should support a client-to-server transaction to delete all the state bundled under a given session ID. - must support a way to specify a desired timeout value for and piece of state created by a client-to-server transaction. - should support both activity based timeouts as well as absolute timeouts (i.e. support both 'if you don't see any packets for 60 seconds, please make this NAT binding go away by itself' AND 'make this NAT binding go away in 60 seconds') - must support client-to-server transactions to query middlebox state, including but not restricted to: - currently installed pinholes - currently installed NAT bindings - statistics of various sorts - should support a client-to-server transation allowing the client to register to receive notifications of various sorts from the server. - should support some server-to-client transactions to inform the client of events such as: - timeouts of pinholes and NATs - violations of policy - other? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Mar 27 09:04:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18262 for ; Tue, 27 Mar 2001 09:04:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20947; Tue, 27 Mar 2001 08:52:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20917 for ; Tue, 27 Mar 2001 08:52:08 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18066 for ; Tue, 27 Mar 2001 08:52:08 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id FAA06543; Tue, 27 Mar 2001 05:51:36 -0800 (PST) Received: from spandex (rtp-vpn-51.cisco.com [10.82.192.51]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AAH24121; Tue, 27 Mar 2001 05:51:25 -0800 (PST) Message-ID: <02ad01c0b6c5$4bee60e0$d45904d1@cisco.com> From: "Melinda Shore" To: "Andrew Molitor" , References: Subject: Re: [midcom] Protocol Requirements - Date: Tue, 27 Mar 2001 08:53:25 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Quick notes: > - must operate over standard IP transports, UDP required, TCP > optional. Transport specification is an answer, not a question. i.e. we need to describe transport requirement characteristics. > - should support one or more privacy models (I am weak on this > because, in general, not much you are saying is a big > secret -- traffic flows will pretty much reveal the state > of the box anyways) To varying degrees. It's pretty common to do VPN termination on firewalls, and while you can infer a lot from tunnelled traffic characteristics at least the actual destination address itself is protected in the case where the VPN is encrypted. > - must support server-to-client informational messages (or > transactions?) "Transaction" implies that a response would be expected. We had talked about asynchronous alerts from the middlebox to the midcom client and agreed that it's necessary - can you describe a scenario in which you'd like a response back to the middlebox? > - must support a method for mirroring an existing NAT > binding allocated by one middlebox into another middlebox, > for redundancy. There are a few ways to build this, > I don't know or care how the protocol does it, but > this capability must be supported. I'm actually not convinced about that, but even so, a mechanism to do this that required communication among middleboxes is out of scope. A mechanism that made the client responsible for requesting a particular binding is not. Either way, how the address of the NAT itself is failed over is absolutely not our concern, yet if that's not done the question of transferring existing bindings is pretty much moot. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Mar 27 09:53:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18909 for ; Tue, 27 Mar 2001 09:53:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21911; Tue, 27 Mar 2001 09:44:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21882 for ; Tue, 27 Mar 2001 09:44:45 -0500 (EST) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18696 for ; Tue, 27 Mar 2001 09:44:45 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 04243811A for ; Tue, 27 Mar 2001 08:41:47 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id IAA04120 for ; Tue, 27 Mar 2001 08:44:56 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Tue, 27 Mar 2001 08:44:56 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Protocol Requirements - In-Reply-To: <02ad01c0b6c5$4bee60e0$d45904d1@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Tue, 27 Mar 2001, Melinda Shore wrote: > Quick notes: > > - must operate over standard IP transports, UDP required, TCP > > optional. > > Transport specification is an answer, not a question. i.e. > we need to describe transport requirement characteristics. Point taken. Is it fair to devise a maze of constraints which rule out everything except 'UDP, with a TCP option'? For a large number of fairly vague reasons which I would, if necessary, take the time to refine and write down, I think that any other transport description would be lunacy. I am, nontheless, happy to phrase the answer in the form of a requirement! > > - should support one or more privacy models (I am weak on this > > because, in general, not much you are saying is a big > > secret -- traffic flows will pretty much reveal the state > > of the box anyways) > > To varying degrees. It's pretty common to do VPN termination > on firewalls, and while you can infer a lot from tunnelled > traffic characteristics at least the actual destination > address itself is protected in the case where the VPN is > encrypted. What I meant was this: If I open a pinhole allowing traffic from A to B, the fact that I have will be obvious pretty soon, when A starts sending traffic to B. This is somewhat more trivial than VPN traffic analysis. Of course, I conveniently forgot NAT and the fact that people like to hide their private addresses when I wrote that. Again, point taken, and thanks. > > - must support server-to-client informational messages (or > > transactions?) > > "Transaction" implies that a response would be expected. > We had talked about asynchronous alerts from the middlebox > to the midcom client and agreed that it's necessary - can > you describe a scenario in which you'd like a response > back to the middlebox? I cannot. As a potential server-end MIDCOM implementor, I REALLY like the plan to send alerts optimistically into the void and hope for the best. > > - must support a method for mirroring an existing NAT > > binding allocated by one middlebox into another middlebox, > > for redundancy. There are a few ways to build this, > > I don't know or care how the protocol does it, but > > this capability must be supported. > > I'm actually not convinced about that, but even so, > a mechanism to do this that required communication > among middleboxes is out of scope. A mechanism that > made the client responsible for requesting a particular > binding is not. Either way, how the address of the > NAT itself is failed over is absolutely not our concern, > yet if that's not done the question of transferring > existing bindings is pretty much moot. I actually meant to indicate a mechanism whereby a client can do the heavy lifting. The point was that the MIDCOM protocol should support: - returning enough information to the client to allow a NAT binding to be installed on a parallel middlebox - a way to install said information on same The difficulty is that the Middlebox-NAT really needs to be allocating stuff (port numbers and whatnot) in the normal case. Otherwise the multiple-client case breaks entirely, and the clients have to do way too much computation and address/port space management. However, in the redundant middlebox case, the "spare" middlebox has to simply told what the other one did. Then, if all the clients agree which one is the primary and which one is the spare, we don't have Middlebox A and Middlebox B allocating the same IP address/port to two different things. This is actually a solution too. What is needed is a way, any way, to allow a bunch of clients to collectively keep a bunch of middleboxes all configured the same. The idea of middlebox-middlebox communications a) gives me the willies and b) doesn't solve the problem. You really need a single logical allocator of IP addresses and ports to avoid problems. Thanks much for your comments! _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Mar 27 10:42:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20389 for ; Tue, 27 Mar 2001 10:42:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22912; Tue, 27 Mar 2001 10:33:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22886 for ; Tue, 27 Mar 2001 10:33:22 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20114 for ; Tue, 27 Mar 2001 10:33:21 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA28634; Tue, 27 Mar 2001 07:32:55 -0800 (PST) Received: from spandex (rtp-vpn-51.cisco.com [10.82.192.51]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AAJ00561; Tue, 27 Mar 2001 07:32:50 -0800 (PST) Message-ID: <030801c0b6d3$76f50e20$d45904d1@cisco.com> From: "Melinda Shore" To: "Andrew Molitor" , References: Subject: Re: [midcom] Protocol Requirements - Date: Tue, 27 Mar 2001 10:34:49 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > Point taken. Is it fair to devise a maze of constraints > which rule out everything except 'UDP, with a TCP option'? For > a large number of fairly vague reasons which I would, if necessary, > take the time to refine and write down, I think that any other > transport description would be lunacy. Sorry! Presumably you've got reasons for preferring one transport over another, and it's those reasons that need to go into the requirements document. > I actually meant to indicate a mechanism whereby a client > can do the heavy lifting. The point was that the MIDCOM protocol > should support: > > - returning enough information to the client to allow a > NAT binding to be installed on a parallel middlebox > - a way to install said information on same I think that probably a properly-specified request primitive should be sufficient. A request can be sent to the NAT saying "gimme a binding," allowing the NAT to select the protocol/address/port tuple. The NAT would return a description of what was allocated. A request can also be sent to the NAT saying "gimme a binding, and I'd prefer that it use protocol/address/ port ," in response to which the NAT would return what it actually allocated. Similarly, a request could say "assign me and do nothing if it's not available." > The idea of middlebox-middlebox communications a) gives me > the willies and b) doesn't solve the problem. You really need > a single logical allocator of IP addresses and ports to avoid > problems. Think shared memory (but think it someplace else!). Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Mar 27 11:50:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22575 for ; Tue, 27 Mar 2001 11:50:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24261; Tue, 27 Mar 2001 11:45:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24230 for ; Tue, 27 Mar 2001 11:45:39 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22441 for ; Tue, 27 Mar 2001 11:45:38 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id LAA16887; Tue, 27 Mar 2001 11:45:27 -0500 (EST) Date: Tue, 27 Mar 2001 11:45:27 -0500 (EST) From: Scott Bradner Message-Id: <200103271645.LAA16887@newdev.harvard.edu> To: amolitor@visi.com, midcom@ietf.org Subject: Re: [midcom] Protocol Requirements - Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > Is it fair to devise a maze of constraints > which rule out everything except 'UDP, no if UDP is the answer based on realistic requirements then that is OK but please concentrate on real requirements not a devised maze of artificial ones and note that any UDP-based option has to deal with retries and congestion and must be conformant with RFC 2914 Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Mar 27 11:55:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22788 for ; Tue, 27 Mar 2001 11:55:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24186; Tue, 27 Mar 2001 11:42:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24159 for ; Tue, 27 Mar 2001 11:42:28 -0500 (EST) Received: from exchange_03.2wire.com (exchange_03 [63.203.253.73] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22368 for ; Tue, 27 Mar 2001 11:42:27 -0500 (EST) Received: by exchange.2wire.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Mar 2001 08:26:59 -0800 Message-ID: <91CDB24C5FCDD31198A2009027E79021011BD9D5@exchange.2wire.com> From: Randy Turner To: "'Andrew Molitor '" , "'midcom@ietf.org '" Subject: RE: [midcom] Protocol Requirements - Date: Tue, 27 Mar 2001 08:26:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Regarding the need for acknoledged receipt of asynchronous update messages from a middlebox to a client, I think this requirement depends upon how important it is for the client to absolutely know the current state of the middlebox. I wouldn't dismiss the requirement out of hand. SNMPv3 "fixed" the problem of reliable notifications, in part because there was a class of network management entities that did not want constant polling, but still wanted to make sure that notifications were reliable. I think we should wait until we have a complete set of required scenarios before we dismiss this as a possible requirement. Also, I'm assuming that the "mirroring" capability is not to suggest that "failover" is in scope, but instead to allow some "enabling" technology by which a client "could" construct some type of failover. This would really only need to be supported if the functionality naturally overlapped one or more other requirements. Randy -----Original Message----- From: Andrew Molitor To: midcom@ietf.org Sent: 3/27/01 6:44 AM Subject: Re: [midcom] Protocol Requirements - On Tue, 27 Mar 2001, Melinda Shore wrote: > Quick notes: > > - must operate over standard IP transports, UDP required, TCP > > optional. > > Transport specification is an answer, not a question. i.e. > we need to describe transport requirement characteristics. Point taken. Is it fair to devise a maze of constraints which rule out everything except 'UDP, with a TCP option'? For a large number of fairly vague reasons which I would, if necessary, take the time to refine and write down, I think that any other transport description would be lunacy. I am, nontheless, happy to phrase the answer in the form of a requirement! > > - should support one or more privacy models (I am weak on this > > because, in general, not much you are saying is a big > > secret -- traffic flows will pretty much reveal the state > > of the box anyways) > > To varying degrees. It's pretty common to do VPN termination > on firewalls, and while you can infer a lot from tunnelled > traffic characteristics at least the actual destination > address itself is protected in the case where the VPN is > encrypted. What I meant was this: If I open a pinhole allowing traffic from A to B, the fact that I have will be obvious pretty soon, when A starts sending traffic to B. This is somewhat more trivial than VPN traffic analysis. Of course, I conveniently forgot NAT and the fact that people like to hide their private addresses when I wrote that. Again, point taken, and thanks. > > - must support server-to-client informational messages (or > > transactions?) > > "Transaction" implies that a response would be expected. > We had talked about asynchronous alerts from the middlebox > to the midcom client and agreed that it's necessary - can > you describe a scenario in which you'd like a response > back to the middlebox? I cannot. As a potential server-end MIDCOM implementor, I REALLY like the plan to send alerts optimistically into the void and hope for the best. > > - must support a method for mirroring an existing NAT > > binding allocated by one middlebox into another middlebox, > > for redundancy. There are a few ways to build this, > > I don't know or care how the protocol does it, but > > this capability must be supported. > > I'm actually not convinced about that, but even so, > a mechanism to do this that required communication > among middleboxes is out of scope. A mechanism that > made the client responsible for requesting a particular > binding is not. Either way, how the address of the > NAT itself is failed over is absolutely not our concern, > yet if that's not done the question of transferring > existing bindings is pretty much moot. I actually meant to indicate a mechanism whereby a client can do the heavy lifting. The point was that the MIDCOM protocol should support: - returning enough information to the client to allow a NAT binding to be installed on a parallel middlebox - a way to install said information on same The difficulty is that the Middlebox-NAT really needs to be allocating stuff (port numbers and whatnot) in the normal case. Otherwise the multiple-client case breaks entirely, and the clients have to do way too much computation and address/port space management. However, in the redundant middlebox case, the "spare" middlebox has to simply told what the other one did. Then, if all the clients agree which one is the primary and which one is the spare, we don't have Middlebox A and Middlebox B allocating the same IP address/port to two different things. This is actually a solution too. What is needed is a way, any way, to allow a bunch of clients to collectively keep a bunch of middleboxes all configured the same. The idea of middlebox-middlebox communications a) gives me the willies and b) doesn't solve the problem. You really need a single logical allocator of IP addresses and ports to avoid problems. Thanks much for your comments! _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Mar 27 13:39:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25551 for ; Tue, 27 Mar 2001 13:39:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26145; Tue, 27 Mar 2001 13:31:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26107 for ; Tue, 27 Mar 2001 13:30:55 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25320 for ; Tue, 27 Mar 2001 13:30:55 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA61466; Tue, 27 Mar 2001 10:30:13 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA21818; Tue, 27 Mar 2001 10:30:18 -0800 Message-ID: <3AC0D986.FF1500EA@hursley.ibm.com> Date: Tue, 27 Mar 2001 12:18:46 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Eliot Lear CC: Randy Turner , midcom@ietf.org Subject: Re: [midcom] on "diversion" References: <91CDB24C5FCDD31198A2009027E79021011BD9CE@exchange.2wire.com> <3ABDB471.1060307@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit This looks exactly like the OPES call-out model to me, except that OPES is restricting the domain of discourse to HTTP and RTP based apps. Brian Eliot Lear wrote: > > To me, diversion means the following (the numbers next to the lines > indicate the data flow): > > __________ > | | > | External | > | Host | > |__________| > v > | > | > |1 > | > | > ___v______ 2 ______________ > | |>---------->| | > | NAT / | | Application | > | Firewall |<----------<| Controller | > |__________| 3 |______________| > v > | > | > |4 > | > | > ___v______ > | | > | Internal | > | Host | > |__________| > > Although I indicate flow direction from external to internal, the > opposite flow direction would also be considered a diversion. > > Note that (3) is optional. It's quite possible that the > application controller could conceivably consume the flow in its > entirety (like in the case of a transparent cache). > > Requiring this sort of capability, and even mentioning it, is > a rathole. I'm not arguing that we should go out of our way to > prevent it, but let's not go out of our way to do that either. > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Mar 27 14:10:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26540 for ; Tue, 27 Mar 2001 14:10:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26610; Tue, 27 Mar 2001 14:02:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26582 for ; Tue, 27 Mar 2001 14:02:01 -0500 (EST) Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26305 for ; Tue, 27 Mar 2001 14:02:01 -0500 (EST) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id TAA10881 for ; Tue, 27 Mar 2001 19:01:27 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 27 Mar 2001 19:01:29 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Mar 2001 11:01:28 -0800 Message-ID: <856592CED9BBD211AC3E00A0C967ED7A05618C08@orsmsx51.jf.intel.com> From: "Anderson, Todd A" To: "'midcom@ietf.org'" Subject: RE: [midcom] on "diversion" Date: Tue, 27 Mar 2001 11:01:26 -0800 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I have only been following the MIDCOM work recently so I don't know for sure whether interactions 2 and 3 have been declared "in scope" but it seems like they haven't so I'd like to throw my 2 cents in. From my perspective, if I am a midcom client, I don't care about the architecture of the middlebox. If the middlebox has a separate application controller, I don't want to be aware of that fact. I want the firewall and controller to behave as one virtual box. Therefore, I think it is very important to clearly separate interactions 1 and 4 from 2 and 3. Having said that, I am in favor of efforts in the 2-3 space such as OPES. It also seems like part of the ForCES work is in this same area. I think I understand the motivation to get into this area though because whatever one carries in 1 and 4 also has to be respresented in 2 and 3. However, 2 and 3 may be solved as part of a more general problem and I don't think they should be addressed by this group. Todd > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, March 27, 2001 10:19 AM > To: Eliot Lear > Cc: Randy Turner; midcom@ietf.org > Subject: Re: [midcom] on "diversion" > > > This looks exactly like the OPES call-out model to me, except that > OPES is restricting the domain of discourse to HTTP and RTP based > apps. > > Brian > > Eliot Lear wrote: > > > > To me, diversion means the following (the numbers next to the lines > > indicate the data flow): > > > > __________ > > | | > > | External | > > | Host | > > |__________| > > v > > | > > | > > |1 > > | > > | > > ___v______ 2 ______________ > > | |>---------->| | > > | NAT / | | Application | > > | Firewall |<----------<| Controller | > > |__________| 3 |______________| > > v > > | > > | > > |4 > > | > > | > > ___v______ > > | | > > | Internal | > > | Host | > > |__________| > > > > Although I indicate flow direction from external to internal, the > > opposite flow direction would also be considered a diversion. > > > > Note that (3) is optional. It's quite possible that the > > application controller could conceivably consume the flow in its > > entirety (like in the case of a transparent cache). > > > > Requiring this sort of capability, and even mentioning it, is > > a rathole. I'm not arguing that we should go out of our way to > > prevent it, but let's not go out of our way to do that either. > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > Non-IBM email: brian@icair.org > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Mar 27 14:27:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27116 for ; Tue, 27 Mar 2001 14:27:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26776; Tue, 27 Mar 2001 14:14:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26747 for ; Tue, 27 Mar 2001 14:14:23 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26716 for ; Tue, 27 Mar 2001 14:14:23 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 27 Mar 2001 13:49:33 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HS2C8R7R; Tue, 27 Mar 2001 13:49:31 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HMHZDWKY; Tue, 27 Mar 2001 13:49:32 -0500 Message-ID: <3AC0E199.2B9B3391@americasm01.nt.com> Date: Tue, 27 Mar 2001 13:53:13 -0500 From: "Abdallah Rayhan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: Randy Turner , midcom Subject: Re: [midcom] on "diversion" References: <91CDB24C5FCDD31198A2009027E7902102AA2786@exchange.2wire.com> <029201c0b5f4$0ec1bf40$d45904d1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Is diversion similar to the out-of-path concept? They seem to follow similar processing. regards Abdallah Melinda Shore wrote: > > > Ok, I believe that's really what diversion means to me as well. > > > > If this is out-of-scope, then this leaves out the ability to "outboard" > > an ALG processor from the firewall/NAT device, which I guess is ok with me. > > Actually, it doesn't - it just means that it wouldn't > be done in midcom. > > Here's where I think we are with this: > 1) a packet of "known" provenance or disposition arrives > on a middlebox and is diverted to some sort of application > or network proxy/ALG/auxiliary thing: definitely out of > scope. > > 2) a packet of unknown provenance or disposition arrives > on a middlebox and we don't know what to do with it: > policy consultation to make a determination could be > part of the policy component, but diverting the packet > itself to some sort of application or network proxy/ > ALG/auxiliary thing is definitely out of scope. > > Melinda > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Mar 28 16:10:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11581 for ; Wed, 28 Mar 2001 16:10:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25243; Wed, 28 Mar 2001 15:58:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25214 for ; Wed, 28 Mar 2001 15:58:16 -0500 (EST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11256 for ; Wed, 28 Mar 2001 15:58:10 -0500 (EST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id UAA21571 for ; Wed, 28 Mar 2001 20:58:08 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 28 Mar 2001 20:58:08 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Mar 2001 12:58:06 -0800 Message-ID: From: "Maciocco, Christian" To: midcom@ietf.org Subject: RE: [midcom] on "diversion" Date: Wed, 28 Mar 2001 12:58:02 -0800 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This picture might lead to confusion over what Midcom is doing. At the last meeting it was said that Midcom will focus only on NAT/Firewall and not application level stuff. I'd remove (2) & (3) from this picture as this seems closer to what OPES is doing. Christian > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Sunday, March 25, 2001 1:04 AM > To: Randy Turner > Cc: midcom@ietf.org > Subject: Re: [midcom] on "diversion" > > > To me, diversion means the following (the numbers next to the lines > indicate the data flow): > > __________ > | | > | External | > | Host | > |__________| > v > | > | > |1 > | > | > ___v______ 2 ______________ > | |>---------->| | > | NAT / | | Application | > | Firewall |<----------<| Controller | > |__________| 3 |______________| > v > | > | > |4 > | > | > ___v______ > | | > | Internal | > | Host | > |__________| > > > > Although I indicate flow direction from external to internal, the > opposite flow direction would also be considered a diversion. > > Note that (3) is optional. It's quite possible that the > application controller could conceivably consume the flow in its > entirety (like in the case of a transparent cache). > > Requiring this sort of capability, and even mentioning it, is > a rathole. I'm not arguing that we should go out of our way to > prevent it, but let's not go out of our way to do that either. > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Mar 28 16:46:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12880 for ; Wed, 28 Mar 2001 16:46:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26005; Wed, 28 Mar 2001 16:32:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25976 for ; Wed, 28 Mar 2001 16:32:46 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12451 for ; Wed, 28 Mar 2001 16:32:48 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA18399; Wed, 28 Mar 2001 13:32:40 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2SLWHR10200; Wed, 28 Mar 2001 13:32:18 -0800 (PST) Message-ID: <3AC259B6.1090303@cisco.com> Date: Wed, 28 Mar 2001 13:37:58 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0 i686; en-US; 0.8) Gecko/20010217 X-Accept-Language: en MIME-Version: 1.0 To: "Maciocco, Christian" CC: midcom@ietf.org Subject: Re: [midcom] on "diversion" References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Well, now. It sounds like we have consensus. Let's not do diversion and leave that for OPES (if anywhere). _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Mar 28 17:09:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13579 for ; Wed, 28 Mar 2001 17:09:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25965; Wed, 28 Mar 2001 16:31:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25930 for ; Wed, 28 Mar 2001 16:31:11 -0500 (EST) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12383 for ; Wed, 28 Mar 2001 16:31:12 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 9C55A8189 for ; Wed, 28 Mar 2001 15:30:09 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id PAA21732 for ; Wed, 28 Mar 2001 15:31:24 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Wed, 28 Mar 2001 15:31:24 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [midcom] Protocol Requirements Bullet List v2.0 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a new, improved, version of my earlier bullet list. I have noted edited bits in the leftmost column with a * so you can skip the bits I left alone. I have a dreadful habit of using tabs sometimes, and eight spaces other times. Hopefully I didn't do it so much this comes out all weird on your screen. I am particularly interested in the issue of server-to-client messaging. I list a few possible things the server could tell the client in my very last bullet. I would very much like: - to know about any other sorts of things the middlebox could or should be able to tell the client. - what the requirement for acks is on all of these informative messages. It is, for example, possible to build a SIP proxy which works fine without any notifications from the middlebox at all. It might be useful, nontheless, to report timeouts. This might help the SIP proxy out in some way, and would at least let the SIP proxy report that something odd is going on (e.g. a BYE transaction happened but we never saw it -- so the call went away, the media stopped flowing, and the NAT elements timed out.) --------------------------------------------------------------------------- Throughout, I use this terminology: Client - something that requests pinholes and NAT bindings. For example, a MIDCOM aware ALG or SIP proxy. Server - something which is spoken to by a client. By implication, a Server resides in (logically, if not literally) a Middlebox, and exposes the services of that Middlebox to Clients. Middlebox - a firewall or NAT device which is coupled to a MIDCOM server, which offers the firewall/NAT services to Clients. Do we want to require a 1-to-1 relationship between Servers and Middleboxes? Protocol requirements in no particular order: General Stuff ============= * - must support low-latency, high-throughput operation, with * best effort to maintain low latency in the face of a lossy network. * This is necessary for telecom grade operations -- backoff * policies in retransmit timers are not necessarily a good idea * on controlled channels controlling equipment. (This boils * down to: TCP Considered Harmful -- in rather specific * environments.) * * - must also support more ordinary network traffic models for * use on standard networks where backoff policies for retransmit * timers, and the like, are a good ideas. (This boils down to: * TCP is a hell of a good idea most of the time.) * * [ I think the first bullet above pretty much requires UDP * transport with wicked timers, but if there's another option * I'd be pleased to hear about it. The situation I am thinking * of is: some goober in a POP unplugs the wrong cable for * a moment, or there is some other glitch in connectivity. * It would Be Bad if this glitch made TCP back off and make * the POP unable to complete calls for, say, 2 or 3 seconds * AFTER connectivity is restored. This could readily create * irritating post-dial delays for several hundred customers * over the next 10 seconds while the queue clears. This is the * sort of thing that gives telecom geeks nightmares. ] - should be transport independent, a la SIP. - must support high transaction throughput over highish latency networks (read: must support message streaming.) - must support one or more strong authentication models. * - must support one or more privacy models. - must support client-to-server request/response transactions. * - must support server-to-client "alerts" (unacknowledged messages) * * - should support an acknowledged server-to-client messaging * model as well? - must support models in which multiple clients talk to multiple servers. Specific Operations/Scenarios Note that these are protocol requirements, not box requirements. So, while the protocol must support the ability of a client to ask for a pinhole, the protocol also allows for a middlebox to return 'NO - I am a NAT, dummy.' * - must support a client-to-server transaction which returns * the middlebox capabilities to the client. These capabilities * must include, but not be restricted to: * - firewalling * - NAT * - NAT capabilities (ports and stuff) * - Plumbing information (where does NAT fit * relative to other elements, specifically, * THIS MATTERS!) * * and should include: * - QoS * - QoS flavor(s) * [ can someone help out with what one might want to say * if one WERE a QoS capable middlebox? Is this far enough * out of scope to just leave QoS out entirely, burying it * in the 'but not be restricted to' part above? ] - must support a client-to-server transaction to open a "pinhole" in the middlebox's traffic policy. - must support a client-to-server transaction to request a NAT binding, associating an IP address/port pair on one interface with an IP address/port pair on another. - it would sure be nice if these binding requests could specify information about the expected source of the flow initiator. E.G. 'I have a server on the inside at 192.168.1.99 port 5000, and I think someone on the outside at address 209.46.41.61, I don't know the port' will be connecting to my server -- please give me an address/port I can advertise to the remote as the phone's address/port' * - must support means for clients to manage redundant middlebox * configurations. This means that it must be possible for a * client or clients to: * - apply the same NAT binding across multiple (NAT capable) * middleboxes. * - apply the same pinhole across multiple (pinhole capable) * middleboxes (this is actually trivial and impossible * to NOT get right -- included for completeness) * * [ these two boil down to: client can keep a primary * and a spare middlebox in synch ] * * - bring a new middlebox into synch with a set of * synchronized redundant middleboxes. * * [ this boils down to: a client can bring a formerly * dead primary middlebox back into service after repairs, * without bringing the network down.] - must support a client-to-server transaction to release an individual NAT binding. - must support a client-to-server transaction to release an individual pinhole. - should support a way to identify bundles of state (pinholes and NAT) as belonging to the same group (a "session ID" specified by the client in a set of requests) - should support a client-to-server transaction to delete all the state bundled under a given session ID. * - should support a way to re-session-ID a bundle. That is, * there should be a client-to-server transaction in which * the client asks the middlebox to take all the stuff with * session ID "A" and re-file it under session ID "B" * * [ this is a surprisingly useful operation but the uses of it * that I know of might be proprietary so I shan't describe them. * There are people reading who know whether they are or are not * proprietary, so if there is curiosity, hopefully explanations * will be forthcoming. Sorry to be so mysterious. ] - must support a way to specify a desired timeout value for and piece of state created by a client-to-server transaction. - should support both activity based timeouts as well as absolute timeouts (i.e. support both 'if you don't see any packets for 60 seconds, please make this NAT binding go away by itself' AND 'make this NAT binding go away in 60 seconds') - must support client-to-server transactions to query middlebox state, including but not restricted to: - currently installed pinholes - currently installed NAT bindings - statistics of various sorts - should support a client-to-server transaction allowing the client to register to receive notifications of various sorts from the server. - should support some server-to-client transactions to inform the client of events such as: - timeouts of pinholes and NATs - violations of policy - other? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Mar 28 17:23:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13904 for ; Wed, 28 Mar 2001 17:23:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26651; Wed, 28 Mar 2001 17:12:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26620 for ; Wed, 28 Mar 2001 17:12:02 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13628 for ; Wed, 28 Mar 2001 17:12:02 -0500 (EST) From: Jon.Peterson@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id WAA05226; Wed, 28 Mar 2001 22:12:02 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA20857; Wed, 28 Mar 2001 22:12:02 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Mar 2001 15:14:18 -0700 Message-ID: <6384220893BCD411BDFE0008C791B79CA3E430@N0228IDC1.oss.level3.com> To: lear@cisco.com, christian.maciocco@intel.com Cc: midcom@ietf.org Subject: RE: [midcom] on "diversion" Date: Wed, 28 Mar 2001 15:10:07 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org While I agree that no protocol work in midcom should be done in support of diversion, I'd like to second Scott Brim's earlier statement that we shouldn't necessarily remove from the conceptual framework doc any and all mention of the use of diversion, as I think it could provide valuable context for understanding middlebox deployments. Jon Peterson Level(3) Communications -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: Wednesday, March 28, 2001 2:38 PM To: Maciocco, Christian Cc: midcom@ietf.org Subject: Re: [midcom] on "diversion" Well, now. It sounds like we have consensus. Let's not do diversion and leave that for OPES (if anywhere). _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Mar 28 20:22:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16417 for ; Wed, 28 Mar 2001 20:22:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28835; Wed, 28 Mar 2001 20:05:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28804 for ; Wed, 28 Mar 2001 20:05:36 -0500 (EST) Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16183 for ; Wed, 28 Mar 2001 20:05:38 -0500 (EST) Received: from condryvaio-desk.intel.com (condryvaio-desk.jf.intel.com [134.134.159.68]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with ESMTP id BAA00273; Thu, 29 Mar 2001 01:05:35 GMT Message-Id: <5.0.2.1.2.20010328170245.018c3148@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 28 Mar 2001 17:03:47 -0800 To: "Scott Brim" , lear@cisco.com From: "Michael W. Condry" Subject: Re: [midcom] on "diversion" Cc: midcom@ietf.org, ietf-openproxy@imc.org In-Reply-To: <15037.59051.243000.874560@gargle.gargle.HOWL> References: <3ABD4231.96BE54EC@cisco.com> <3ABD4231.96BE54EC@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Yes, and this discussion keeps occurring at OPES as well. Why don't we stick to our charter's and then work as a team over time for the more generic architecture. At 07:38 AM 3/25/2001 -0500, Scott Brim wrote: >On 24 Mar 2001 at 16:56 -0800, Eliot Lear apparently wrote: > > Do people need to be convinced that diversion is not necessary to discuss > > in ANY midcom work? > >It's certainly not in scope for requirements or protocol work. I like >having it in the conceptual framework, just as we do e.g. simple >proxies, just so we all have the same context. > >...Scott > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >http://www.ietf.org/mailman/listinfo/midcom Michael W. Condry Director, Network Edge Technology _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Mar 28 20:41:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16658 for ; Wed, 28 Mar 2001 20:41:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29249; Wed, 28 Mar 2001 20:34:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29222 for ; Wed, 28 Mar 2001 20:34:14 -0500 (EST) Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16576 for ; Wed, 28 Mar 2001 20:34:15 -0500 (EST) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id BAA04813; Thu, 29 Mar 2001 01:33:04 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 29 Mar 2001 01:33:06 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Mar 2001 17:33:04 -0800 Message-ID: From: "Maciocco, Christian" To: "'Jon.Peterson@Level3.com'" , lear@cisco.com Cc: midcom@ietf.org Subject: RE: [midcom] on "diversion" Date: Wed, 28 Mar 2001 17:33:03 -0800 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Is this in the context of NAT/Firewall? If not it seems to be out of scope of Midcom charter. > -----Original Message----- > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] > Sent: Wednesday, March 28, 2001 2:10 PM > To: lear@cisco.com; christian.maciocco@intel.com > Cc: midcom@ietf.org > Subject: RE: [midcom] on "diversion" > > > While I agree that no protocol work in midcom should be done > in support of > diversion, I'd like to second Scott Brim's earlier statement that we > shouldn't necessarily remove from the conceptual framework > doc any and all > mention of the use of diversion, as I think it could provide valuable > context for understanding middlebox deployments. > > Jon Peterson > Level(3) Communications > > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Wednesday, March 28, 2001 2:38 PM > To: Maciocco, Christian > Cc: midcom@ietf.org > Subject: Re: [midcom] on "diversion" > > > Well, now. It sounds like we have consensus. Let's not do diversion > and leave that for OPES (if anywhere). > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 29 07:07:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10384 for ; Thu, 29 Mar 2001 07:07:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12877; Thu, 29 Mar 2001 06:58:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12846 for ; Thu, 29 Mar 2001 06:58:44 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09997 for ; Thu, 29 Mar 2001 06:58:46 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id DAA17379; Thu, 29 Mar 2001 03:58:14 -0800 (PST) Received: from spandex (rtp-vpn-28.cisco.com [10.82.192.28]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AAP03564; Thu, 29 Mar 2001 03:58:08 -0800 (PST) Message-ID: <009801c0b847$ce6ccec0$d45904d1@cisco.com> From: "Melinda Shore" To: "Maciocco, Christian" Cc: References: Subject: Re: [midcom] on "diversion" Date: Thu, 29 Mar 2001 07:00:09 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > Is this in the context of NAT/Firewall? If not it seems to be > out of scope of Midcom charter. It is out of scope, but not because it doesn't directly address NATs or firewalls. It's just plain out of scope. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 29 16:33:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12218 for ; Thu, 29 Mar 2001 16:33:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20718; Thu, 29 Mar 2001 16:23:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20686 for ; Thu, 29 Mar 2001 16:23:26 -0500 (EST) Received: from mail.aravox.com (mail.aravox.com [209.46.41.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11647 for ; Thu, 29 Mar 2001 16:23:27 -0500 (EST) Received: from linux.aravox.com (mail-gw.aravox.com [209.46.41.66]) by mail.aravox.com (Postfix) with ESMTP id 1C23C542D; Thu, 29 Mar 2001 15:22:57 -0600 (CST) Received: (from jladwig@localhost) by linux.aravox.com (8.9.3/8.9.3) id PAA08859; Thu, 29 Mar 2001 15:22:56 -0600 From: John Ladwig MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15043.42927.329929.107551@linux.aravox.com> Date: Thu, 29 Mar 2001 15:22:55 -0600 (CST) To: "Melinda Shore" Cc: Subject: Re: [midcom] Fw: minutes In-Reply-To: Melinda Shore's message <03db01c0b465$06c3dd90$d65904d1@NAUGA> of 24 March 2001 References: <03db01c0b465$06c3dd90$d65904d1@NAUGA> X-Mailer: VM 6.71 under 21.1 (patch 4) "Arches" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Is the proposed interim meeting actually going to happen? Does there have to be some sort of formal notice of it at least 30 days prior? If so, seems like we're at decision-time. Us here at Aravox, we think the interim meeting is a fine idea. -jml >>>>> On Sat, 24 Mar 2001 08:19:15 -0500, "Melinda Shore" said: >> MIDCOM Meeting Minutes, 50th IETF >> Chair: Melinda Shore >> Minutes: Ted Hardie >> March 22, 2001 [ snip ] >> An interim meeting has been proposed in conjunction with the >> SIP summit in Richardson, TX. The SIP meeting is May 1 & May >> 2nd, 2001. The chair and ADs will discuss the scheduling of an >> interim meeting. The interim meeting will be focused on >> eliminating any remaining confusion on models, and attendees >> will be expected to volunteer to produce text for working group >> documents based on the results. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 29 16:41:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12615 for ; Thu, 29 Mar 2001 16:41:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21078; Thu, 29 Mar 2001 16:33:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21046 for ; Thu, 29 Mar 2001 16:33:50 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12250 for ; Thu, 29 Mar 2001 16:33:50 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA16155; Thu, 29 Mar 2001 13:32:50 -0800 (PST) Received: from spandex (rtp-vpn-121.cisco.com [10.82.192.121]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AAQ14255; Thu, 29 Mar 2001 13:32:33 -0800 (PST) Message-ID: <012f01c0b898$0cc2b2c0$d45904d1@cisco.com> From: "Melinda Shore" To: "John Ladwig" Cc: References: <03db01c0b465$06c3dd90$d65904d1@NAUGA> <15043.42927.329929.107551@linux.aravox.com> Subject: Re: [midcom] Fw: minutes Date: Thu, 29 Mar 2001 16:34:34 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > Is the proposed interim meeting actually going to happen? Does there > have to be some sort of formal notice of it at least 30 days prior? > If so, seems like we're at decision-time. An interim working group meeting requires 30 days advance notice and the approval of the area directors. A design team meeting isn't under the same strictures. However, I would just as soon not have any kind of meeting without 1) clear goals, 2) a clear agenda, 3) significant progress by way of discussions conducted on the mailing list, and 4) revised documents available a reasonable amount of time in advance. I think we need to be a bit sensitive to restricted travel budgets, if nothing else. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 29 20:58:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25179 for ; Thu, 29 Mar 2001 20:58:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24485; Thu, 29 Mar 2001 20:52:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24458 for ; Thu, 29 Mar 2001 20:52:56 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24791 for ; Thu, 29 Mar 2001 20:52:58 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA18564 for ; Thu, 29 Mar 2001 17:52:26 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2U1qP525925 for ; Thu, 29 Mar 2001 17:52:25 -0800 (PST) Message-ID: <3AC3E6D7.C2F1CB6D@cisco.com> Date: Thu, 29 Mar 2001 17:52:23 -0800 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] SIP MIDCOM flow... Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi, Can someone help me fill in the missing pieces in the following diagram? I'm trying to understand the flow of communication. _________ --->| SIP | / | Proxy | | |_________| 1| | | | | | |4 |2 |3 _________ | | | | Outside |<--/ _v_____^___ ________ |SIP Phone| | | | Inside | | |>------->| MiddleBox |>------->| SIP | |_________|<-------<|___________|<-------<| Phone | |________| Note that 1/4 is a request/response respectively. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 29 21:27:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26781 for ; Thu, 29 Mar 2001 21:27:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24861; Thu, 29 Mar 2001 21:19:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24832 for ; Thu, 29 Mar 2001 21:19:47 -0500 (EST) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26461 for ; Thu, 29 Mar 2001 21:19:47 -0500 (EST) Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.11.3/8.11.3) with ESMTP id f2U2JU421213; Fri, 30 Mar 2001 12:19:30 +1000 (EST) To: lear@cisco.com cc: midcom@ietf.org Subject: Re: [midcom] SIP MIDCOM flow... In-reply-to: Your message of "Thu, 29 Mar 2001 17:52:23 PST." <3AC3E6D7.C2F1CB6D@cisco.com> Date: Fri, 30 Mar 2001 12:19:31 +1000 Message-ID: <9418.985918771@dstc.edu.au> From: George Michaelson X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi, Can someone help me fill in the missing pieces in the following diagram? I'm trying to understand the flow of communication. _________ --->| SIP | / | Proxy | | |_________| 1| | | | | | |4 |2 |3 _________ | | | | Outside |<--/ _v_____^___ ________ |SIP Phone| a | | c | Inside | | |>------->| MiddleBox |>------->| SIP | |_________|<-------<|___________|<-------<| Phone | b d |________| Note that 1/4 is a request/response respectively. I have labelled the other paths {a,b,c,d} to make it plain they aren't ordered. Your question lies in the space: "what order do {a,b,c,d} take place" and one presumes there are sequencing differences if c predicates 3-4 being done etc etc. ie, in a 3-way endpoint dialogue, is there end-to-end-ness for all 3 parties? (middlebox is being directed in this exchange. circumstances where it says "no" seem to me to under constrains coming from other places. Or does it have rigid policy embedded? are there other paths left out for simplicity?) -George -- George Michaelson | DSTC Pty Ltd Email: ggm@dstc.edu.au | University of Qld 4072 Phone: +61 7 3365 4310 | Australia Fax: +61 7 3365 4311 | http://www.dstc.edu.au _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 29 21:33:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27099 for ; Thu, 29 Mar 2001 21:33:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24927; Thu, 29 Mar 2001 21:28:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24894 for ; Thu, 29 Mar 2001 21:28:41 -0500 (EST) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26810 for ; Thu, 29 Mar 2001 21:28:38 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA28005; Thu, 29 Mar 2001 21:31:49 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Mar 2001 21:28:25 -0500 Message-ID: From: Tim Rang To: "'George Michaelson'" , lear@cisco.com Cc: midcom@ietf.org Subject: RE: [midcom] SIP MIDCOM flow... Date: Thu, 29 Mar 2001 21:28:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I guess I read the question somewhat differently... > -----Original Message----- > From: George Michaelson [mailto:ggm@dstc.edu.au] > Sent: Thursday, March 29, 2001 9:20 PM > To: lear@cisco.com > Cc: midcom@ietf.org > Subject: Re: [midcom] SIP MIDCOM flow... > > > > Hi, > > Can someone help me fill in the missing pieces in the > following diagram? > I'm trying to understand the flow of communication. > > > _________ > --->| SIP | > / | Proxy | > | |_________| > 1| | | > | | | > |4 |2 |3 > _________ | | | > | Outside |<--/ _v_____^___ ________ > |SIP Phone| a | | c | Inside | > | |>------->| MiddleBox |>------->| SIP | > |_________|<-------<|___________|<-------<| Phone | > b d |________| > > Note that 1/4 is a request/response respectively. > > > I have labelled the other paths {a,b,c,d} to make it plain they aren't > ordered. Your question lies in the space: > > "what order do {a,b,c,d} take place" What your diagram is missing is the SIP signaling that occurs between SIP Proxy and Inside SIP Phone. Segments a and c cannot occur until signaling is exchanged between those 2 specifying the desired media for that phone. So, while your timing for when you set policy at the middlebox is a Proxy implementation question, a and c cannot occur until something along these lines occurs- 5. Proxy --> Inside SIP Phone 6. Inside SIP Phone --> PRoxy 7. Proxy --> Middlebox 8. Middlebox-->Proxy ... at which time, what you specify as 4 can occur. Tim Rang > > and one presumes there are sequencing differences if c predicates 3-4 > being done etc etc. > > ie, in a 3-way endpoint dialogue, is there end-to-end-ness > for all 3 parties? > > (middlebox is being directed in this exchange. circumstances > where it says > "no" seem to me to under constrains coming from other > places. Or does it have > rigid policy embedded? are there other paths left out for > simplicity?) > > -George > > -- > George Michaelson | DSTC Pty Ltd > Email: ggm@dstc.edu.au | University of Qld 4072 > Phone: +61 7 3365 4310 | Australia > Fax: +61 7 3365 4311 | http://www.dstc.edu.au > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Mar 29 21:36:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28268 for ; Thu, 29 Mar 2001 21:36:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24971; Thu, 29 Mar 2001 21:29:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24938 for ; Thu, 29 Mar 2001 21:29:19 -0500 (EST) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26842 for ; Thu, 29 Mar 2001 21:29:21 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 2B9F881B8 for ; Thu, 29 Mar 2001 20:07:59 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id UAA23384 for ; Thu, 29 Mar 2001 20:08:17 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 29 Mar 2001 20:08:17 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] SIP MIDCOM flow... In-Reply-To: <3AC3E6D7.C2F1CB6D@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, 29 Mar 2001, Eliot Lear wrote: > Hi, > > Can someone help me fill in the missing pieces in the following diagram? > I'm trying to understand the flow of communication. > > > _________ > --->| SIP | > / | Proxy | > | |_________| > 1| | | > | | | > |4 |2 |3 > _________ | | | > | Outside |<--/ _v_____^___ ________ > |SIP Phone| | | | Inside | > | |>------->| MiddleBox |>------->| SIP | > |_________|<-------<|___________|<-------<| Phone | > |________| > > Note that 1/4 is a request/response respectively. Outside SIP Phone -- OSP SIP Proxy -- SP Middlebox -- MB Inside SIP Phone -- ISP It goes like this: 1) INVITE from OSP to SP 2) SP makes bind request to MB 3) MB replies with binding of an internal address for OSP 4) SP re-writes INVITE's SDP 5) SP sends INVITE to ISP 6) ISP rings and stuff until someone picks up; 200 OK -> SP 7) SP makes bind request to MB 8) MB replies with public address for ISP 9) SP rewrites SDP in 200 OK 10) SP forwards 200 OK to OSP 11) OSP replies to 200 OK with ACK 12) SP receives ACK and opens pinholes for media streams on MB (using addresses pre NAT -- hence importance of understanding NAT/Fwall plumbing in MB!) 13) SP forwards ACK to ISP 14) media flows Notes: steps 2-4 are not necessary in the easy case, where the OSP's address is perfectly useful to the ISP as is (normal enterprise NAT case). step 12 can be done almost any time you like. It makes sense to do it on the ACK from a purist point of view. On the other hand, it may also make sense to open pinholes early, since media can start to flow awfully early from some phones. You can open one pinhole immediately after step 4 (for outgoing media) and the other after step 9 (for incoming media). Obviously you can open them any time later as well, including as indicated. I think I have this right, at any rate. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 09:42:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17967 for ; Fri, 30 Mar 2001 09:42:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10414; Fri, 30 Mar 2001 09:31:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10383 for ; Fri, 30 Mar 2001 09:31:30 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17328 for ; Fri, 30 Mar 2001 09:31:32 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A86EA20268; Fri, 30 Mar 2001 09:30:06 -0500 Message-ID: <007901c0b925$4c345340$3700000a@acmepacket.com> From: "Bob Penfield" To: , "George Michaelson" Cc: References: <9418.985918771@dstc.edu.au> Subject: Re: [midcom] SIP MIDCOM flow... Date: Fri, 30 Mar 2001 09:25:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit see comments below ----- Original Message ----- From: "George Michaelson" To: Cc: Sent: Thursday, March 29, 2001 9:19 PM Subject: Re: [midcom] SIP MIDCOM flow... > > Hi, > > Can someone help me fill in the missing pieces in the following diagram? > I'm trying to understand the flow of communication. > > > _________ > --->| SIP |<-----\ > / | Proxy | \ > | |_________| | > 1| | | 1a| > | | | | > |4 |2 |3 |1b > _________ | | | \ ________ > | Outside |<--/ _v_____^___ \->| | > |SIP Phone| a | | c | Inside | > | |>------->| MiddleBox |>------->| SIP | > |_________|<-------<|___________|<-------<| Phone | > b d |________| > > Note that 1/4 is a request/response respectively. There is a missing request/response (I've added 1a+1b above) from the SIP Proxy to the Inside SIP Phone. Note that 1+4 and/or 1a+1b may go thru the MiddleBox for NAT/Firewall, but that rule would have been previously estabished. > > I have labelled the other paths {a,b,c,d} to make it plain they aren't > ordered. Your question lies in the space: > > "what order do {a,b,c,d} take place" > These represent the RTP flow for the session and it does not really matter whether a or d is first. None of them can begin until the NAT/forwarding rules (forward a to c and d to b) are installed by the 2+3 transaction from the proxy. > and one presumes there are sequencing differences if c predicates 3-4 > being done etc etc. > > ie, in a 3-way endpoint dialogue, is there end-to-end-ness for all 3 parties? > > (middlebox is being directed in this exchange. circumstances where it says > "no" seem to me to under constrains coming from other places. Or does it have > rigid policy embedded? are there other paths left out for simplicity?) > > -George > > -- > George Michaelson | DSTC Pty Ltd > Email: ggm@dstc.edu.au | University of Qld 4072 > Phone: +61 7 3365 4310 | Australia > Fax: +61 7 3365 4311 | http://www.dstc.edu.au > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 11:41:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24835 for ; Fri, 30 Mar 2001 11:41:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11953; Fri, 30 Mar 2001 11:29:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11925 for ; Fri, 30 Mar 2001 11:29:30 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24110 for ; Fri, 30 Mar 2001 11:29:31 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GB000B28R37OK@firewall.mcit.com> for midcom@ietf.org; Fri, 30 Mar 2001 16:28:19 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GB000C01R30PA@dgismtp01.wcomnet.com> for midcom@ietf.org; Fri, 30 Mar 2001 16:28:19 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GB0009L0R2XPC@dgismtp01.wcomnet.com>; Fri, 30 Mar 2001 16:28:09 +0000 (GMT) Date: Fri, 30 Mar 2001 10:28:04 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] SIP MIDCOM flow... In-reply-to: <007901c0b925$4c345340$3700000a@acmepacket.com> To: midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <001001c0b936$66307c40$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit To simplify things a bit, in relation to SIP, I thought that I would add this call flow to the mix. Middlebox control messages are merely examples. SIP UA SIP Middle Internal Client Proxy Box SIP Client | | | | |----INVITE------>| | | | |-----INVITE--->| | |<---100Trying----| | | | |----Initiate-->| | | |<-Initiated----| | | | |-INVITE-->| | |<-----180Ringing----------| |<--180Ringing----| | | | |<-------200 OK------------| |<---200 OK ------| | | | |----OPEN Hole->| | | |<-OPEN Hole----| | |-------ACK------>| | | | |-----------ACK------------| | | | | |<-------------------RTP/RTCP--------------->| | | | | |-------BYE------>| | | | |----Terminate->| | | |<-Terminating--| | | | |----BYE-->| | |<----------200 OK---------| | |----CloseHole->| | | |<---CloseHole--| | |<---200 OK-------| | | | | | | This flow describes a call from start to finish. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Bob Penfield > Sent: Friday, March 30, 2001 8:26 AM > To: lear@cisco.com; George Michaelson > Cc: midcom@ietf.org > Subject: Re: [midcom] SIP MIDCOM flow... > > > see comments below > > > ----- Original Message ----- > From: "George Michaelson" > To: > Cc: > Sent: Thursday, March 29, 2001 9:19 PM > Subject: Re: [midcom] SIP MIDCOM flow... > > > > > > Hi, > > > > Can someone help me fill in the missing pieces in the > following diagram? > > I'm trying to understand the flow of communication. > > > > > > _________ > > --->| SIP |<-----\ > > / | Proxy | \ > > | |_________| | > > 1| | | 1a| > > | | | | > > |4 |2 |3 |1b > > _________ | | | \ ________ > > | Outside |<--/ _v_____^___ \->| | > > |SIP Phone| a | | c | Inside | > > | |>------->| MiddleBox |>------->| SIP | > > |_________|<-------<|___________|<-------<| Phone | > > b d |________| > > > > Note that 1/4 is a request/response respectively. > > There is a missing request/response (I've added 1a+1b above) > from the SIP > Proxy to the Inside SIP Phone. Note that 1+4 and/or 1a+1b may > go thru the > MiddleBox for NAT/Firewall, but that rule would have been previously > estabished. > > > > > I have labelled the other paths {a,b,c,d} to make it plain > they aren't > > ordered. Your question lies in the space: > > > > "what order do {a,b,c,d} take place" > > > These represent the RTP flow for the session and it does not > really matter > whether a or d is first. None of them can begin until the > NAT/forwarding > rules (forward a to c and d to b) are installed by the 2+3 > transaction from > the proxy. > > > and one presumes there are sequencing differences if c > predicates 3-4 > > being done etc etc. > > > > ie, in a 3-way endpoint dialogue, is there end-to-end-ness for all 3 > parties? > > > > (middlebox is being directed in this exchange. > circumstances where it says > > "no" seem to me to under constrains coming from other > places. Or does it > have > > rigid policy embedded? are there other paths left out for > simplicity?) > > > > -George > > > > -- > > George Michaelson | DSTC Pty Ltd > > Email: ggm@dstc.edu.au | University of Qld 4072 > > Phone: +61 7 3365 4310 | Australia > > Fax: +61 7 3365 4311 | http://www.dstc.edu.au > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 11:49:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25321 for ; Fri, 30 Mar 2001 11:49:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12232; Fri, 30 Mar 2001 11:35:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12201 for ; Fri, 30 Mar 2001 11:35:38 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24501 for ; Fri, 30 Mar 2001 11:35:39 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GB000INZRBM54@firewall.mcit.com> for midcom@ietf.org; Fri, 30 Mar 2001 16:33:22 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GB000F01RBBSU@dgismtp01.wcomnet.com> for midcom@ietf.org; Fri, 30 Mar 2001 16:33:22 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GB000F1YRB6IL@dgismtp01.wcomnet.com> for midcom@ietf.org; Fri, 30 Mar 2001 16:33:07 +0000 (GMT) Date: Fri, 30 Mar 2001 10:33:03 -0600 From: "Christopher A. Martin" Subject: FW: [midcom] SIP MIDCOM flow... To: midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <001101c0b937$17ecab20$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I thought I should change the name of the SIP proxy to SIP/Ctrl Proxy to denote that the midcom controller is integrated in this example for this protocol (and only as an example not as a requirement). To simplify things a bit, in relation to SIP, I thought that I would add this call flow to the mix. Middlebox control messages are merely examples. SIP UA SIP/Ctrl Middle Internal Client Proxy Box SIP Client | | | | |----INVITE------>| | | | |-----INVITE--->| | |<---100Trying----| | | | |----Initiate-->| | | |<-Initiated----| | | | |-INVITE-->| | |<-----180Ringing----------| |<--180Ringing----| | | | |<-------200 OK------------| |<---200 OK ------| | | | |----OPEN Hole->| | | |<-OPEN Hole----| | |-------ACK------>| | | | |-----------ACK------------| | | | | |<-------------------RTP/RTCP--------------->| | | | | |-------BYE------>| | | | |----Terminate->| | | |<-Terminating--| | | | |----BYE-->| | |<----------200 OK---------| | |----CloseHole->| | | |<---CloseHole--| | |<---200 OK-------| | | | | | | This flow describes a call from start to finish. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Bob Penfield > Sent: Friday, March 30, 2001 8:26 AM > To: lear@cisco.com; George Michaelson > Cc: midcom@ietf.org > Subject: Re: [midcom] SIP MIDCOM flow... > > > see comments below > > > ----- Original Message ----- > From: "George Michaelson" > To: > Cc: > Sent: Thursday, March 29, 2001 9:19 PM > Subject: Re: [midcom] SIP MIDCOM flow... > > > > > > Hi, > > > > Can someone help me fill in the missing pieces in the > following diagram? > > I'm trying to understand the flow of communication. > > > > > > _________ > > --->| SIP |<-----\ > > / | Proxy | \ > > | |_________| | > > 1| | | 1a| > > | | | | > > |4 |2 |3 |1b > > _________ | | | \ ________ > > | Outside |<--/ _v_____^___ \->| | > > |SIP Phone| a | | c | Inside | > > | |>------->| MiddleBox |>------->| SIP | > > |_________|<-------<|___________|<-------<| Phone | > > b d |________| > > > > Note that 1/4 is a request/response respectively. > > There is a missing request/response (I've added 1a+1b above) > from the SIP > Proxy to the Inside SIP Phone. Note that 1+4 and/or 1a+1b may > go thru the > MiddleBox for NAT/Firewall, but that rule would have been previously > estabished. > > > > > I have labelled the other paths {a,b,c,d} to make it plain > they aren't > > ordered. Your question lies in the space: > > > > "what order do {a,b,c,d} take place" > > > These represent the RTP flow for the session and it does not > really matter > whether a or d is first. None of them can begin until the > NAT/forwarding > rules (forward a to c and d to b) are installed by the 2+3 > transaction from > the proxy. > > > and one presumes there are sequencing differences if c > predicates 3-4 > > being done etc etc. > > > > ie, in a 3-way endpoint dialogue, is there end-to-end-ness for all 3 > parties? > > > > (middlebox is being directed in this exchange. > circumstances where it says > > "no" seem to me to under constrains coming from other > places. Or does it > have > > rigid policy embedded? are there other paths left out for > simplicity?) > > > > -George > > > > -- > > George Michaelson | DSTC Pty Ltd > > Email: ggm@dstc.edu.au | University of Qld 4072 > > Phone: +61 7 3365 4310 | Australia > > Fax: +61 7 3365 4311 | http://www.dstc.edu.au > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 12:05:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26288 for ; Fri, 30 Mar 2001 12:05:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12477; Fri, 30 Mar 2001 11:58:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12442 for ; Fri, 30 Mar 2001 11:58:03 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25880 for ; Fri, 30 Mar 2001 11:58:04 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GB0007HCSFWRB@firewall.mcit.com> for midcom@ietf.org; Fri, 30 Mar 2001 16:57:32 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GB000701SFSI1@dgismtp01.wcomnet.com> for midcom@ietf.org; Fri, 30 Mar 2001 16:57:32 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GB00070HSFIFX@dgismtp01.wcomnet.com>; Fri, 30 Mar 2001 16:57:19 +0000 (GMT) Date: Fri, 30 Mar 2001 10:57:15 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] SIP MIDCOM flow... In-reply-to: <001101c0b937$17ecab20$6401010a@mcit.com> To: christopher.a.martin@wcom.com, midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <001201c0b93a$794b65c0$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit One additional point of clarification, as you can see I am shooting fomr the hip, the following commands are not related to SIP rather they are used between middlebox and controller in this "example": Initiate, Initiated, Terminate, Terminating, OPEN Hole, Close Hole. All other messages are SIP specific to indicate how they would fit in a call flow together. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Christopher A. Martin > Sent: Friday, March 30, 2001 10:33 AM > To: midcom@ietf.org > Subject: FW: [midcom] SIP MIDCOM flow... > > > I thought I should change the name of the SIP proxy to > SIP/Ctrl Proxy to > denote that the midcom controller is integrated in this > example for this > protocol (and only as an example not as a requirement). > > To simplify things a bit, in relation to SIP, I thought that > I would add > this call flow to the mix. Middlebox control messages are > merely examples. > > SIP UA SIP/Ctrl Middle Internal > Client Proxy Box SIP Client > | | | | > |----INVITE------>| | | > | |-----INVITE--->| | > |<---100Trying----| | | > | |----Initiate-->| | > | |<-Initiated----| | > | | |-INVITE-->| > | |<-----180Ringing----------| > |<--180Ringing----| | | > | |<-------200 OK------------| > |<---200 OK ------| | | > | |----OPEN Hole->| | > | |<-OPEN Hole----| | > |-------ACK------>| | | > | |-----------ACK------------| > | | | | > |<-------------------RTP/RTCP--------------->| > | | | | > |-------BYE------>| | | > | |----Terminate->| | > | |<-Terminating--| | > | | |----BYE-->| > | |<----------200 OK---------| > | |----CloseHole->| | > | |<---CloseHole--| | > |<---200 OK-------| | | > | | | | > > This flow describes a call from start to finish. > > > > -----Original Message----- > > From: midcom-admin@ietf.org > [mailto:midcom-admin@ietf.org]On Behalf Of > > Bob Penfield > > Sent: Friday, March 30, 2001 8:26 AM > > To: lear@cisco.com; George Michaelson > > Cc: midcom@ietf.org > > Subject: Re: [midcom] SIP MIDCOM flow... > > > > > > see comments below > > > > > > ----- Original Message ----- > > From: "George Michaelson" > > To: > > Cc: > > Sent: Thursday, March 29, 2001 9:19 PM > > Subject: Re: [midcom] SIP MIDCOM flow... > > > > > > > > > > Hi, > > > > > > Can someone help me fill in the missing pieces in the > > following diagram? > > > I'm trying to understand the flow of communication. > > > > > > > > > _________ > > > --->| SIP |<-----\ > > > / | Proxy | \ > > > | |_________| | > > > 1| | | 1a| > > > | | | | > > > |4 |2 |3 |1b > > > _________ | | | \ ________ > > > | Outside |<--/ _v_____^___ \->| | > > > |SIP Phone| a | | c | Inside | > > > | |>------->| MiddleBox |>------->| SIP | > > > |_________|<-------<|___________|<-------<| Phone | > > > b d |________| > > > > > > Note that 1/4 is a request/response respectively. > > > > There is a missing request/response (I've added 1a+1b above) > > from the SIP > > Proxy to the Inside SIP Phone. Note that 1+4 and/or 1a+1b may > > go thru the > > MiddleBox for NAT/Firewall, but that rule would have been previously > > estabished. > > > > > > > > I have labelled the other paths {a,b,c,d} to make it plain > > they aren't > > > ordered. Your question lies in the space: > > > > > > "what order do {a,b,c,d} take place" > > > > > These represent the RTP flow for the session and it does not > > really matter > > whether a or d is first. None of them can begin until the > > NAT/forwarding > > rules (forward a to c and d to b) are installed by the 2+3 > > transaction from > > the proxy. > > > > > and one presumes there are sequencing differences if c > > predicates 3-4 > > > being done etc etc. > > > > > > ie, in a 3-way endpoint dialogue, is there > end-to-end-ness for all 3 > > parties? > > > > > > (middlebox is being directed in this exchange. > > circumstances where it says > > > "no" seem to me to under constrains coming from other > > places. Or does it > > have > > > rigid policy embedded? are there other paths left out for > > simplicity?) > > > > > > -George > > > > > > -- > > > George Michaelson | DSTC Pty Ltd > > > Email: ggm@dstc.edu.au | University of Qld 4072 > > > Phone: +61 7 3365 4310 | Australia > > > Fax: +61 7 3365 4311 | http://www.dstc.edu.au > > > > > > _______________________________________________ > > > midcom mailing list > > > midcom@ietf.org > > > http://www.ietf.org/mailman/listinfo/midcom > > > > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 12:31:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27622 for ; Fri, 30 Mar 2001 12:31:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13260; Fri, 30 Mar 2001 12:23:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13228 for ; Fri, 30 Mar 2001 12:23:05 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27121 for ; Fri, 30 Mar 2001 12:23:06 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A0B4F01B6; Fri, 30 Mar 2001 12:21:56 -0500 Message-ID: <012a01c0b93d$36898660$3700000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" , References: <001001c0b936$66307c40$6401010a@mcit.com> Subject: Re: [midcom] SIP MIDCOM flow... Date: Fri, 30 Mar 2001 12:16:50 -0500 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit see embedded comments below ----- Original Message ----- From: "Christopher A. Martin" To: Sent: Friday, March 30, 2001 11:28 AM Subject: RE: [midcom] SIP MIDCOM flow... > To simplify things a bit, in relation to SIP, I thought that I would add > this call flow to the mix. Middlebox control messages are merely examples. > > SIP UA SIP Middle Internal > Client Proxy Box SIP Client > | | | | > |----INVITE------>| | | > | |-----INVITE--->| | > |<---100Trying----| | | > | |----Initiate-->| | > | |<-Initiated----| | > | | |-INVITE-->| > | |<-----180Ringing----------| > |<--180Ringing----| | | > | |<-------200 OK------------| > |<---200 OK ------| | | > | |----OPEN Hole->| | > | |<-OPEN Hole----| | > |-------ACK------>| | | > | |-----------ACK------------| > | | | | > |<-------------------RTP/RTCP--------------->| > | | | | > |-------BYE------>| | | > | |----Terminate->| | > | |<-Terminating--| | > | | |----BYE-->| > | |<----------200 OK---------| > | |----CloseHole->| | > | |<---CloseHole--| | > |<---200 OK-------| | | > | | | | > > This flow describes a call from start to finish. > > I believe the "Initiate" is required to obtain a NAT'd address from the middlebox to put in the session description (SDP) of the INVITE. This is to tell the SIP Client (called party) where to send its RTP messages (this will be an address and port on the Middlebox). The INVITE should not stop at the Middlebox (if the middlebox can talk SIP, there's no need for MIDCOM), but should go from the SIP Proxy to the SIP Client after the "Initiate" transaction with the Middlebox. Assuming the session description (SDP) is in the 200 OK response, the "OPEN Hole" would open the hole and obtain a NAT'd address to put in that session description to tell the SIP UA Client (calling party) where to send its RTP (again an address and port on the Middlebox). If NAT is not needed, then the "Initiate" would only be required if you wanted to "reserve" ports on the Middlebox before letting the call go thru. Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 (781) 933-6166 bpenfield@acmepacket.com > > -----Original Message----- > > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > > Bob Penfield > > Sent: Friday, March 30, 2001 8:26 AM > > To: lear@cisco.com; George Michaelson > > Cc: midcom@ietf.org > > Subject: Re: [midcom] SIP MIDCOM flow... > > > > > > see comments below > > > > > > ----- Original Message ----- > > From: "George Michaelson" > > To: > > Cc: > > Sent: Thursday, March 29, 2001 9:19 PM > > Subject: Re: [midcom] SIP MIDCOM flow... > > > > > > > > > > Hi, > > > > > > Can someone help me fill in the missing pieces in the > > following diagram? > > > I'm trying to understand the flow of communication. > > > > > > > > > _________ > > > --->| SIP |<-----\ > > > / | Proxy | \ > > > | |_________| | > > > 1| | | 1a| > > > | | | | > > > |4 |2 |3 |1b > > > _________ | | | \ ________ > > > | Outside |<--/ _v_____^___ \->| | > > > |SIP Phone| a | | c | Inside | > > > | |>------->| MiddleBox |>------->| SIP | > > > |_________|<-------<|___________|<-------<| Phone | > > > b d |________| > > > > > > Note that 1/4 is a request/response respectively. > > > > There is a missing request/response (I've added 1a+1b above) > > from the SIP > > Proxy to the Inside SIP Phone. Note that 1+4 and/or 1a+1b may > > go thru the > > MiddleBox for NAT/Firewall, but that rule would have been previously > > estabished. > > > > > > > > I have labelled the other paths {a,b,c,d} to make it plain > > they aren't > > > ordered. Your question lies in the space: > > > > > > "what order do {a,b,c,d} take place" > > > > > These represent the RTP flow for the session and it does not > > really matter > > whether a or d is first. None of them can begin until the > > NAT/forwarding > > rules (forward a to c and d to b) are installed by the 2+3 > > transaction from > > the proxy. > > > > > and one presumes there are sequencing differences if c > > predicates 3-4 > > > being done etc etc. > > > > > > ie, in a 3-way endpoint dialogue, is there end-to-end-ness for all 3 > > parties? > > > > > > (middlebox is being directed in this exchange. > > circumstances where it says > > > "no" seem to me to under constrains coming from other > > places. Or does it > > have > > > rigid policy embedded? are there other paths left out for > > simplicity?) > > > > > > -George > > > > > > -- > > > George Michaelson | DSTC Pty Ltd > > > Email: ggm@dstc.edu.au | University of Qld 4072 > > > Phone: +61 7 3365 4310 | Australia > > > Fax: +61 7 3365 4311 | http://www.dstc.edu.au > > > > > > _______________________________________________ > > > midcom mailing list > > > midcom@ietf.org > > > http://www.ietf.org/mailman/listinfo/midcom > > > > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 13:09:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00866 for ; Fri, 30 Mar 2001 13:08:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13871; Fri, 30 Mar 2001 13:00:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13830 for ; Fri, 30 Mar 2001 12:59:59 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00206 for ; Fri, 30 Mar 2001 13:00:02 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GB000N4SVAS2F@firewall.mcit.com> for midcom@ietf.org; Fri, 30 Mar 2001 17:59:16 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GB000I01VAGDU@dgismtp01.wcomnet.com>; Fri, 30 Mar 2001 17:59:16 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GB000FNJVAE3D@dgismtp01.wcomnet.com>; Fri, 30 Mar 2001 17:59:03 +0000 (GMT) Date: Fri, 30 Mar 2001 11:58:57 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] SIP MIDCOM flow... In-reply-to: <012a01c0b93d$36898660$3700000a@acmepacket.com> To: "'Bob Penfield'" , "'midcom mail-list'" Reply-to: christopher.a.martin@wcom.com Message-id: <001c01c0b943$18776880$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Bob, Here is the corrected Call flow, other comments inline: SIP UA SIP/CTRL Middle Internal Client Proxy Box SIP Client | | | | |----INVITE------>| | | | |----Initiate-->| | | |<-Initiated----| | | | | | | |--------INVITE----------->| |<---100Trying----| | | | | | | | |<-----180Ringing----------| |<--180Ringing----| | | | |<-------200 OK------------| |<---200 OK ------| | | | |----OPEN Hole->| | | |<-OPEN Hole----| | |-------ACK------>| | | | |-----------ACK------------| | | | | |<-------------------RTP/RTCP--------------->| | | | | |-------BYE------>| | | | |----Terminate->| | | |<-Terminating--| | | | |----BYE-->| | |<----------200 OK---------| | |----CloseHole->| | | |<---CloseHole--| | |<---200 OK-------| | | | | | | > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Bob Penfield > Sent: Friday, March 30, 2001 11:17 AM > To: midcom mail-list; christopher.a.martin@wcom.com > Subject: Re: [midcom] SIP MIDCOM flow... > > > see embedded comments below > > ----- Original Message ----- > From: "Christopher A. Martin" > To: > Sent: Friday, March 30, 2001 11:28 AM > Subject: RE: [midcom] SIP MIDCOM flow... > > > > To simplify things a bit, in relation to SIP, I thought > that I would add > > this call flow to the mix. Middlebox control messages are > merely examples. > > > > SIP UA SIP Middle Internal > > Client Proxy Box SIP Client > > | | | | > > |----INVITE------>| | | > > | |-----INVITE--->| | > > |<---100Trying----| | | > > | |----Initiate-->| | > > | |<-Initiated----| | > > | | |-INVITE-->| > > | |<-----180Ringing----------| > > |<--180Ringing----| | | > > | |<-------200 OK------------| > > |<---200 OK ------| | | > > | |----OPEN Hole->| | > > | |<-OPEN Hole----| | > > |-------ACK------>| | | > > | |-----------ACK------------| > > | | | | > > |<-------------------RTP/RTCP--------------->| > > | | | | > > |-------BYE------>| | | > > | |----Terminate->| | > > | |<-Terminating--| | > > | | |----BYE-->| > > | |<----------200 OK---------| > > | |----CloseHole->| | > > | |<---CloseHole--| | > > |<---200 OK-------| | | > > | | | | > > > > This flow describes a call from start to finish. > > > > > I believe the "Initiate" is required to obtain a NAT'd > address from the > middlebox to put in the session description (SDP) of the > INVITE. >This is to > tell the SIP Client (called party) where to send its RTP > messages (this will > be an address and port on the Middlebox). The INVITE should > not stop at the > Middlebox (if the middlebox can talk SIP, there's no need for > MIDCOM), but > should go from the SIP Proxy to the SIP Client after the "Initiate" > transaction with the Middlebox. Excellent point. I have revised the call flow above accordingly. >Assuming the session > description (SDP) is in > the 200 OK response, the "OPEN Hole" would open the hole and > obtain a NAT'd > address to put in that session description to tell the SIP UA Client > (calling party) where to send its RTP (again an address and > port on the > Middlebox). > > If NAT is not needed, then the "Initiate" would only be > required if you > wanted to "reserve" ports on the Middlebox before letting the > call go thru. Initiate would be required (I am assuming the intiate function as being an authentication phase or such mechanism to begin the process of opening holes in a secure manner)if for nothing more than to merely open the holes, even in the case of no NAT, I believe. > > Bob > d:-) > > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > (781) 933-6166 > bpenfield@acmepacket.com > > > > > -----Original Message----- > > > From: midcom-admin@ietf.org > [mailto:midcom-admin@ietf.org]On Behalf Of > > > Bob Penfield > > > Sent: Friday, March 30, 2001 8:26 AM > > > To: lear@cisco.com; George Michaelson > > > Cc: midcom@ietf.org > > > Subject: Re: [midcom] SIP MIDCOM flow... > > > > > > > > > see comments below > > > > > > > > > ----- Original Message ----- > > > From: "George Michaelson" > > > To: > > > Cc: > > > Sent: Thursday, March 29, 2001 9:19 PM > > > Subject: Re: [midcom] SIP MIDCOM flow... > > > > > > > > > > > > > > Hi, > > > > > > > > Can someone help me fill in the missing pieces in the > > > following diagram? > > > > I'm trying to understand the flow of communication. > > > > > > > > > > > > _________ > > > > --->| SIP |<-----\ > > > > / | Proxy | \ > > > > | |_________| | > > > > 1| | | 1a| > > > > | | | | > > > > |4 |2 |3 |1b > > > > _________ | | | \ ________ > > > > | Outside |<--/ _v_____^___ \->| | > > > > |SIP Phone| a | | c | Inside | > > > > | |>------->| MiddleBox |>------->| SIP | > > > > |_________|<-------<|___________|<-------<| Phone | > > > > b d |________| > > > > > > > > Note that 1/4 is a request/response respectively. > > > > > > There is a missing request/response (I've added 1a+1b above) > > > from the SIP > > > Proxy to the Inside SIP Phone. Note that 1+4 and/or 1a+1b may > > > go thru the > > > MiddleBox for NAT/Firewall, but that rule would have been > previously > > > estabished. > > > > > > > > > > > I have labelled the other paths {a,b,c,d} to make it plain > > > they aren't > > > > ordered. Your question lies in the space: > > > > > > > > "what order do {a,b,c,d} take place" > > > > > > > These represent the RTP flow for the session and it does not > > > really matter > > > whether a or d is first. None of them can begin until the > > > NAT/forwarding > > > rules (forward a to c and d to b) are installed by the 2+3 > > > transaction from > > > the proxy. > > > > > > > and one presumes there are sequencing differences if c > > > predicates 3-4 > > > > being done etc etc. > > > > > > > > ie, in a 3-way endpoint dialogue, is there > end-to-end-ness for all 3 > > > parties? > > > > > > > > (middlebox is being directed in this exchange. > > > circumstances where it says > > > > "no" seem to me to under constrains coming from other > > > places. Or does it > > > have > > > > rigid policy embedded? are there other paths left out for > > > simplicity?) > > > > > > > > -George > > > > > > > > -- > > > > George Michaelson | DSTC Pty Ltd > > > > Email: ggm@dstc.edu.au | University of Qld 4072 > > > > Phone: +61 7 3365 4310 | Australia > > > > Fax: +61 7 3365 4311 | http://www.dstc.edu.au > > > > > > > > _______________________________________________ > > > > midcom mailing list > > > > midcom@ietf.org > > > > http://www.ietf.org/mailman/listinfo/midcom > > > > > > > > > > > > > _______________________________________________ > > > midcom mailing list > > > midcom@ietf.org > > > http://www.ietf.org/mailman/listinfo/midcom > > > > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 13:10:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00951 for ; Fri, 30 Mar 2001 13:10:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14157; Fri, 30 Mar 2001 13:04:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14129 for ; Fri, 30 Mar 2001 13:04:24 -0500 (EST) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00555 for ; Fri, 30 Mar 2001 13:04:26 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 8B9CD81A6 for ; Fri, 30 Mar 2001 12:03:56 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id MAA28511 for ; Fri, 30 Mar 2001 12:04:36 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 30 Mar 2001 12:04:36 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] SIP MIDCOM flow... In-Reply-To: <012a01c0b93d$36898660$3700000a@acmepacket.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 30 Mar 2001, Bob Penfield wrote: > > > I believe the "Initiate" is required to obtain a NAT'd address from the > middlebox to put in the session description (SDP) of the INVITE. This is to > tell the SIP Client (called party) where to send its RTP messages (this will > be an address and port on the Middlebox). The INVITE should not stop at the > Middlebox (if the middlebox can talk SIP, there's no need for MIDCOM), but > should go from the SIP Proxy to the SIP Client after the "Initiate" > transaction with the Middlebox. Assuming the session description (SDP) is in > the 200 OK response, the "OPEN Hole" would open the hole and obtain a NAT'd > address to put in that session description to tell the SIP UA Client > (calling party) where to send its RTP (again an address and port on the > Middlebox). A couple of remarks. It is definitely necessary to talk to the middlebox before forwarding the INVITE, yes. And the reason is as indicated. The INVITE may be considered to hit the middlebox or to flow through it. Since the middlebox, as indicated, more or less by definition doesn't DO anything to the INVITE I think it's simplest to designate it as flowing through it. I always flow signaling through my middleboxes when I am drawing these things. The address/port returned by the middlebox in response to the "Initiate" (I MUCH prefer talking about bind requests and responses, rather than a generic "Initiate" by the way) may or may not be an address/port on the middlebox. If the middlebox is a proper NAT, the address is just an address drawn from the pool of addresses available on the relevent side of the middlebox. If the middlebox is a general purpose UDP plugboard box, then the IP address of the middlebox might indeed be used. However, it doesn't matter. The point of a NAT bind request is 'gimme an address/port I can use on THAT side to get to this address/port on THIS side.' How the middlebox scrapes these addresses and ports up doesn't matter. I enclose some material I submitted to the foglamps list a while back which might make more sense in the current context. In these flows, "Call Initiate" is synonymous with INVITE and ACK is (confusingly) synonymous with 200 OK, and there is no equivalent of the actual SIP ACK. Since the SIP ACK happens after all the good stuff is over, this probably isn't very important, though implementations may choose to use it to drive state machines in interesting and useful ways. At this high level of abstraction, I feel comfortable ignoring SIP ACKs. ----------------------------------------------------------------- Sample Flows ============ These are modeled on typical IP telephony call flows, and assume a magical NAT/Firewall Middlebox device. A and B represent two different networks, each with an Application controlling a Middlebox, the latter located at the perimeter. In these flows, the X's and Y's represent abstract endpoint addresses, typically the combination of an IP address with a port, and a transport protocol (possibly implicitly specified). The middlebox communication protocol should be sufficiently rich and expressive to support these operations. Simple Egress Firewall Control ------------------------------ In this case, we have only our A network, with some controlling application and a Middlebox performing normal perimeter firewalling work. The Call Initiate winds up, through mechanisms far outside the scope of this document, at a destination, Y, which replies with an ACK. In this scenario, pinholes are opened only after the ACK from Y is received. It may be desirable (e.g. early media) to open the inbound pinhole earlier (see below). Application A MidBox A | | Call Initiate | from X | | ------------>| | | Call Initiate | From X |----------------------> | | | | | ACK From Y |<----------------------- | | | Open Pinhole | | X --> Y | |(or * --> Y ?)| |------------->| | ACK Pinhole | |<-------------| | | | Open Pinhole | | X <-- Y | |(or X <-- * ?)| |------------->| | ACK Pinhole | |<-------------| | | | | ACK From Y | | <-------------| | Simple Egress Firewall Control Case II -- "Early Media" ------------------------------------------------------- This is the same as the previous example, except that the inbound pinhole is opened earlier. Note that in this case there is no ambiguity about wildcarding the first pinhole -- in general the remote WILL NOT be known at this point, so the pinhole almost certainly must be wildcarded. Application A MidBox A | | Call Initiate | from X | | ------------>| | | | | Open Pinhole | | X <-- * | |------------->| | ACK Pinhole | |<-------------| | | | Call Initiate | From X |----------------------> | | | | | ACK From Y |<----------------------- | Media from Y -> X Media |<----------------------- <-------------| | | | Open Pinhole | | X --> Y | |(or * --> Y ?)| |------------->| | ACK Pinhole | |<-------------| | | ACK From Y | | <-------------| | Clearly, in the case of a NACK from Y or a timeout, the pinhole needs to be closed. This makes this scenario more of a hassle to implement, though it will work quite a bit better in some cases. Simple Egress NAT Control ------------------------- In this example, we worry only about an egress NAT device. This is somewhat artificial, since a firewall is generally also present. However, it is illustrative. Application A MidBox A | | Call Initiate | from X | | ------------>| | | | | NAT REQ | | Target: X | | Source: * | |------------->| | NAT RESP | | Map: X -> X1 | |<-------------| | | | Call Initiate | From X1 |----------------------> | | | | | ACK From Y |<----------------------- | | ACK From Y | | <-------------| | Note that the Call Initiate sent outwards to the world is not from X but from the translated address X1. All Singing All Dancing Firewall+NAT Across Two Networks -------------------------------------------------------- Application A MidBox A MidBox B Application B | | | | Call Initiate | | | from X | | | | -------->| NAT REQ | | | |------------->| | | | Target: X | | | | Source: * | | | | | | | | NAT RESP | | | | Map: X->X1 | | | |<-------------| | | | | | | | Call Initiate From X1| | |-------------------------------------------------->| (locate dest | | | | at Y and fwd | | | | initiate) | | | | | | | | ACK from Y | | | |<----------- | | | NAT REQ | | | | Target: Y | | | | Source: * | | | |<---------------| | | | | | | | NAT RESP | | | | Map: Y->Y1 | | | |--------------->| | | | | | | | Open Pinhole | | | | X1 --> Y1 | | | |(or * --> Y1?) | | | |<---------------| | | | ACK Pinhole | | | |--------------->| | | | | | | | Open Pinhole | | | | X1 <-- Y1 | | | |(or X1 <-- * ?) | | | |<---------------| | | | ACK Pinhole | | | |--------------->| | | ACK From Y1 | | |<--------------------------------------------------| | | | | | Open Pinhole | | | | X1 --> Y1 | | | |(or * --> Y1?)| | | |------------->| | | | ACK Pinhole | | | |<-------------| | | | | | | | Open Pinhole | | | | X1 <-- Y1 | | | |(or X1 <-- *?)| | | |------------->| | | | ACK Pinhole | | | |<-------------| | | | | | | | | | | ACK From | | | | Y1 | | | | <--------| | | | Note that there is an issue of whether pinholes are opened for pre-NAT addresses, post-NAT addresses, Internal addresses or External Addresses (there are indeed 4 cases). Indicated above, pinholes are indicated for External addresses. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 13:31:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02910 for ; Fri, 30 Mar 2001 13:31:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14592; Fri, 30 Mar 2001 13:26:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14545 for ; Fri, 30 Mar 2001 13:26:36 -0500 (EST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02424 for ; Fri, 30 Mar 2001 13:26:38 -0500 (EST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id SAA15618 for ; Fri, 30 Mar 2001 18:26:34 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 30 Mar 2001 18:26:32 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Mar 2001 10:26:30 -0800 Message-ID: <856592CED9BBD211AC3E00A0C967ED7A05618C24@orsmsx51.jf.intel.com> From: "Anderson, Todd A" To: "'midcom@ietf.org'" Subject: RE: [midcom] SIP MIDCOM flow... Date: Fri, 30 Mar 2001 10:26:25 -0800 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org In the hangup sequence, am I wrong in my understanding that the SIP proxy should send the bye to the internal client and not the middlebox? Diagram updated to reflect this sequence. SIP UA SIP/CTRL Middle Internal Client Proxy Box SIP Client | | | | |----INVITE------>| | | | |----Initiate-->| | | |<-Initiated----| | | | | | | |--------INVITE----------->| |<---100Trying----| | | | | | | | |<-----180Ringing----------| |<--180Ringing----| | | | |<-------200 OK------------| |<---200 OK ------| | | | |----OPEN Hole->| | | |<-OPEN Hole----| | |-------ACK------>| | | | |-----------ACK----------->| | | | | |<-------------------RTP/RTCP--------------->| | | | | |-------BYE------>| | | | |----Terminate->| | | |<-Terminating--| | | | | | | |-----------BYE----------->| | |<----------200 OK---------| | | | | | |----CloseHole->| | | |<---CloseHole--| | |<---200 OK-------| | | | | | | Just for my own understanding, why are terminate and closehole in the order presented here? My intuition would say to unroll the stack as it were and closehole first followed by terminate. Either of these seems to have the problem though that it causes the bye and 200 OK between the proxy and the internal client to fail, either because there is no NAT binding or no pinhole to go through. Why wouldn't the following work? Would appreciate someone to educate me on this issue. | | | | |-------BYE------>| | | | |-----------BYE----------->| | |<----------200 OK---------| | | | | | |----CloseHole->| | | |<---CloseHole--| | | | | | | |----Terminate->| | | |<-Terminating--| | |<---200 OK-------| | | | | | | Todd _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 13:37:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03424 for ; Fri, 30 Mar 2001 13:37:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14690; Fri, 30 Mar 2001 13:29:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14657 for ; Fri, 30 Mar 2001 13:29:41 -0500 (EST) Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02707 for ; Fri, 30 Mar 2001 13:29:43 -0500 (EST) Received: from condryvaio-desk.intel.com (condryvaio-desk.jf.intel.com [134.134.159.68]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with ESMTP id SAA02415; Fri, 30 Mar 2001 18:29:38 GMT Message-Id: <5.0.2.1.2.20010330102532.019ad740@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 30 Mar 2001 10:27:49 -0800 To: Andrew Molitor , midcom@ietf.org From: "Michael W. Condry" Subject: Re: [midcom] Protocol Requirements - Cc: midtax@lists.hactrn.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org is there some consistency that the MidTax folks are supposed to define here? At 05:36 PM 3/26/2001 -0600, Andrew Molitor wrote: > Since the issue of what goes IN to a requirements document has >been resolved to 'requirements for a middlebox control protocol' I will >now trot out the bullet list of protocol requirements I have. Feel >free to shoot at it. If/when I peceive rough consensus having been >acheived, I will more carefully format and submit more formally to the >editor. > > Throughout, I use this terminology: > > Client - something that requests pinholes pinholes and > NAT bindings. For example, a MIDCOM aware ALG or > SIP proxy. > > Server - something which is spoken to by a client. By implication, > a Server resides in (logically, if not literally) a > Middlebox, and exposes the services of that Middlebox > to Clients. > > Middlebox - a firewall or NAT device which is coupled to a > MIDCOM server, which offers the firewall/NAT services > to Clients. > > Do we want to require a 1-to-1 relationship between Servers >and Middleboxes? > > Protocol requirements in no particular order: > >General Stuff >============= > - must operate over standard IP transports, UDP required, TCP > optional. > > - should be transport independent, a la SIP. > > - must support high transaction throughput over highish > latency networks (read: must support message streaming.) > > - must support one or more strong authentication models. > > - should support one or more privacy models (I am weak on this > because, in general, not much you are saying is a big > secret -- traffic flows will pretty much reveal the state > of the box anyways) > > - must support client-to-server request/response transactions. > > - must support server-to-client informational messages (or > transactions?) > > - must support models in which multiple clients talk to > multiple servers. > >Specific Operations/Scenarios > > Note that these are protocol requirements, not box >requirements. So, while the protocol must support the ability >of a client to ask for a pinhole, the protocol also allows >for a middlebox to return 'NO - I am a NAT, dummy.' > > - must support a client-to-server transaction which returns > the middlebox capabilities to the client. These capabilities > should include, but not be restricted to: > - firewalling > - NAT (including port translations) > - QoS > - Plumbing information (where does NAT fit > relative to other elements, specifically, > THIS MATTERS!) > > - must support a client-to-server transaction to open a > "pinhole" in the middlebox's traffic policy. > > - must support a client-to-server transaction to request > a NAT binding, associating an IP address/port pair on > one interface with an IP address/port pair on another. > > - it would sure be nice if these binding requests could > specify information about the expected source of the > flow initiator. E.G. 'I have a server on the inside > at 192.168.1.99 port 5000, and I think someone on the > outside at address 209.46.41.61, I don't know the port' > will be connecting to my server -- please give me an > address/port I can advertise to the remote as the phone's > address/port' > > - must support a method for mirroring an existing NAT > binding allocated by one middlebox into another middlebox, > for redundancy. There are a few ways to build this, > I don't know or care how the protocol does it, but > this capability must be supported. > > - must support a client-to-server transation to release an > individual NAT binding. > > - must support a client-to-server transation to release an > individual pinhole. > > - should support a way to identify bundles of state (pinholes > and NAT) as belonging to the same group (a "session ID" > specified by the client in a set of requests) > > - should support a client-to-server transaction to delete all > the state bundled under a given session ID. > > - must support a way to specify a desired timeout value for > and piece of state created by a client-to-server transaction. > > - should support both activity based timeouts as well as > absolute timeouts (i.e. support both 'if you don't see any > packets for 60 seconds, please make this NAT binding go > away by itself' AND 'make this NAT binding go away in 60 > seconds') > > - must support client-to-server transactions to query middlebox > state, including but not restricted to: > > - currently installed pinholes > - currently installed NAT bindings > - statistics of various sorts > > - should support a client-to-server transation allowing the > client to register to receive notifications of various > sorts from the server. > > - should support some server-to-client transactions to inform > the client of events such as: > > - timeouts of pinholes and NATs > - violations of policy > - other? > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >http://www.ietf.org/mailman/listinfo/midcom Michael W. Condry Director, Network Edge Technology _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 14:05:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05639 for ; Fri, 30 Mar 2001 14:05:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15070; Fri, 30 Mar 2001 13:36:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15038 for ; Fri, 30 Mar 2001 13:36:43 -0500 (EST) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03357 for ; Fri, 30 Mar 2001 13:36:45 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA05590; Fri, 30 Mar 2001 13:40:04 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Mar 2001 13:36:40 -0500 Message-ID: From: Tim Rang To: "'Anderson, Todd A'" , "'midcom@ietf.org'" Subject: RE: [midcom] SIP MIDCOM flow... Date: Fri, 30 Mar 2001 13:36:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > -----Original Message----- > From: Anderson, Todd A [mailto:todd.a.anderson@intel.com] > Sent: Friday, March 30, 2001 1:26 PM > To: 'midcom@ietf.org' > Subject: RE: [midcom] SIP MIDCOM flow... > > > In the hangup sequence, am I wrong in my understanding that > the SIP proxy > should send the bye to the internal client and not the > middlebox? Diagram > updated to reflect this sequence. > > SIP UA SIP/CTRL Middle Internal > Client Proxy Box SIP Client > | | | | > |----INVITE------>| | | > | |----Initiate-->| | > | |<-Initiated----| | > | | | | > | |--------INVITE----------->| > |<---100Trying----| | | > | | | | > | |<-----180Ringing----------| > |<--180Ringing----| | | > | |<-------200 OK------------| > |<---200 OK ------| | | > | |----OPEN Hole->| | > | |<-OPEN Hole----| | > |-------ACK------>| | | > | |-----------ACK----------->| > | | | | > |<-------------------RTP/RTCP--------------->| > | | | | > |-------BYE------>| | | > | |----Terminate->| | > | |<-Terminating--| | > | | | | > | |-----------BYE----------->| > | |<----------200 OK---------| > | | | | > | |----CloseHole->| | > | |<---CloseHole--| | > |<---200 OK-------| | | > | | | | > > Just for my own understanding, why are terminate and > closehole in the order > presented here? My intuition would say to unroll the stack > as it were and > closehole first followed by terminate. Either of these seems > to have the > problem though that it causes the bye and 200 OK between the > proxy and the > internal client to fail, either because there is no NAT binding or no > pinhole to go through. Why wouldn't the following work? > Would appreciate > someone to educate me on this issue. > > | | | | > |-------BYE------>| | | > | |-----------BYE----------->| > | |<----------200 OK---------| > | | | | > | |----CloseHole->| | > | |<---CloseHole--| | > | | | | > | |----Terminate->| | > | |<-Terminating--| | > |<---200 OK-------| | | > | | | | > > Todd > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > Both MAY be acceptable. I don't think that the way someone draws the picture (or builds their proxy for that matter) is so important to us as making sure all of the potentially required operations are represented. I think either the original drawing or the latest will work depending upon what you are looking for. The only thing in the call flow that is absolutely prescribed for SIP to work is that a translation be obtained before the INVITE and SDP containing response are forwarded for purposes already stated. Whether someone does a hole open on the 200 or the ACK and whether a hole is closed after the BYE or the 200 to the BYE is a matter of what you are trying to accomplish. Tim Rang _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 14:12:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06363 for ; Fri, 30 Mar 2001 14:12:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15656; Fri, 30 Mar 2001 14:04:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15628 for ; Fri, 30 Mar 2001 14:04:50 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05590 for ; Fri, 30 Mar 2001 14:04:51 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A88C2A90122; Fri, 30 Mar 2001 14:03:40 -0500 Message-ID: <018401c0b94b$5f87e080$3700000a@acmepacket.com> From: "Bob Penfield" To: "Anderson, Todd A" , References: <856592CED9BBD211AC3E00A0C967ED7A05618C24@orsmsx51.jf.intel.com> Subject: Re: [midcom] SIP MIDCOM flow... Date: Fri, 30 Mar 2001 13:58:11 -0500 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Anderson, Todd A" To: Sent: Friday, March 30, 2001 1:26 PM Subject: RE: [midcom] SIP MIDCOM flow... > In the hangup sequence, am I wrong in my understanding that the SIP proxy > should send the bye to the internal client and not the middlebox? Diagram > updated to reflect this sequence. Correct. > > SIP UA SIP/CTRL Middle Internal > Client Proxy Box SIP Client > | | | | > |----INVITE------>| | | > | |----Initiate-->| | > | |<-Initiated----| | > | | | | > | |--------INVITE----------->| > |<---100Trying----| | | > | | | | > | |<-----180Ringing----------| > |<--180Ringing----| | | > | |<-------200 OK------------| > |<---200 OK ------| | | > | |----OPEN Hole->| | > | |<-OPEN Hole----| | > |-------ACK------>| | | > | |-----------ACK----------->| > | | | | > |<-------------------RTP/RTCP--------------->| > | | | | > |-------BYE------>| | | > | |----Terminate->| | > | |<-Terminating--| | > | | | | > | |-----------BYE----------->| > | |<----------200 OK---------| > | | | | > | |----CloseHole->| | > | |<---CloseHole--| | > |<---200 OK-------| | | > | | | | > > Just for my own understanding, why are terminate and closehole in the order > presented here? My intuition would say to unroll the stack as it were and > closehole first followed by terminate. Either of these seems to have the > problem though that it causes the bye and 200 OK between the proxy and the > internal client to fail, either because there is no NAT binding or no > pinhole to go through. Why wouldn't the following work? Would appreciate > someone to educate me on this issue. > > | | | | > |-------BYE------>| | | > | |-----------BYE----------->| > | |<----------200 OK---------| > | | | | > | |----CloseHole->| | > | |<---CloseHole--| | > | | | | > | |----Terminate->| | > | |<-Terminating--| | > |<---200 OK-------| | | > | | | | > > Todd > Are these really 2 different functions? or can they be done as 1? If it is just a NAT, you don't need to close the hole. Also, there is no need for the proxy to hold on to the BYE while communicating with the middlebox. Doing this may cause the calling side to re-transmit the BYE. > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 14:48:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09306 for ; Fri, 30 Mar 2001 14:48:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16319; Fri, 30 Mar 2001 14:40:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16291 for ; Fri, 30 Mar 2001 14:40:00 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08570 for ; Fri, 30 Mar 2001 14:40:01 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA25546; Fri, 30 Mar 2001 11:39:18 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA23588; Fri, 30 Mar 2001 11:39:23 -0800 Message-ID: <3AC4DD51.3391B84A@hursley.ibm.com> Date: Fri, 30 Mar 2001 13:24:01 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Michael W. Condry" CC: Andrew Molitor , midcom@ietf.org, midtax@lists.hactrn.net Subject: Re: [midcom] Protocol Requirements - References: <5.0.2.1.2.20010330102532.019ad740@FMSMSX63.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Well, I hadn't thought of doing formal terminology as part of the midtax effort... would it be useful? Brian "Michael W. Condry" wrote: > > is there some consistency that the MidTax folks are supposed > to define here? > At 05:36 PM 3/26/2001 -0600, Andrew Molitor wrote: > > > Since the issue of what goes IN to a requirements document has > >been resolved to 'requirements for a middlebox control protocol' I will > >now trot out the bullet list of protocol requirements I have. Feel > >free to shoot at it. If/when I peceive rough consensus having been > >acheived, I will more carefully format and submit more formally to the > >editor. > > > > Throughout, I use this terminology: > > > > Client - something that requests pinholes pinholes and > > NAT bindings. For example, a MIDCOM aware ALG or > > SIP proxy. > > > > Server - something which is spoken to by a client. By implication, > > a Server resides in (logically, if not literally) a > > Middlebox, and exposes the services of that Middlebox > > to Clients. > > > > Middlebox - a firewall or NAT device which is coupled to a > > MIDCOM server, which offers the firewall/NAT services > > to Clients. > > > > Do we want to require a 1-to-1 relationship between Servers > >and Middleboxes? > > > > Protocol requirements in no particular order: > > > >General Stuff > >============= > > - must operate over standard IP transports, UDP required, TCP > > optional. > > > > - should be transport independent, a la SIP. > > > > - must support high transaction throughput over highish > > latency networks (read: must support message streaming.) > > > > - must support one or more strong authentication models. > > > > - should support one or more privacy models (I am weak on this > > because, in general, not much you are saying is a big > > secret -- traffic flows will pretty much reveal the state > > of the box anyways) > > > > - must support client-to-server request/response transactions. > > > > - must support server-to-client informational messages (or > > transactions?) > > > > - must support models in which multiple clients talk to > > multiple servers. > > > >Specific Operations/Scenarios > > > > Note that these are protocol requirements, not box > >requirements. So, while the protocol must support the ability > >of a client to ask for a pinhole, the protocol also allows > >for a middlebox to return 'NO - I am a NAT, dummy.' > > > > - must support a client-to-server transaction which returns > > the middlebox capabilities to the client. These capabilities > > should include, but not be restricted to: > > - firewalling > > - NAT (including port translations) > > - QoS > > - Plumbing information (where does NAT fit > > relative to other elements, specifically, > > THIS MATTERS!) > > > > - must support a client-to-server transaction to open a > > "pinhole" in the middlebox's traffic policy. > > > > - must support a client-to-server transaction to request > > a NAT binding, associating an IP address/port pair on > > one interface with an IP address/port pair on another. > > > > - it would sure be nice if these binding requests could > > specify information about the expected source of the > > flow initiator. E.G. 'I have a server on the inside > > at 192.168.1.99 port 5000, and I think someone on the > > outside at address 209.46.41.61, I don't know the port' > > will be connecting to my server -- please give me an > > address/port I can advertise to the remote as the phone's > > address/port' > > > > - must support a method for mirroring an existing NAT > > binding allocated by one middlebox into another middlebox, > > for redundancy. There are a few ways to build this, > > I don't know or care how the protocol does it, but > > this capability must be supported. > > > > - must support a client-to-server transation to release an > > individual NAT binding. > > > > - must support a client-to-server transation to release an > > individual pinhole. > > > > - should support a way to identify bundles of state (pinholes > > and NAT) as belonging to the same group (a "session ID" > > specified by the client in a set of requests) > > > > - should support a client-to-server transaction to delete all > > the state bundled under a given session ID. > > > > - must support a way to specify a desired timeout value for > > and piece of state created by a client-to-server transaction. > > > > - should support both activity based timeouts as well as > > absolute timeouts (i.e. support both 'if you don't see any > > packets for 60 seconds, please make this NAT binding go > > away by itself' AND 'make this NAT binding go away in 60 > > seconds') > > > > - must support client-to-server transactions to query middlebox > > state, including but not restricted to: > > > > - currently installed pinholes > > - currently installed NAT bindings > > - statistics of various sorts > > > > - should support a client-to-server transation allowing the > > client to register to receive notifications of various > > sorts from the server. > > > > - should support some server-to-client transactions to inform > > the client of events such as: > > > > - timeouts of pinholes and NATs > > - violations of policy > > - other? > > > > > >_______________________________________________ > >midcom mailing list > >midcom@ietf.org > >http://www.ietf.org/mailman/listinfo/midcom > > Michael W. Condry > Director, Network Edge Technology > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 15:06:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10541 for ; Fri, 30 Mar 2001 15:06:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16597; Fri, 30 Mar 2001 14:57:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16540 for ; Fri, 30 Mar 2001 14:57:02 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09840 for ; Fri, 30 Mar 2001 14:57:03 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GB1005DF0P692@firewall.mcit.com> for midcom@ietf.org; Fri, 30 Mar 2001 19:55:54 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GB100B010OTIZ@dgismtp01.wcomnet.com>; Fri, 30 Mar 2001 19:55:53 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GB1009EH0OM4J@dgismtp01.wcomnet.com>; Fri, 30 Mar 2001 19:55:34 +0000 (GMT) Date: Fri, 30 Mar 2001 13:55:27 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] SIP MIDCOM flow... In-reply-to: To: "'Andrew Molitor'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <002b01c0b953$5e97ba80$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Andrew Molitor > Sent: Friday, March 30, 2001 12:05 PM > To: midcom@ietf.org > Subject: Re: [midcom] SIP MIDCOM flow... > > > > > On Fri, 30 Mar 2001, Bob Penfield wrote: > > > > > I believe the "Initiate" is required to obtain a NAT'd > address from the > > middlebox to put in the session description (SDP) of the > INVITE. This is to > > tell the SIP Client (called party) where to send its RTP > messages (this will > > be an address and port on the Middlebox). The INVITE should > not stop at the > > Middlebox (if the middlebox can talk SIP, there's no need > for MIDCOM), but > > should go from the SIP Proxy to the SIP Client after the "Initiate" > > transaction with the Middlebox. Assuming the session > description (SDP) is in > > the 200 OK response, the "OPEN Hole" would open the hole > and obtain a NAT'd > > address to put in that session description to tell the SIP UA Client > > (calling party) where to send its RTP (again an address and > port on the > > Middlebox). > > A couple of remarks. > > It is definitely necessary to talk to the middlebox before > forwarding the INVITE, yes. And the reason is as indicated. > > The INVITE may be considered to hit the middlebox or to > flow through it. Since the middlebox, as indicated, more or less by > definition doesn't DO anything to the INVITE I think it's simplest > to designate it as flowing through it. I always flow signaling through > my middleboxes when I am drawing these things. > > The address/port returned by the middlebox in response > to the "Initiate" (I MUCH prefer talking about bind requests and > responses, rather than a generic "Initiate" by the way) may or may not Then the initiate and intiated can be considered BIND REQUEST and BINDING I can change it. The flow is actually meant to represent what a SIP call from beginning to enbd would look like. > be an address/port on the middlebox. If the middlebox is a proper > NAT, the address is just an address drawn from the pool of addresses > available on the relevent side of the middlebox. If the middlebox > is a general purpose UDP plugboard box, then the IP address of the > middlebox might indeed be used. > > However, it doesn't matter. The point of a NAT bind request > is 'gimme an address/port I can use on THAT side to get to this > address/port on THIS side.' How the middlebox scrapes these addresses > and ports up doesn't matter. Actually I consider intiate a way to perform the control that dynamically opens pinholes, irrespective of NAT. Binding for NAT however could be conveyed in the initiate message as part of the process (if it is developed this way). > > I enclose some material I submitted to the foglamps list > a while back which might make more sense in the current context. > In these flows, "Call Initiate" is synonymous with INVITE and > ACK is (confusingly) synonymous with 200 OK, and there is no > equivalent of the actual SIP ACK. Since the SIP ACK happens after > all the good stuff is over, this probably isn't very important, > though implementations may choose to use it to drive state machines > in interesting and useful ways. At this high level of abstraction, > I feel comfortable ignoring SIP ACKs. I thought this would come up so I clarified in a later message (prior to any comments...thinking on the fly) that a portion of the call flow is related to SIP signaling and RTP flow and the rest is for middlebox control. Middlebox control was made up of initiate, initiating, open holes, close holes, and terminate, terminating. The idea here is that I wanted to clarify SIP for those that wished to know the process SIP uses. I will read the following flows in minute, just wanted to address this. Thanks > > ----------------------------------------------------------------- > > Sample Flows > ============ > > These are modeled on typical IP telephony call flows, and > assume a magical NAT/Firewall Middlebox device. A and B represent > two different networks, each with an Application controlling a > Middlebox, the latter located at the perimeter. In these flows, > the X's and Y's represent abstract endpoint addresses, typically > the combination of an IP address with a port, and a transport > protocol (possibly implicitly specified). > > The middlebox communication protocol should be sufficiently > rich and expressive to support these operations. > > Simple Egress Firewall Control > ------------------------------ > > In this case, we have only our A network, with some > controlling application and a Middlebox performing normal perimeter > firewalling work. The Call Initiate winds up, through mechanisms > far outside the scope of this document, at a destination, Y, which > replies with an ACK. > > In this scenario, pinholes are opened only after the ACK > from Y is received. It may be desirable (e.g. early media) to open > the inbound pinhole earlier (see below). > > Application A MidBox A > | | > Call Initiate | > from X | | > ------------>| | > | Call Initiate > | From X > |----------------------> > | | > | | > | ACK From Y > |<----------------------- > | | > | Open Pinhole | > | X --> Y | > |(or * --> Y ?)| > |------------->| > | ACK Pinhole | > |<-------------| > | | > | Open Pinhole | > | X <-- Y | > |(or X <-- * ?)| > |------------->| > | ACK Pinhole | > |<-------------| > | | > | | > ACK From Y | | > <-------------| | > > > Simple Egress Firewall Control Case II -- "Early Media" > ------------------------------------------------------- > > This is the same as the previous example, except that the > inbound pinhole is opened earlier. Note that in this case there is no > ambiguity about wildcarding the first pinhole -- in general the remote > WILL NOT be known at this point, so the pinhole almost certainly must > be wildcarded. > > Application A MidBox A > | | > Call Initiate | > from X | | > ------------>| | > | | > | Open Pinhole | > | X <-- * | > |------------->| > | ACK Pinhole | > |<-------------| > | | > | Call Initiate > | From X > |----------------------> > | | > | | > | ACK From Y > |<----------------------- > | Media from Y -> X > Media |<----------------------- > <-------------| > | | > | Open Pinhole | > | X --> Y | > |(or * --> Y ?)| > |------------->| > | ACK Pinhole | > |<-------------| > | | > ACK From Y | | > <-------------| | > > > Clearly, in the case of a NACK from Y or a timeout, the > pinhole needs > to be closed. This makes this scenario more of a hassle to > implement, though > it will work quite a bit better in some cases. > > > Simple Egress NAT Control > ------------------------- > > In this example, we worry only about an egress NAT > device. This is > somewhat artificial, since a firewall is generally also > present. However, > it is illustrative. > > > Application A MidBox A > | | > Call Initiate | > from X | | > ------------>| | > | | > | NAT REQ | > | Target: X | > | Source: * | > |------------->| > | NAT RESP | > | Map: X -> X1 | > |<-------------| > | | > | Call Initiate > | From X1 > |----------------------> > | | > | | > | ACK From Y > |<----------------------- > | | > ACK From Y | | > <-------------| | > > Note that the Call Initiate sent outwards to the world is > not from X but from the translated address X1. > > > All Singing All Dancing Firewall+NAT Across Two Networks > -------------------------------------------------------- > > Application A MidBox A MidBox B Application B > | | | | > Call Initiate | | | > from X | | | | > -------->| NAT REQ | | | > |------------->| | | > | Target: X | | | > | Source: * | | | > | | | | > | NAT RESP | | | > | Map: X->X1 | | | > |<-------------| | | > | | | | > | Call Initiate From X1| | > > |-------------------------------------------------->| (locate dest > | | | > | at Y and fwd > | | | > | initiate) > | | | | > | | | > | ACK from Y > | | | > |<----------- > | | | NAT REQ | > | | | Target: Y | > | | | Source: * | > | | |<---------------| > | | | | > | | | NAT RESP | > | | | Map: Y->Y1 | > | | |--------------->| > | | | | > | | | Open Pinhole | > | | | X1 --> Y1 | > | | |(or * --> Y1?) | > | | |<---------------| > | | | ACK Pinhole | > | | |--------------->| > | | | | > | | | Open Pinhole | > | | | X1 <-- Y1 | > | | |(or X1 <-- * ?) | > | | |<---------------| > | | | ACK Pinhole | > | | |--------------->| > | | ACK From Y1 | | > |<--------------------------------------------------| > | | | | > | Open Pinhole | | | > | X1 --> Y1 | | | > |(or * --> Y1?)| | | > |------------->| | | > | ACK Pinhole | | | > |<-------------| | | > | | | | > | Open Pinhole | | | > | X1 <-- Y1 | | | > |(or X1 <-- *?)| | | > |------------->| | | > | ACK Pinhole | | | > |<-------------| | | > | | | | > | | | | > ACK From | | | | > Y1 | | | | > <--------| | | | > > Note that there is an issue of whether pinholes are opened > for pre-NAT addresses, post-NAT addresses, Internal addresses or > External Addresses (there are indeed 4 cases). Indicated > above, pinholes > are indicated for External addresses. > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 15:32:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12335 for ; Fri, 30 Mar 2001 15:32:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17054; Fri, 30 Mar 2001 15:25:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17023 for ; Fri, 30 Mar 2001 15:25:00 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11835 for ; Fri, 30 Mar 2001 15:25:00 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA00582; Fri, 30 Mar 2001 12:24:51 -0800 (PST) Received: from SBRIM-W2K.cisco.com (sjc-vpn-86.cisco.com [10.21.64.86]) by airborne.cisco.com (Mirapoint) with ESMTP id AAH11660; Fri, 30 Mar 2001 12:24:26 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15044.60280.832000.612953@gargle.gargle.HOWL> Date: Fri, 30 Mar 2001 15:24:24 -0500 To: Andrew Molitor Cc: midcom@ietf.org Subject: Re: [midcom] Protocol Requirements - In-Reply-To: References: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 26 Mar 2001 at 17:36 -0600, Andrew Molitor apparently wrote: > Throughout, I use this terminology: > > Client - something that requests pinholes pinholes and > NAT bindings. For example, a MIDCOM aware ALG or > SIP proxy. > > Server - something which is spoken to by a client. By implication, > a Server resides in (logically, if not literally) a > Middlebox, and exposes the services of that Middlebox > to Clients. > > Middlebox - a firewall or NAT device which is coupled to a > MIDCOM server, which offers the firewall/NAT services > to Clients. > > Do we want to require a 1-to-1 relationship between Servers > and Middleboxes? Interesting. Am I right in understanding that - your Client is Suresh's Agent, something speaking on behalf of the originating end node - your Server is something which speaks on behalf of the middlebox. ? I thought about whether we needed the extra decoupling and indirection we would get from this kind of Server, and decided we *probably* didn't need it. Something like this might come in handy in the future when we want to make sure we have coordination between middleboxes, but a single client-side agent could probably coordinate its specific protocol realm just as well. So I don't think we need your Server separated from the middlebox. In the future if we need to we can separate them without the rest of the world noticing. > - must operate over standard IP transports, UDP required, TCP > optional. > > - should be transport independent, a la SIP. Why? (You're going to see that question a lot.) btw as I recall SIP's transport independence was added afterward. > - must support high transaction throughput over highish > latency networks (read: must support message streaming.) What are you expecting to carry in this protocol that you would want message streaming? I think of it as a small-message control protocol. > - must support client-to-server request/response transactions. > > - must support server-to-client informational messages (or > transactions?) Depends on what you mean by transactions -- what your actual requirement is. COPS started out with a pure transaction model (iirc) and added unsolicited messages without much trouble. > - must support models in which multiple clients talk to > multiple servers. Yes. We're going to have to deal with robustness/reliability, scaling and multihoming. > Specific Operations/Scenarios > > Note that these are protocol requirements, not box > requirements. So, while the protocol must support the ability > of a client to ask for a pinhole, the protocol also allows > for a middlebox to return 'NO - I am a NAT, dummy.' > > - must support a client-to-server transaction which returns > the middlebox capabilities to the client. These capabilities > should include, but not be restricted to: > - firewalling > - NAT (including port translations) > - QoS > - Plumbing information (where does NAT fit > relative to other elements, specifically, > THIS MATTERS!) Are you trying, say, to find all middleboxes close to you with capability X (or a list of capabilities X,Y...)? If so then I don't getting a single middlebox to tell you everything it's capable of is what you're after. Are you a network operator doing diagnostics? Finally, I believe all of this is modulo policy, that some clients may never get to hear about certain capabilities. I think the requirement here is a requirement on the network as a whole, that of discovery of specific capabilities. > - must support a method for mirroring an existing NAT > binding allocated by one middlebox into another middlebox, > for redundancy. There are a few ways to build this, > I don't know or care how the protocol does it, Exactly :-) > but > this capability must be supported. This might not be a requirement on us. We have to have it in the framework, and we have to have some idea about how it *might* be done, but it could be done by a number of completely different control functions. > - must support client-to-server transactions to query middlebox > state, including but not restricted to: > > - currently installed pinholes > - currently installed NAT bindings > - statistics of various sorts Modulo policy. I like the rest. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 15:33:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12463 for ; Fri, 30 Mar 2001 15:33:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17128; Fri, 30 Mar 2001 15:28:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17094 for ; Fri, 30 Mar 2001 15:28:49 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12106 for ; Fri, 30 Mar 2001 15:28:49 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id MAA18778; Fri, 30 Mar 2001 12:27:00 -0800 (PST) Received: from SBRIM-W2K.cisco.com (sjc-vpn-86.cisco.com [10.21.64.86]) by airborne.cisco.com (Mirapoint) with ESMTP id AAH11731; Fri, 30 Mar 2001 12:28:12 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15044.60507.488000.859497@gargle.gargle.HOWL> Date: Fri, 30 Mar 2001 15:28:11 -0500 To: Brian E Carpenter Cc: "Michael W. Condry" , Andrew Molitor , midcom@ietf.org, midtax@lists.hactrn.net Subject: Re: [midcom] Protocol Requirements - In-Reply-To: <3AC4DD51.3391B84A@hursley.ibm.com> References: <5.0.2.1.2.20010330102532.019ad740@FMSMSX63.fm.intel.com> <3AC4DD51.3391B84A@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I hope midtax will be involved, but it's up to midcom to define the functions better. Names are easy compared to functional models. ...Scott On 30 Mar 2001 at 13:24 -0600, Brian E Carpenter apparently wrote: > Well, I hadn't thought of doing formal terminology as part of the > midtax effort... would it be useful? > > Brian > > "Michael W. Condry" wrote: > > > > is there some consistency that the MidTax folks are supposed > > to define here? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 16:38:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15875 for ; Fri, 30 Mar 2001 16:38:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18007; Fri, 30 Mar 2001 16:18:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17976 for ; Fri, 30 Mar 2001 16:18:31 -0500 (EST) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15082 for ; Fri, 30 Mar 2001 16:18:33 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id E0C6E8188 for ; Fri, 30 Mar 2001 15:18:00 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id PAA12843 for ; Fri, 30 Mar 2001 15:18:43 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 30 Mar 2001 15:18:43 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Protocol Requirements - In-Reply-To: <15044.60280.832000.612953@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 30 Mar 2001, Scott Brim wrote: > On 26 Mar 2001 at 17:36 -0600, Andrew Molitor apparently wrote: > > Throughout, I use this terminology: > > > > Client - something that requests pinholes pinholes and > > NAT bindings. For example, a MIDCOM aware ALG or > > SIP proxy. > > > > Server - something which is spoken to by a client. By implication, > > a Server resides in (logically, if not literally) a > > Middlebox, and exposes the services of that Middlebox > > to Clients. > > > > Middlebox - a firewall or NAT device which is coupled to a > > MIDCOM server, which offers the firewall/NAT services > > to Clients. > > > > Do we want to require a 1-to-1 relationship between Servers > > and Middleboxes? > > Interesting. Am I right in understanding that > > - your Client is Suresh's Agent, something speaking on behalf of the > originating end node > - your Server is something which speaks on behalf of the middlebox. I think this is exactly right. I view this as natural in the light of the original meaning of client/server. The Client is something that wants services, and the server is something that has them. I therefore think that these Client and Server usages make sense, even for cases in which the Server initiates communications. > I thought about whether we needed the extra decoupling and indirection > we would get from this kind of Server, and decided we *probably* didn't > need it. Something like this might come in handy in the future when we > want to make sure we have coordination between middleboxes, but a single > client-side agent could probably coordinate its specific protocol realm > just as well. So I don't think we need your Server separated from the > middlebox. In the future if we need to we can separate them without the > rest of the world noticing. I view the middlebox as a single entity, which talks MIDCOM to clients and also has NAT and/or firewally stuff in it. That said, I find it useful to separate it into Server and Middlebox functions not by way of proposing two boxes or even two separate pieces of software, but simply as a way to speak of the two aspects of the device clearly. I actually stole this from Richard Swale's document, more or less. > > - should be transport independent, a la SIP. > > Why? (You're going to see that question a lot.) > btw as I recall SIP's transport independence was added afterward. I think I havve addressed this in my followup bullet list? > > - must support high transaction throughput over highish > > latency networks (read: must support message streaming.) > > What are you expecting to carry in this protocol that you would want > message streaming? I think of it as a small-message control protocol. I am thinking of cases in which a SIP proxy wants to control a middlebox that is many many milliseconds away. If the middlebox is N milliseconds away, and you want to do NAT and firewalling, you are optimistically limited to 1000 / (8 * N) calls per second in the absence of streaming (4 messages at 2*N millseconds round trip = 8*N milliseconds/call) which is really low for N bigger than about 4 or 5. > > - must support a client-to-server transaction which returns > > the middlebox capabilities to the client. These capabilities > > should include, but not be restricted to: > > - firewalling > > - NAT (including port translations) > > - QoS > > - Plumbing information (where does NAT fit > > relative to other elements, specifically, > > THIS MATTERS!) > > Are you trying, say, to find all middleboxes close to you with > capability X (or a list of capabilities X,Y...)? If so then I don't > getting a single middlebox to tell you everything it's capable of is > what you're after. Are you a network operator doing diagnostics? > Finally, I believe all of this is modulo policy, that some clients may > never get to hear about certain capabilities. I think the requirement > here is a requirement on the network as a whole, that of discovery of > specific capabilities. This transaction is strictly a Single Client asking a Single Middlebox 'what are you and what can you do?' The point is to simplify configuration of applications which are MIDCOM clients. This capability allows Client configurations boil down to something not too far from 'these are the networks you care about, these are the IP addresses in them, and there are middleboxes here, here, and here.' It's also very useful for network manangement and whatnot. The plumbing thing is critical, so the Client knows what addresses to use in specifying pinholes in a combination firewall/NAT box. This more or less has to be automatically discoverable by the Client, since Joe User is going to go insane if Joe User has to manually configure this information into the Clients. > > [ mirroring NAT and other state ] > > this capability must be supported. > > This might not be a requirement on us. We have to have it in the > framework, and we have to have some idea about how it *might* be done, > but it could be done by a number of completely different control > functions. I'm sort of ok with the idea of just decreeing that MIDCOM should avoid making this impossible. Still, if we want to define The Way a thing like a SIP Proxy talks to a thing like a NAT, I think it might be best to include useful primitives. I'm pretty sure that, at least sometimes: - a SIP Proxy or similar will want to control redundancy. - the aforementioned application will use MIDCOM to talk to NAT devices. - the aforementioned application will need some way to discover NAT binding information and to install it. - the authors of the aforementioned application will be unamused if the answer is 'oh, talk to the REPLICON working group about their protocol for doing that.' With this in mind, my sense is that MIDCOM should provide the communication aspects of solving this problem. Whether this is with explicit state query/copy mechanisms, or if it can be made to simply drop out as a consequence of getting some other primitives right, or if it occurs by black magic, I don't care. > > - must support client-to-server transactions to query middlebox > > state, including but not restricted to: > > > > - currently installed pinholes > > - currently installed NAT bindings > > - statistics of various sorts > > Modulo policy. Absolutely! Clearly, the middlebox can reply with PERMISSION_DENIED to anything, any time. I think it's equally clear that the problem of specifying 'who can do what to me' middlebox policy it out of scope, but we surely need to allow for it. Thanks for your comments! I hope I was able to clarify myself. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 17:22:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17604 for ; Fri, 30 Mar 2001 17:22:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18745; Fri, 30 Mar 2001 17:09:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18714 for ; Fri, 30 Mar 2001 17:09:42 -0500 (EST) Received: from pallas.host4u.net (pallas.host4u.net [216.71.64.48]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17171 for ; Fri, 30 Mar 2001 17:09:44 -0500 (EST) Received: from C1380748B (adsl-64-166-95-198.dsl.sntc01.pacbell.net [64.166.95.198]) by pallas.host4u.net (8.8.5/8.8.5) with SMTP id QAA26606; Fri, 30 Mar 2001 16:09:06 -0600 From: "Shai Mohaban" To: "Andrew Molitor" , Subject: RE: [midcom] Protocol Requirements Bullet List v2.0 Date: Fri, 30 Mar 2001 14:07:44 -0800 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Few comments: - As noted in the WG meeting I think the terms client and server are confusing. Why don't we use something like a MidBox and MidBox Controller and make the terms self explanatory? This would also follow the Media Gateway vs. Media Gateway Controller decomposition concept and terminology... - I understand the focus on NAT/FW but I would like to add a requirement that the protocol be easily extendible. Rather than thinking about all the future primitives I suggest at least the format would be flexible enough to allow such future extensions (e.g. use TLVs). - Besides packet/flow dropping and network address translation few examples of other MidBox primitives include transcoding, encryption and IPv4-IPv6 translations. I am sure there are many others. - I think we should expect different families of primitives, such as security related, QoS related, etc. Because of the different nature of these I think there is a good chance they will be implemented on different physical devices (e.g. I don't expect a firewall to have DSP resources to allow transcoding, or to even want to get into this very different business, and vice versa). This means that a single MidBox Controller might have to control multiple MidBoxes for each and every controlled flow. - The current requirements draft indicates (page 3 and also section 3.4 on page 5) that the MidCom Packet Processor can manipulate the headers. Applications like transcoding require modifying more than just the headers so we should generalize this requirement. - According to section 3.4 the default behavior of the MidBox is not to let packets pass through it. I think this default behavior should be configurable (and policy driven) as the requirement may be different for different applications. E.g. in case of a QoS MidBox I think this will not be the default behavior. - One big issue that is not addressed currently is that of order between primitives. This may be a non-issue when you have just NAT and FW, but might be more complicated as various primitives start interacting with each other. It is even more difficult when we try to make the whole thing extendible to support future primitives... > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On > Behalf Of Andrew Molitor > Sent: Wednesday, March 28, 2001 1:31 PM > To: midcom@ietf.org > Subject: [midcom] Protocol Requirements Bullet List v2.0 > > > This is a new, improved, version of my earlier bullet list. I > have noted edited bits in the leftmost column with a * so you can skip > the bits I left alone. > > I have a dreadful habit of using tabs sometimes, and eight > spaces other times. Hopefully I didn't do it so much this comes out all > weird on your screen. > > I am particularly interested in the issue of server-to-client > messaging. I list a few possible things the server could tell > the client in my very last bullet. I would very much like: > > - to know about any other sorts of things the middlebox could > or should be able to tell the client. > - what the requirement for acks is on all of these informative > messages. > > It is, for example, possible to build a SIP proxy which works > fine without any notifications from the middlebox at all. It might > be useful, nontheless, to report timeouts. This might help the > SIP proxy out in some way, and would at least let the SIP proxy report > that something odd is going on (e.g. a BYE transaction happened but > we never saw it -- so the call went away, the media stopped flowing, > and the NAT elements timed out.) > > ------------------------------------------------------------------ > --------- > > Throughout, I use this terminology: > > Client - something that requests pinholes and NAT bindings. For > example, a MIDCOM aware ALG or SIP proxy. > > Server - something which is spoken to by a client. By implication, > a Server resides in (logically, if not literally) a > Middlebox, and exposes the services of that Middlebox > to Clients. > > Middlebox - a firewall or NAT device which is coupled to a > MIDCOM server, which offers the firewall/NAT services > to Clients. > > Do we want to require a 1-to-1 relationship between Servers > and Middleboxes? > > Protocol requirements in no particular order: > > General Stuff > ============= > * - must support low-latency, high-throughput operation, with > * best effort to maintain low latency in the face of a > lossy network. > * This is necessary for telecom grade operations -- backoff > * policies in retransmit timers are not necessarily a good idea > * on controlled channels controlling equipment. (This boils > * down to: TCP Considered Harmful -- in rather specific > * environments.) > * > * - must also support more ordinary network traffic models for > * use on standard networks where backoff policies for retransmit > * timers, and the like, are a good ideas. (This boils down to: > * TCP is a hell of a good idea most of the time.) > * > * [ I think the first bullet above pretty much requires UDP > * transport with wicked timers, but if there's another option > * I'd be pleased to hear about it. The situation I am thinking > * of is: some goober in a POP unplugs the wrong cable for > * a moment, or there is some other glitch in connectivity. > * It would Be Bad if this glitch made TCP back off and make > * the POP unable to complete calls for, say, 2 or 3 seconds > * AFTER connectivity is restored. This could readily create > * irritating post-dial delays for several hundred customers > * over the next 10 seconds while the queue clears. This is the > * sort of thing that gives telecom geeks nightmares. ] > > - should be transport independent, a la SIP. > > - must support high transaction throughput over highish > latency networks (read: must support message streaming.) > > - must support one or more strong authentication models. > > * - must support one or more privacy models. > > - must support client-to-server request/response transactions. > > * - must support server-to-client "alerts" (unacknowledged messages) > * > * - should support an acknowledged server-to-client messaging > * model as well? > > - must support models in which multiple clients talk to > multiple servers. > > Specific Operations/Scenarios > > Note that these are protocol requirements, not box > requirements. So, while the protocol must support the ability > of a client to ask for a pinhole, the protocol also allows > for a middlebox to return 'NO - I am a NAT, dummy.' > > * - must support a client-to-server transaction which returns > * the middlebox capabilities to the client. These capabilities > * must include, but not be restricted to: > * - firewalling > * - NAT > * - NAT capabilities (ports and stuff) > * - Plumbing information (where does NAT fit > * relative to other elements, specifically, > * THIS MATTERS!) > * > * and should include: > * - QoS > * - QoS flavor(s) > * [ can someone help out with what one might want to say > * if one WERE a QoS capable middlebox? Is this far enough > * out of scope to just leave QoS out entirely, burying it > * in the 'but not be restricted to' part above? ] > > - must support a client-to-server transaction to open a > "pinhole" in the middlebox's traffic policy. > > - must support a client-to-server transaction to request > a NAT binding, associating an IP address/port pair on > one interface with an IP address/port pair on another. > > - it would sure be nice if these binding requests could > specify information about the expected source of the > flow initiator. E.G. 'I have a server on the inside > at 192.168.1.99 port 5000, and I think someone on the > outside at address 209.46.41.61, I don't know the port' > will be connecting to my server -- please give me an > address/port I can advertise to the remote as the phone's > address/port' > > * - must support means for clients to manage redundant middlebox > * configurations. This means that it must be possible for a > * client or clients to: > * - apply the same NAT binding across multiple (NAT capable) > * middleboxes. > * - apply the same pinhole across multiple (pinhole capable) > * middleboxes (this is actually trivial and impossible > * to NOT get right -- included for completeness) > * > * [ these two boil down to: client can keep a primary > * and a spare middlebox in synch ] > * > * - bring a new middlebox into synch with a set of > * synchronized redundant middleboxes. > * > * [ this boils down to: a client can bring a formerly > * dead primary middlebox back into service after repairs, > * without bringing the network down.] > > - must support a client-to-server transaction to release an > individual NAT binding. > > - must support a client-to-server transaction to release an > individual pinhole. > > - should support a way to identify bundles of state (pinholes > and NAT) as belonging to the same group (a "session ID" > specified by the client in a set of requests) > > - should support a client-to-server transaction to delete all > the state bundled under a given session ID. > > * - should support a way to re-session-ID a bundle. That is, > * there should be a client-to-server transaction in which > * the client asks the middlebox to take all the stuff with > * session ID "A" and re-file it under session ID "B" > * > * [ this is a surprisingly useful operation but the uses of it > * that I know of might be proprietary so I shan't describe them. > * There are people reading who know whether they are or are not > * proprietary, so if there is curiosity, hopefully explanations > * will be forthcoming. Sorry to be so mysterious. ] > > - must support a way to specify a desired timeout value for > and piece of state created by a client-to-server transaction. > > - should support both activity based timeouts as well as > absolute timeouts (i.e. support both 'if you don't see any > packets for 60 seconds, please make this NAT binding go > away by itself' AND 'make this NAT binding go away in 60 > seconds') > > - must support client-to-server transactions to query middlebox > state, including but not restricted to: > > - currently installed pinholes > - currently installed NAT bindings > - statistics of various sorts > > - should support a client-to-server transaction allowing the > client to register to receive notifications of various > sorts from the server. > > - should support some server-to-client transactions to inform > the client of events such as: > > - timeouts of pinholes and NATs > - violations of policy > - other? > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 17:32:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17982 for ; Fri, 30 Mar 2001 17:32:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18842; Fri, 30 Mar 2001 17:24:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18817 for ; Fri, 30 Mar 2001 17:24:24 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17664 for ; Fri, 30 Mar 2001 17:24:24 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GB100LD57JDFQ@firewall.mcit.com> for midcom@ietf.org; Fri, 30 Mar 2001 22:23:37 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GB1001017JCVW@dgismtp01.wcomnet.com>; Fri, 30 Mar 2001 22:23:37 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GB100IO17IZR4@dgismtp01.wcomnet.com>; Fri, 30 Mar 2001 22:23:23 +0000 (GMT) Date: Fri, 30 Mar 2001 16:23:17 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] SIP MIDCOM flow... In-reply-to: <856592CED9BBD211AC3E00A0C967ED7A05618C24@orsmsx51.jf.intel.com> To: "'Anderson, Todd A'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <002e01c0b968$056953a0$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Anderson, Todd A > Sent: Friday, March 30, 2001 12:26 PM > To: 'midcom@ietf.org' > Subject: RE: [midcom] SIP MIDCOM flow... > > > In the hangup sequence, am I wrong in my understanding that > the SIP proxy > should send the bye to the internal client and not the > middlebox? Diagram > updated to reflect this sequence. > > SIP UA SIP/CTRL Middle Internal > Client Proxy Box SIP Client > | | | | > |----INVITE------>| | | > | |----Initiate-->| | > | |<-Initiated----| | > | | | | > | |--------INVITE----------->| > |<---100Trying----| | | > | | | | > | |<-----180Ringing----------| > |<--180Ringing----| | | > | |<-------200 OK------------| > |<---200 OK ------| | | > | |----OPEN Hole->| | > | |<-OPEN Hole----| | > |-------ACK------>| | | > | |-----------ACK----------->| > | | | | > |<-------------------RTP/RTCP--------------->| > | | | | > |-------BYE------>| | | > | |----Terminate->| | > | |<-Terminating--| | > | | | | > | |-----------BYE----------->| > | |<----------200 OK---------| > | | | | > | |----CloseHole->| | > | |<---CloseHole--| | > |<---200 OK-------| | | > | | | | > I am actually performing two functions above. I am considering intiate and terminate to be the process for opening and closing communications between controller and middlebox (with authentication, and perhaps intiating/terminating an encrypted path), and open/close hole as the action request and verification. I probably need to tie midcom terminology into this call flow. Now that I have clarified this for myself more comments below... > Just for my own understanding, why are terminate and > closehole in the order > presented here? My intuition would say to unroll the stack > as it were and > closehole first followed by terminate. Either of these seems > to have the > problem though that it causes the bye and 200 OK between the > proxy and the > internal client to fail, either because there is no NAT binding or no > pinhole to go through. Why wouldn't the following work? > Would appreciate > someone to educate me on this issue. > > | | | | > |-------BYE------>| | | > | |-----------BYE----------->| > | |<----------200 OK---------| > | | | | > | |----CloseHole->| | > | |<---CloseHole--| | > | | | | > | |----Terminate->| | > | |<-Terminating--| | > |<---200 OK-------| | | > | | | | > Using my clarification above, your correction would be exactly how it should look. > Todd > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 17:40:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18400 for ; Fri, 30 Mar 2001 17:40:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18941; Fri, 30 Mar 2001 17:27:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18884 for ; Fri, 30 Mar 2001 17:27:42 -0500 (EST) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17802 for ; Fri, 30 Mar 2001 17:27:44 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 522898186 for ; Fri, 30 Mar 2001 16:27:11 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA17430 for ; Fri, 30 Mar 2001 16:27:55 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 30 Mar 2001 16:27:55 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] Protocol Requirements Bullet List v2.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 30 Mar 2001, Shai Mohaban wrote: > Few comments: > > - As noted in the WG meeting I think the terms client and server are > confusing. Why don't we use something like a MidBox and MidBox Controller > and make the terms self explanatory? This would also follow the Media > Gateway vs. Media Gateway Controller decomposition concept and > terminology... This is fine with me. > - I understand the focus on NAT/FW but I would like to add a requirement > that the protocol be easily extendible. Rather than thinking about all the > future primitives I suggest at least the format would be flexible enough to > allow such future extensions (e.g. use TLVs). I think the WG is pretty much agreed that extensibility is extremely desireable, but you are entirely correct -- that should be actually written down. My bullet list will acquire such an item in its next edition. > - I think we should expect different families of primitives, such as > security related, QoS related, etc. Because of the different nature of these > I think there is a good chance they will be implemented on different > physical devices (e.g. I don't expect a firewall to have DSP resources to > allow transcoding, or to even want to get into this very different business, > and vice versa). This means that a single MidBox Controller might have to > control multiple MidBoxes for each and every controlled flow. Quite. Hence the 'multiple clients, multiple servers' (or, if you prefer, 'multiple MidBox, multiple MidBox controllers' remark I and others have made. It is clearly necessary to let a single MidBox Controller manage a chain of MidBoxen on a path, as well as to let multiple MidBox controllers access a single MidBox. Carrier networks, at least, demand this. > - The current requirements draft indicates (page 3 and also section 3.4 on > page 5) that the MidCom Packet Processor can manipulate the headers. > Applications like transcoding require modifying more than just the headers > so we should generalize this requirement. Err, does transcoding mean going from one audio/video codec to another? E.G. decode G.711 into PCM and thence into G.723 and vice versa? I think this is so far out of scope as to be well over the horizon and completely out of sight. I am happy to restrict the scope by defining a middlebox as something which manipulates headers. This does not mean that a middlebox cannot logically co-reside with some other box which does other stuff, only that MIDCOM talks to that aspect of the box which does header manipulations -- that is, to the middlebox aspect of the device. If you wanted to build a firewall/NAT/QoS/transcoding device, in this scenario, that would be excellent. MIDCOM would only let you talk to the firewall/NAT parts, as is. On the other hand, if we want to support niftier devices through extensibility or mechanisms for tunneling arbitrary other protocols inside MIDCOM, that's cool too. My feeling is that this is not what the ADs want, not what the WG wants collectively. Hopefully there will be enough voices chiming in to make this clear one way or the other. > - According to section 3.4 the default behavior of the MidBox is not to let > packets pass through it. I think this default behavior should be > configurable (and policy driven) as the requirement may be different for > different applications. E.g. in case of a QoS MidBox I think this will not > be the default behavior. I concur. This may be one of the things a middlebox can tell a client in response to the 'hey, what are you, what can you do, and how are you plumbed' request. The default behavior of the device is an interesting piece of data. Where possible, it should be configurable, but recall that we are here to deal with existing middlebox class devices, not to define their behavior. > - One big issue that is not addressed currently is that of order between > primitives. This may be a non-issue when you have just NAT and FW, but might > be more complicated as various primitives start interacting with each other. > It is even more difficult when we try to make the whole thing extendible to > support future primitives... NAT and firewalls interact. I have been beating this drum for a while now, and I am gratified to see that someone else is worried about it! Hopefully the silence has been due to others not worrying about it too much, as opposed to it being SO OBVIOUS that I simply look like a twit for foaming at the mouth about it! Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Mar 30 18:07:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19354 for ; Fri, 30 Mar 2001 18:07:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19346; Fri, 30 Mar 2001 17:52:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19316 for ; Fri, 30 Mar 2001 17:52:57 -0500 (EST) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18834 for ; Fri, 30 Mar 2001 17:52:58 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id A7E798185 for ; Fri, 30 Mar 2001 16:52:23 -0600 (CST) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA19214 for ; Fri, 30 Mar 2001 16:53:10 -0600 (CST) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 30 Mar 2001 16:53:10 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] SIP MIDCOM flow... In-Reply-To: <002e01c0b968$056953a0$6401010a@mcit.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 30 Mar 2001, Christopher A. Martin wrote: > I am actually performing two functions above. I am considering intiate and > terminate to be the process for opening and closing communications between > controller and middlebox (with authentication, and perhaps > intiating/terminating an encrypted path), and open/close hole as the action > request and verification. > > I probably need to tie midcom terminology into this call flow. Goodness! With this definition of Initiate and Terminate, I cannot imagine why they're tied in to a call flow. Surely these are separate operations which happen entirely outside the call processing path? I suppose you COULD re-authenticate for every call, but why on earth would you want to? I think the authentication transaction, and the corresponding "log out" transaction should be completely decoupled from pinholes and stuff. Obviously a Client (or Controller) may elect to do them as indicated, but anything wishing to Go Fast will surely tend to authenticate fairly infrequently. I realize that these call flows are just intended as sort of typical applications, but I think it's unrealistic to indicate the Initiate and Terminate transactions this closely. If I were drawing the flows, I'd have an Initiate transaction first, and then an indication of 'some amount of time passes' and then the call setup and the call teardown and then another 'some amount of time passes' followed by the Terminate. Somewhat related, are there standard words for this? Surely the IPSEC people invented some words for this sort of thing? In the absence of other words, I would suggest Authenticate and Logout, or Connect and Disconnect, or something. These words are probably as meaningless to others as Initiate and Terminate are to me, though. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom