From midcom-admin@ietf.org Wed Jun 13 09:18: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 ESMTP id JAA22260 for ; Wed, 13 Jun 2001 09:18:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16202; Wed, 13 Jun 2001 09:15:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16173 for ; Wed, 13 Jun 2001 09:15:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22169 for ; Wed, 13 Jun 2001 09:14:41 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5DDElU12068 for ; Wed, 13 Jun 2001 06:14:47 -0700 (PDT) Received: from spandex (rtp-vpn-263.cisco.com [10.82.193.7]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AJA04747; Wed, 13 Jun 2001 06:14:25 -0700 (PDT) Message-ID: <002901c0f40a$e3300800$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Wed, 13 Jun 2001 09:15:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Fw: Internet-Draft Cutoff Dates for London (England) IETF 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 In case you're not on the ietf-announce mailing list. Please note that our according to the milestones in our working group charter we are to have our deliverables through working group last call and submitted to the IESG in August. I'd like to continue to push to meet the deadline, which may mean that at the meeting we'll be resolving the VERY FEW remaining issues that haven't been worked through on the midcom mailing list. There will be no technology presentations. Melinda ----- Original Message ----- From: Natalie Syracuse To: Sent: Wednesday, June 13, 2001 8:32 AM Subject: Internet-Draft Cutoff Dates for London (England) IETF > > NOTE: There are two (2) Internet-Draft Cutoff dates > > July 13: Cutoff for Initial Submissions (new documents) > > All initial submissions(-00) must be submitted by Friday, > July 13, 17:00 US-EST. Initial submissions received after this time > will NOT be made available in the Internet-Drafts directory, and will have > to be resubmitted. > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Monday, July 16. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of July 13 will NOT be accepted. > > July 20: FINAL Internet-Draft Cutoff > > All revised Internet-Draft submissions must be submitted by Friday, > July 20, 2001 at 17:00 US-EST. Internet-Drafts received after this time > will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions the week of the > meeting, though announcements will NOT be sent until the IETF meeting > is over. > > Thank you for your understanding and cooperation. Please do not hesitate > to contact us if you have any questions or concenrs. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_51.html > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 14 07:19: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 ESMTP id HAA25056 for ; Thu, 14 Jun 2001 07:19:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05057; Thu, 14 Jun 2001 07:08:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05028 for ; Thu, 14 Jun 2001 07:08:53 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24729; Thu, 14 Jun 2001 07:08:21 -0400 (EDT) Message-Id: <200106141108.HAA24729@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, 14 Jun 2001 07:08:21 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-framework-02.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communication Architecture and framework Author(s) : P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan Filename : draft-ietf-midcom-framework-02.txt Pages : 42 Date : 13-Jun-01 There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications such as SIP and H.323 and peer-to-peer applications such as Napster and NetMeeting cannot be identified by merely examining packet headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-02.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-framework-02.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-framework-02.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: <20010613130011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010613130011.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 Jun 14 09:38:26 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 ESMTP id JAA28854 for ; Thu, 14 Jun 2001 09:38:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09752; Thu, 14 Jun 2001 09:36:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09717 for ; Thu, 14 Jun 2001 09:36:15 -0400 (EDT) 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 ESMTP id JAA28665 for ; Thu, 14 Jun 2001 09:35:44 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5EDY9F16135 for ; Thu, 14 Jun 2001 06:34:10 -0700 (PDT) Received: from spandex (sjc-vpn-tmp181.cisco.com [10.21.64.181]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AJG03303; Thu, 14 Jun 2001 06:35:40 -0700 (PDT) Message-ID: <030801c0f4d7$063d4ac0$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Thu, 14 Jun 2001 09:36:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Framework draft review 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 all should have seen the announcement of the most recent revision of the framework document. I'm optimistic that we can get this into last call in time to meet our deadline, but in order to do that we need your review and discussion. Please have a look at it and post questions, concerns, disagreements, etc. to the mailing list. Many thanks, Melinda p.s. if you didn't see the announcement, the URL is http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-02.txt _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 14 15:01: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 ESMTP id PAA07607 for ; Thu, 14 Jun 2001 15:01:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22200; Thu, 14 Jun 2001 14:59:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22172 for ; Thu, 14 Jun 2001 14:59:18 -0400 (EDT) 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 ESMTP id OAA07528 for ; Thu, 14 Jun 2001 14:58:41 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5EIwh916164 for ; Thu, 14 Jun 2001 11:58:43 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-4.cisco.com [10.21.96.4]) by airborne.cisco.com (Mirapoint) with ESMTP id ADJ12875; Thu, 14 Jun 2001 11:58:41 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" Message-ID: <15145.2395.712000.223809@gargle.gargle.HOWL> Date: Thu, 14 Jun 2001 14:58:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Subject: Re: [midcom] Framework draft review In-Reply-To: <030801c0f4d7$063d4ac0$d45904d1@cisco.com> References: <030801c0f4d7$063d4ac0$d45904d1@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 > detection, security and so forth. Network Address Translator > service, on the other hand, provides routing transparency across > address realms (within IPv4 routing network or across V4 and V6 > routing realms). Application Level gateways (ALGs) are used in This use of "routing" came up in the NAT WG about 2 years ago, maybe more. There was a long discussion and I thought Suresh had conceded. In any case "routing" is misused here, assuming you mean IP routing. IP routing information does not pass transparently through NATs. I would change the first instance of "routing" to "forwarding" and delete the other instances. > The communication between a MIDCOM > agent and a middlebox will be transparent to the end-hosts that > take part in the application, unless one of the end-hosts assumes > the role of a MIDCOM agent. I don't think "transparent" is a good word here. "Transparent" usually means communications from the end host are passed through unchanged, which this framework should not guarantee. I think you mean "does not require changes to the end host". Do you? > method performed on a network intermediary that requires application For clarity, you should change "on" to "by". > 2.2. MiddleBox > > Middlebox is a network intermediate device that implements one or > more of the middlebox services. A NAT middlebox is a middlebox > implementing NAT service. A firewall middlebox is a middlebox > implementing firewall service. At this point, please reiterate that middlefunctions can run on end systems as well as routers or just about anywhere. > Network Address Translation is a method by which IP addresses are > mapped from one address realm to another, providing transparent > routing to end-hosts. This is achieved by modifying end node Same comment as above re "routing". > ALGs are different from proxies. ALGs are transparent to > end-hosts, unlike the proxies which are relay agents terminating > sessions with both end-hosts. ALGs do not terminate session with > either end-host. Instead, ALGs examine and optionally modify > application payload content to facilitate the flow of application > traffic through a middlebox. ALGs are middlebox centric, in that Here you make it clear that ALGs are not "transparent" in the usual sense. See suggested fix above. > Policy Server is a management entity that acts in advisory > capacity and interfaces with a middlebox to communicate policies Change "advisory" to "authoritative". Policy servers don't say "gee, I don't think you should do that. > middlebox. In the case where a MIDCOM agent is not pre-configured, > the middlebox will consult Policy Server out-of-band and obtain > the agent profile to validate connection setup and authorization > of the agent to gain access to middlebox resources. Once an agent > is connected to the middlebox, the policy server may at anytime > notify the middlebox to terminate authorization for the agent. First, I'd delete out-of-band. Out-of-band of what? The relationship between middlebox and policy server is purely management. There is no other data flow to be out-of-band of. Second, as discussed on the mailing list, there are two different kinds of information which can be obtained from a policy server. You have the them bundled together. The first is general authorization and limits for an agent. The second is information regarding a particular request from an agent. While a middlebox might obtain an agent "profile" either before or when it first makes contact with that agent, it does not necessarily obtain complete rules for treatment of requests from that agent at that time. The text above requires that (or if it doesn't, then you don't mention request-specific rules anywhere :-)). I would add another sentence, something along the lines of "Policy regarding treatment of specific agent requests may be obtained when the agent is first authorized or at any time thereafter." > Resources such as a Session-Descriptor may be shared across > middlebox functions. A Session-Descriptor may uniquely identify > a session denoted by the tuple of (SessionDirection, > SourceAddress, DestinationAddress, Protocol, SourcePort, > DestinationPort). An aggregated Session-Descriptor, on the other > hand, may have one of the tuple elements denoted by a regular > expression (ex: Any source port). The attributes associated There's an unnecessary assumption here about what a "session" might be. A "session" may be more specific than the exact-match tuple you propose, as might regular expression descriptors. You demonstrate this in 5.1, when you talk about "sub-sessions". I would leave out everything between the first sentence and "The attributes associated ...". > It is important to note that an agent and a middlebox can be on > the same physical device. In such a case, it is not desirable > for them to communicate using MIDCOM protocol. They may communicate > using a MIDCOM protocol message formats, but using a non-IP based All true except leave out "it is not desirable for them to communicate using MIDCOM protocol". It isn't up to us to judge implementations. We do need to note (as you do) that they MAY communicate by any means. > A MIDCOM session may be terminated by either of the parties. > Alternately, a MIDCOM session termination may be triggered by > one of (a) agent going out of service and not being available > for further MIDCOM operations, or (b) a policy server notifying > the middlebox that a particular MIDCOM agent is no longer > authorized for a particular set of sessions any longer. The policy server telling the middlebox an agent is no longer authorized does not terminate the midcom protocol. That's a completely separate relationship. Leave this part out. Do we need to say, now, that the midcom protocol will have reason codes in it? I don't think so. > (out of band stuff) I see no scope for an out-of-path agent for JUST control. As in, the middlebox says "Hey, Charlie is trying to make such-and-such a connection, what do I do?", and the oop agent says "do this for him", or "return this error". What about, e.g., incoming calls? > Agents are pre-registered with a Policy Server for authorization to > gain access to a middlebox. Well, the middlebox doesn't know or need to know if they are PRE-registered. They may be registering moments before they talk to the middlebox. Change "are pre-registered" to "are registered". > The policy server maintains a list of > agents that are authorized to connect to each of the middleboxes the > policy server supports. The Policy server has no knowledge of > middlebox service and as such cannot help a middlebox with any of > the middlebox services and the resource authorization. No knowledge? That's an assumption. We don't know yet what level of detail will be required by communication between middlebox and policy server. > The policy server acts in an advisory capacity to a middlebox to The policy server is the policy authority (again). > authorize or terminate authorization for an agent to gain > connectivity to the middlebox. The primary objective of a policy > server is to communicate agent authorization information so as to > ensure that the security and integrity of a middlebox is not > jeopardized. Specifically, the policy server should associate a > trust level with each agent attempting to connect to a middlebox > and provide a security profile. The policy server should be capable > of addressing cases when end-hosts are agents to the middle-box. See comment way up top about not restricting the policy server to this limited coarse-grain ability. If we do, I guarantee that someone will have to create another kind of policy server. > of the key can decipher the message content. Lastly, replay > protection is a form of sequence integrity so when an intruder > plays back a previously recorded sequence of messages, the > receiver of the replay messages will simply drop the replay > messages into bit-bucket. Certain applications of the MIDCOM > protocol might require support for non-repudiation as an option of > the data integrity service. Typically, support for non-repudiation > is required for billing, service level agreements, payment orders, > and receipts for delivery of service. OK, but certain agent communications will need to be idempotent. We need to think carefully about our security needs when we get to the midcom protocol. > IPsec AH ([IPSEC-AH]) offers data-origin authentication, data > integrity and protection from message replay. IPsec ESP > ([IPSEC-ESP]) provides data-origin authentication to a lesser > degree (same as IPsec AH if the MIDCOM transport protocol turns out > to be TCP or UDP), message confidentiality, data integrity and > protection from replay. Besides the IPsec based protocols, there > are other security options as well. TLS based transport layer > security is one option. There are also many application-layer > security mechanisms available. Simple Source-address based > security is the least form of security in a trusted domain and > may be permitted to trusted hosts. Leave this entire paragraph out. We're not at the point where we should be discussing which security mechanisms to use at all. > The premise of middlebox operation fundamentally requires > stateful inspection of data in the clear. This compromises the ... > However, the MIDCOM protocol removes the need for a middlebox > to inspect or manipulate data. This in turn allows applications Thus, I hope you mean, in the first excerpt, that *current* middlebox operation requires stateful inspection. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 14 19:32: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 ESMTP id TAA11353 for ; Thu, 14 Jun 2001 19:32:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00301; Thu, 14 Jun 2001 19:30:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00265 for ; Thu, 14 Jun 2001 19:30:47 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11304 for ; Thu, 14 Jun 2001 19:30:16 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id SAA29585 for ; Thu, 14 Jun 2001 18:30:57 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id SAA23194 for ; Thu, 14 Jun 2001 18:30:46 -0500 (CDT) Received: from xch-pssbh-01.nw.nos.boeing.com by stl-hub-01.boeing.com with ESMTP for midcom@ietf.org; Thu, 14 Jun 2001 18:30:37 -0500 Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 16:30:36 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12D9B@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'midcom@ietf.org'" Date: Thu, 14 Jun 2001 16:30:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] State in framework-02 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 The final two paragraphs of Section 4 addresses the need for middlebox services to be stateful. I've been puzzling over these two paragraphs over the last few versions because Section 4 itself deals with the Midcom protocol, rather than the middlebox, which was described in Section 3. It appears to me that these two paragraphs are misplaced and should be moved to Section 3. That is, it appears that the authors' intent is NOT to make the Midcom protocol be stateful between the Midcom Agent and the middlebox nor to require that the Midcom Agent itself be stateful. If so, this point needs to become more explicitly stated. That is, the final paragraph of Section 4 says in part: "Explicit release of dynamically allocated resources happens when the application session is ended or when a Midcom agent requests the middlebox to release the resource. However, the middlebox must be able to recover the dynamically allocated resources at some point in time even if the agent that was responsible for the dynamic allocation is not alive. ..." It has been Boeing's experience that application-level gateways have been unusually expensive and resource- intensive to maintain over time. This is especially the case if the protocols which they are "linking" are themselves stateful, because should the gateway's state machine enter an indeterminate state (e.g., due to an unanticipated melding of the states of the two protocols), which occurs vastly more often than one would hope, the gateway inevitably hangs. From protracted painful and expensive experience, we have learned to prefer approaches which are as stateless as possible (fully realizing that there are good reasons why many protocols need to be stateful) because they tend to be easier to maintain and support over time. Similarly, denial of service exploits are the more effective for stateful protocols, a point which was made in Radia Perlman and Charlie Kaufman's recent article in IEEE Internet Computing magazine ("Key Exchange in IPSec: Analysis of IKE", November/December 2000; see the Cookies section on page 53). For these reasons, it would be desirable if we would explicitly not require the Midcom Agent to be stateful (but allow statefulness there if needed) and, more importantly, that we explicitly design a midcom protocol that did not require protocol state to be kept after the setup. That is, the current draft implies that the Midcom protocol will perform two functions: (1) Setup and (2) Teardown where the former opens a hole through the middlebox and the latter closes it. The current text implies that the latter is optional, and that timers on the middlebox will close the hole if no Teardown happens. This is great. What I'd like to see is a mention that if Teardown happens, then it occurs because the Middlebox has tracked which Midcom agent set up which Session Descriptor. That is, that the teardown occurs solely because of statefulness of the middlebox rather than the statefulness of the protocol (i.e., any protocol linkages between the Setup function and the Teardown function). --Eric _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 15 09:54:54 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 ESMTP id JAA08377 for ; Fri, 15 Jun 2001 09:54:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01375; Fri, 15 Jun 2001 09:51:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01344 for ; Fri, 15 Jun 2001 09:51:41 -0400 (EDT) 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 ESMTP id JAA08142 for ; Fri, 15 Jun 2001 09:51:06 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5FDnWF09799 for ; Fri, 15 Jun 2001 06:49:32 -0700 (PDT) Received: from spandex (rtp-dial-1-114.cisco.com [10.83.97.114]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AJI02211; Fri, 15 Jun 2001 06:51:03 -0700 (PDT) Message-ID: <007a01c0f5a2$568d9400$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Fri, 15 Jun 2001 09:51:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Fw: WG Review: Open Pluggable Edge Services (opes) 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 for those not on the IETF announcements mailing list. Melinda ----- Original Message ----- From: The IESG To: Cc: Sent: Friday, June 15, 2001 9:18 AM Subject: WG Review: Open Pluggable Edge Services (opes) > > A new IETF working group has been proposed in the Applications Area. > The IESG has not made any determination as yet. > > The following Description was submitted, and is provided for > informational purposes only: > > Open Pluggable Edge Services (opes) > ----------------------------------- > > Current Status: Proposed Working Group > > Description of Working Group: > > The Open Plugable Edge Service (OPES) WG primary task is to define a > protocol to be used to extend participating transit intermediaries to > incorporate services executed on application data transported by HTTP. > The protocol provides a framework for integrating arbitrary services > into arbitrary intermediaries. Intermediaries may employ either local > or remote ("callout") servers to perform a service, and as a result, > the data may be diverted temporarily over a closed loop pathway > different from the transit pathway. Intermediary services provided in > this way are not transparent: Either the content requestor or provider > will be aware that a tranformation has been performed. > > As part of the development of this protocol the WG will produce an > analysis of the security impliciations of this architecture. > > A secondary task for this WG is to enumerate the requirements for > management policies and associated administrative protocols that allow > these services to be specified and deployed. > > The advantage of standardizing a protocol for this is that services can > be re-used across vendor products without modifying the transit > intermediaries or services. > > The ICAP protocol already provides similar functionality and this WG > may elect to use ICAP as a starting point for its work. However, the > working group is not obliged to retain any level of compatibility with > ICAP. > > A number of existing Internet-Drafts will become WG documents: > > Early Requirements document (expired but available on the web site): > draft-tomlinson-epsfw-00.txt > > Updated iCAP Callout Server: > draft-elson-opes-icap-01.txt > > A Rule Specification Language for Proxy Services: > draft-beck-opes-imrl-00.txt > > OPES Network Taxonomy: > draft-erikson-opes-net-taxonomy-00.txt > > OPES Architecture for Rule Processing and Service Execution: > draft-yang-opes-rule-processing-service-execution-00.txt > > OMML: OPES Meta-data Markup Language: > draft-maciocco-opes-omml-00.txt > > General Use Cases: > draft-beck-opes-esfnep-01.txt > > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 15 10:25: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 ESMTP id KAA10224 for ; Fri, 15 Jun 2001 10:25:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02346; Fri, 15 Jun 2001 10:23:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02321 for ; Fri, 15 Jun 2001 10:23:30 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09962 for ; Fri, 15 Jun 2001 10:22:55 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5FEN2U09369; Fri, 15 Jun 2001 07:23:02 -0700 (PDT) Received: from spandex (rtp-dial-1-114.cisco.com [10.83.97.114]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AJI02724; Fri, 15 Jun 2001 07:22:56 -0700 (PDT) Message-ID: <011a01c0f5a6$ca7f71e0$d45904d1@cisco.com> From: "Melinda Shore" To: "Fleischman, Eric W" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12D9B@XCH-NW-01.nw.nos.boeing.com> Subject: Re: [midcom] State in framework-02 Date: Fri, 15 Jun 2001 10:23:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > That is, that the teardown occurs solely > because of statefulness of the middlebox rather than > the statefulness of the protocol (i.e., any protocol > linkages between the Setup function and the Teardown > function). The other situation which hasn't been discussed is that the application is going to continue to retain state and that it will notify the agent when it releases a resource. The agent then sents the teardown request to the middlebox, but it's not retaining state itself. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 15 11:22:26 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 ESMTP id LAA11629 for ; Fri, 15 Jun 2001 11:22:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04152; Fri, 15 Jun 2001 11:12:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04123 for ; Fri, 15 Jun 2001 11:12:28 -0400 (EDT) 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 ESMTP id LAA11367 for ; Fri, 15 Jun 2001 11:11:54 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5FFC4k17724 for ; Fri, 15 Jun 2001 08:12:04 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-13.cisco.com [10.21.96.13]) by airborne.cisco.com (Mirapoint) with ESMTP id ADQ03846; Fri, 15 Jun 2001 08:11:55 -0700 (PDT) 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: <15146.9659.201000.548538@gargle.gargle.HOWL> Date: Fri, 15 Jun 2001 11:11:55 -0400 To: Subject: Re: [midcom] State in framework-02 In-Reply-To: <011a01c0f5a6$ca7f71e0$d45904d1@cisco.com> References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12D9B@XCH-NW-01.nw.nos.boeing.com> <011a01c0f5a6$ca7f71e0$d45904d1@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 15 Jun 2001 at 10:23 -0400, Melinda Shore apparently wrote: > > That is, that the teardown occurs solely > > because of statefulness of the middlebox rather than > > the statefulness of the protocol (i.e., any protocol > > linkages between the Setup function and the Teardown > > function). > > The other situation which hasn't been discussed is > that the application is going to continue to retain > state and that it will notify the agent when it releases > a resource. The agent then sents the teardown request > to the middlebox, but it's not retaining state itself. This is a scenario, but we're still allowing the possibility that an application may be completely naive, right? (more later) ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 15 11:41:31 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 ESMTP id LAA12222 for ; Fri, 15 Jun 2001 11:41:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05386; Fri, 15 Jun 2001 11:39:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05357 for ; Fri, 15 Jun 2001 11:39:53 -0400 (EDT) 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 ESMTP id LAA12147 for ; Fri, 15 Jun 2001 11:39:19 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5FFdM913041; Fri, 15 Jun 2001 08:39:22 -0700 (PDT) Received: from spandex (rtp-vpn-351.cisco.com [10.82.193.95]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AJI04339; Fri, 15 Jun 2001 08:39:20 -0700 (PDT) Message-ID: <017901c0f5b1$76dbb2a0$d45904d1@cisco.com> From: "Melinda Shore" To: "Scott Brim" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12D9B@XCH-NW-01.nw.nos.boeing.com><011a01c0f5a6$ca7f71e0$d45904d1@cisco.com> <15146.9659.201000.548538@gargle.gargle.HOWL> Subject: Re: [midcom] State in framework-02 Date: Fri, 15 Jun 2001 11:40:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > This is a scenario, but we're still allowing the possibility that an > application may be completely naive, right? Sure - the point was that it's possible for the agent to request state changes without having to retain state itself. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 15 14:50: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 ESMTP id OAA22836 for ; Fri, 15 Jun 2001 14:50:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12378; Fri, 15 Jun 2001 14:48:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12349 for ; Fri, 15 Jun 2001 14:48:48 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22744 for ; Fri, 15 Jun 2001 14:48:14 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5FImLU24959 for ; Fri, 15 Jun 2001 11:48:21 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-13.cisco.com [10.21.96.13]) by airborne.cisco.com (Mirapoint) with ESMTP id ADQ07492; Fri, 15 Jun 2001 11:48:15 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" Message-ID: <15146.22634.829000.607274@gargle.gargle.HOWL> Date: Fri, 15 Jun 2001 14:48:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Subject: Re: [midcom] State in framework-02 In-Reply-To: <017901c0f5b1$76dbb2a0$d45904d1@cisco.com> References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12D9B@XCH-NW-01.nw.nos.boeing.com> <011a01c0f5a6$ca7f71e0$d45904d1@cisco.com> <15146.9659.201000.548538@gargle.gargle.HOWL> <017901c0f5b1$76dbb2a0$d45904d1@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 15 Jun 2001 at 11:40 -0400, Melinda Shore apparently wrote: > > This is a scenario, but we're still allowing the possibility that an > > application may be completely naive, right? > > Sure - the point was that it's possible for the agent > to request state changes without having to retain state > itself. Nice and simple, isn't it? Here are some principles which might generate some text for Requirements ... We can use the end-to-end argument & fatesharing, and say the fate of state in the network should ultimately be controlled by the endpoints for whom it is installed in the first place. (Network operators can install state by configuration, but that's orthogonal.) This doesn't mean that endpoints have to say something explicit to get state installed -- in fact they probably won't -- but that whatever the action by an endpoint which triggered the installation of that state to start with, there has to be at least one trigger for removing it which is based on action or inaction by that endpoint. The fate of session-related state rests in the hands of the endpoints, whether they know it or not. Agents will either receive explicit cues from endpoints for deleting state (e.g. call teardown), or there will be reliable implicit cues, or they will have to have timers (of any kind). This is protocol-specific and thus agent-specific. We don't need to specify anything here. Since we're trying to minimize the amount of session-related state that middlefunctions generate for themselves, the midcom protocol must let agents give middleboxes explicit rules for when to remove state. Those rules could be, for example, to wait for explicit instructions from the agent, to delete when certain traffic (to/from an endpoint) hasn't been seen for some time, to delete after a certain absolute time, to delete when certain packets are seen from the endpoint(s), or to query the agent after a certain amount of time (this is Suresh's timer). We have to narrow down this list of possibilities in order to keep middleboxes simple. Also, since we already have multiple requirements on it, what do we do when contact with the middlebox is lost? I think we should make room for including a rule for that in the midcom protocol, but make it optional, and leave default behavior (per-agent) up to configuration. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 15 16:33: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 ESMTP id QAA28635 for ; Fri, 15 Jun 2001 16:33:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15777; Fri, 15 Jun 2001 16:31:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15745 for ; Fri, 15 Jun 2001 16:31:26 -0400 (EDT) Received: from web13804.mail.yahoo.com (web13804.mail.yahoo.com [216.136.175.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28455 for ; Fri, 15 Jun 2001 16:30:52 -0400 (EDT) Message-ID: <20010615203100.54422.qmail@web13804.mail.yahoo.com> Received: from [65.12.33.187] by web13804.mail.yahoo.com; Fri, 15 Jun 2001 13:31:00 PDT Date: Fri, 15 Jun 2001 13:31:00 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Framework draft review To: Scott Brim , midcom@ietf.org In-Reply-To: <15145.2395.712000.223809@gargle.gargle.HOWL> 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: > > detection, security and so forth. Network Address Translator > > service, on the other hand, provides routing transparency across > > address realms (within IPv4 routing network or across V4 and V6 > > routing realms). Application Level gateways (ALGs) are used in > > This use of "routing" came up in the NAT WG about 2 years ago, maybe > more. There was a long discussion and I thought Suresh had conceded. > In any case "routing" is misused here, assuming you mean IP routing. IP > routing information does not pass transparently through NATs. I would > change the first instance of "routing" to "forwarding" and delete the > other instances. > My use of the term "transparent routing" is consistent with what was agreed upon two years ago. You might refer section 2.2 of RFC 2663 for the term and its definition. > > The communication between a MIDCOM > > agent and a middlebox will be transparent to the end-hosts that > > take part in the application, unless one of the end-hosts assumes > > the role of a MIDCOM agent. > > I don't think "transparent" is a good word here. "Transparent" usually > means communications from the end host are passed through unchanged, > which this framework should not guarantee. I think you mean "does not > require changes to the end host". Do you? > I believe, the word "transparent" means "not noticeable". Transparency does not imply "unchanged". I believe, the usage of the term is appropriate. > > method performed on a network intermediary that requires application > > For clarity, you should change "on" to "by". > OK. > > 2.2. MiddleBox > > > > Middlebox is a network intermediate device that implements one or > > more of the middlebox services. A NAT middlebox is a middlebox > > implementing NAT service. A firewall middlebox is a middlebox > > implementing firewall service. > > At this point, please reiterate that middlefunctions can run on end > systems as well as routers or just about anywhere. > That is not correct. A middlebox is a netwrok intermediate device that transits an application - not one that terminates it. As such, an end-system will not be considered a middlebox. > > Network Address Translation is a method by which IP addresses are > > mapped from one address realm to another, providing transparent > > routing to end-hosts. This is achieved by modifying end node > > Same comment as above re "routing". > See my comments above. Refer RFC 2663. > > ALGs are different from proxies. ALGs are transparent to > > end-hosts, unlike the proxies which are relay agents terminating > > sessions with both end-hosts. ALGs do not terminate session with > > either end-host. Instead, ALGs examine and optionally modify > > application payload content to facilitate the flow of application > > traffic through a middlebox. ALGs are middlebox centric, in that > > Here you make it clear that ALGs are not "transparent" in the usual > sense. See suggested fix above. > Not really. The sentence reads... "The ALGS are transparent to end-hosts..." > > Policy Server is a management entity that acts in advisory > > capacity and interfaces with a middlebox to communicate policies > > Change "advisory" to "authoritative". Policy servers don't say "gee, I > don't think you should do that. > We had this thread before. "Advisory" was the term folks on the list wanted to see happen. You might also check with Melinda on this. She was one of the people who suggested this. I happen to agree with the usage as well. > > middlebox. In the case where a MIDCOM agent is not pre-configured, > > the middlebox will consult Policy Server out-of-band and obtain > > the agent profile to validate connection setup and authorization > > of the agent to gain access to middlebox resources. Once an agent > > is connected to the middlebox, the policy server may at anytime > > notify the middlebox to terminate authorization for the agent. > > > First, I'd delete out-of-band. Out-of-band of what? The relationship The "out-of-Band" here refers to Out-of-band of the MIDCOM protocol. > between middlebox and policy server is purely management. There is no > other data flow to be out-of-band of. > > Second, as discussed on the mailing list, there are two different kinds > of information which can be obtained from a policy server. You have the > them bundled together. The first is general authorization and limits > for an agent. The second is information regarding a particular request > from an agent. While a middlebox might obtain an agent "profile" either > before or when it first makes contact with that agent, it does not > necessarily obtain complete rules for treatment of requests from that > agent at that time. The text above requires that (or if it doesn't, > then you don't mention request-specific rules anywhere :-)). I would > add another sentence, something along the lines of "Policy regarding > treatment of specific agent requests may be obtained when the agent is > first authorized or at any time thereafter." > What sort of agent requests would require the middlebox to consult the Policy Server at run time? DO you have a specific example? We had a discussion on this thread. Somewhat inconclusive. SO, I didnt add any text that is suggestive or not-suggestive of the use of Policy Server at run-time by the middlebox. > > Resources such as a Session-Descriptor may be shared across > > middlebox functions. A Session-Descriptor may uniquely identify > > a session denoted by the tuple of (SessionDirection, > > SourceAddress, DestinationAddress, Protocol, SourcePort, > > DestinationPort). An aggregated Session-Descriptor, on the other > > hand, may have one of the tuple elements denoted by a regular > > expression (ex: Any source port). The attributes associated > > There's an unnecessary assumption here about what a "session" might be. > A "session" may be more specific than the exact-match tuple you propose, > as might regular expression descriptors. You demonstrate this in 5.1, > when you talk about "sub-sessions". I would leave out everything > between the first sentence and "The attributes associated ...". > I did use different words - "session-descriptors" and "Aggregate session descriptors". Are you refering to sessions from an application point of view (parent sessions, sub-sessions) vs session as an independent tuple from middlebox view point. My use of the terms above was within the context of middlebox. > > It is important to note that an agent and a middlebox can be on > > the same physical device. In such a case, it is not desirable > > for them to communicate using MIDCOM protocol. They may communicate > > using a MIDCOM protocol message formats, but using a non-IP based > > All true except leave out "it is not desirable for them to communicate > using MIDCOM protocol". It isn't up to us to judge implementations. We > do need to note (as you do) that they MAY communicate by any means. > OK. > > A MIDCOM session may be terminated by either of the parties. > > Alternately, a MIDCOM session termination may be triggered by > > one of (a) agent going out of service and not being available > > for further MIDCOM operations, or (b) a policy server notifying > > the middlebox that a particular MIDCOM agent is no longer > > authorized for a particular set of sessions any longer. > > The policy server telling the middlebox an agent is no longer authorized > does not terminate the midcom protocol. That's a completely separate > relationship. Leave this part out. > I am loosing you. Why do you expect that a MIDCOM session should not be terminated when the middlebox is notified by the Policy Server that the agent is no longer authorized? > Do we need to say, now, that the midcom protocol will have reason codes > in it? I don't think so. > > > (out of band stuff) > > I see no scope for an out-of-path agent for JUST control. As in, the > middlebox says "Hey, Charlie is trying to make such-and-such a > connection, what do I do?", and the oop agent says "do this for him", or > "return this error". What about, e.g., incoming calls? > The framework allows for Out-of-Path MIDCOM agents. However, the diversion function and its implmentation is out of scope for the MIDCOM protocol and this document. The specification and implmentation of diversion function can be proprietary for the middlebox vendor. The document says this. > > Agents are pre-registered with a Policy Server for authorization to > > gain access to a middlebox. > > Well, the middlebox doesn't know or need to know if they are > PRE-registered. They may be registering moments before they talk to the > middlebox. Change "are pre-registered" to "are registered". > OK. > > The policy server maintains a list of > > agents that are authorized to connect to each of the middleboxes the > > policy server supports. The Policy server has no knowledge of > > middlebox service and as such cannot help a middlebox with any of > > the middlebox services and the resource authorization. > > No knowledge? That's an assumption. We don't know yet what level of > detail will be required by communication between middlebox and policy > server. > OK. I will remove the following text: "has no Knowledge of middlebox Service". > > The policy server acts in an advisory capacity to a middlebox to > > The policy server is the policy authority (again). > See my comment earlier. > > authorize or terminate authorization for an agent to gain > > connectivity to the middlebox. The primary objective of a policy > > server is to communicate agent authorization information so as to > > ensure that the security and integrity of a middlebox is not > > jeopardized. Specifically, the policy server should associate a > > trust level with each agent attempting to connect to a middlebox > > and provide a security profile. The policy server should be capable > > of addressing cases when end-hosts are agents to the middle-box. > > See comment way up top about not restricting the policy server to this > limited coarse-grain ability. If we do, I guarantee that someone will > have to create another kind of policy server. > Again, we had this discussion. I believe, the document reflects it. > > of the key can decipher the message content. Lastly, replay > > protection is a form of sequence integrity so when an intruder > > plays back a previously recorded sequence of messages, the > > receiver of the replay messages will simply drop the replay > > messages into bit-bucket. Certain applications of the MIDCOM > > protocol might require support for non-repudiation as an option of > > the data integrity service. Typically, support for non-repudiation > > is required for billing, service level agreements, payment orders, > > and receipts for delivery of service. > > OK, but certain agent communications will need to be idempotent. We > need to think carefully about our security needs when we get to the > midcom protocol. > > > IPsec AH ([IPSEC-AH]) offers data-origin authentication, data > > integrity and protection from message replay. IPsec ESP > > ([IPSEC-ESP]) provides data-origin authentication to a lesser > > degree (same as IPsec AH if the MIDCOM transport protocol turns out > > to be TCP or UDP), message confidentiality, data integrity and > > protection from replay. Besides the IPsec based protocols, there > > are other security options as well. TLS based transport layer > > security is one option. There are also many application-layer > > security mechanisms available. Simple Source-address based > > security is the least form of security in a trusted domain and > > may be permitted to trusted hosts. > > Leave this entire paragraph out. We're not at the point where we should > be discussing which security mechanisms to use at all. > Right. But, this makes no recommendations. Just lists some of the known mechanisms. > > The premise of middlebox operation fundamentally requires > > stateful inspection of data in the clear. This compromises the > ... > > However, the MIDCOM protocol removes the need for a middlebox > > to inspect or manipulate data. This in turn allows applications > > Thus, I hope you mean, in the first excerpt, that *current* middlebox > operation requires stateful inspection. > Let me redo the first excerpt as follows. The premise of middlebox operation fundamentally requires the data to be in the clear as the middlebox needs the ability to inspect and/or modify packet headers and payload. > ...Scott > Thanks. cheers, suresh ===== __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 15 18:33:41 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 ESMTP id SAA00957 for ; Fri, 15 Jun 2001 18:33:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19493; Fri, 15 Jun 2001 18:30:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19406 for ; Fri, 15 Jun 2001 18:30:38 -0400 (EDT) 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 ESMTP id SAA00911 for ; Fri, 15 Jun 2001 18:30:02 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5FMUAk01546 for ; Fri, 15 Jun 2001 15:30:10 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-13.cisco.com [10.21.96.13]) by airborne.cisco.com (Mirapoint) with ESMTP id ADS00176; Fri, 15 Jun 2001 15:29:59 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" Message-ID: <15146.35939.370000.167641@gargle.gargle.HOWL> Date: Fri, 15 Jun 2001 18:29:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: midcom@ietf.org Subject: Re: [midcom] Framework draft review In-Reply-To: <20010615203100.54422.qmail@web13804.mail.yahoo.com> References: <15145.2395.712000.223809@gargle.gargle.HOWL> <20010615203100.54422.qmail@web13804.mail.yahoo.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 15 Jun 2001 at 13:31 -0700, Pyda Srisuresh apparently wrote: > --- Scott Brim wrote: > > > detection, security and so forth. Network Address Translator > > > service, on the other hand, provides routing transparency across > > > address realms (within IPv4 routing network or across V4 and V6 > > > routing realms). Application Level gateways (ALGs) are used in > > > > This use of "routing" came up in the NAT WG about 2 years ago, maybe > > more. There was a long discussion and I thought Suresh had conceded. > > In any case "routing" is misused here, assuming you mean IP routing. IP > > routing information does not pass transparently through NATs. I would > > change the first instance of "routing" to "forwarding" and delete the > > other instances. > > > > My use of the term "transparent routing" is consistent with what was > agreed upon two years ago. You might refer section 2.2 of RFC 2663 > for the term and its definition. Yes, I know. I recall there was never agreement, we just stopped arguing. The usual IETF story. But we can do better now. In everything I said in my mail, I'm trying to get to technical clarity, with the assumption that this draft *will* become a useful RFC and therefore had better not confuse anyone. That's where this comment on "routing" comes from. Do you agree that there is a difference between (IP layer) routing and forwarding? If not, you should take a look at the specifications and implemented products over the years which have separated them. GSMP comes to mind as a current activity. "GSMP provides an interface that can be used to separate the data forwarder from the routing and other control plane protocols such as LDP." (from http://www.ietf.org/internet-drafts/draft-ietf-gsmp-applicability-01.txt). "Routing" refers to the use of routing protocols to do path discovery and selection. When you say transparent "routing" you are not being clear. As I said, 2663 is not right in its use of the word, and it's only in there because we gave up arguing. > > > The communication between a MIDCOM > > > agent and a middlebox will be transparent to the end-hosts that > > > take part in the application, unless one of the end-hosts assumes > > > the role of a MIDCOM agent. > > > > I don't think "transparent" is a good word here. "Transparent" usually > > means communications from the end host are passed through unchanged, > > which this framework should not guarantee. I think you mean "does not > > require changes to the end host". Do you? > > > > I believe, the word "transparent" means "not noticeable". Transparency > does not imply "unchanged". I believe, the usage of the term is > appropriate. NAT is not noticeable. Would you dare to claim in front of an IETF Plenary that NAT is transparent? :-) Again, just like "routing" above, when you use this word you are opening up the possibility of misinterpretation, which you really don't want to do in a significant RFC. Don't use words which other people already use to mean something different, or if you do, make it clear what you mean (and that you are right). > > > 2.2. MiddleBox > > > > > > Middlebox is a network intermediate device that implements one or > > > more of the middlebox services. A NAT middlebox is a middlebox > > > implementing NAT service. A firewall middlebox is a middlebox > > > implementing firewall service. > > > > At this point, please reiterate that middlefunctions can run on end > > systems as well as routers or just about anywhere. > > > That is not correct. A middlebox is a netwrok intermediate device > that transits an application - not one that terminates it. As such, > an end-system will not be considered a middlebox. Yes, sorry, I was thinking about agents and middleboxes (or middlefunctions) simultaneously when I typed that. I think it would be good to reiterate that middlefunctions can run on routers. > > > ALGs are different from proxies. ALGs are transparent to > > > end-hosts, unlike the proxies which are relay agents terminating > > > sessions with both end-hosts. ALGs do not terminate session with > > > either end-host. Instead, ALGs examine and optionally modify > > > application payload content to facilitate the flow of application > > > traffic through a middlebox. ALGs are middlebox centric, in that > > > > Here you make it clear that ALGs are not "transparent" in the usual > > sense. See suggested fix above. > > > Not really. The sentence reads... "The ALGS are transparent to > end-hosts..." The other sentence says "optionally modify application payload content". Let's see what other people in the group think about calling this transparent. I know what the purists will say. Why goad them? > > > Policy Server is a management entity that acts in advisory > > > capacity and interfaces with a middlebox to communicate policies > > > > Change "advisory" to "authoritative". Policy servers don't say "gee, I > > don't think you should do that. > > > > We had this thread before. "Advisory" was the term folks on the list > wanted to see happen. > You might also check with Melinda on this. She was one of the people > who suggested this. I happen to agree with the usage as well. I look forward to hearing what people think. Discussion on the list often does not lead to conclusion, until we get to this stage. I for one can't imagine what "advisory" might mean in practice. When I "advise" my children, it means they have the option to discard what I say. What's a policy server for? Communicating policy-based information to parts of the infrastructure that don't have it. There may be other sources of policy which have more authority, but any policy server is certainly authoritative. Everyone? > > > middlebox. In the case where a MIDCOM agent is not pre-configured, > > > the middlebox will consult Policy Server out-of-band and obtain > > > the agent profile to validate connection setup and authorization > > > of the agent to gain access to middlebox resources. Once an agent > > > is connected to the middlebox, the policy server may at anytime > > > notify the middlebox to terminate authorization for the agent. > > > > > > First, I'd delete out-of-band. Out-of-band of what? The relationship > > The "out-of-Band" here refers to Out-of-band of the MIDCOM protocol. Out-of-band refers to communication between two entities which are normally communicating by some other means. For example, you dial up a modem connected to your router when you can't reach it otherwise. But the midcom protocol is not between the policy server and the middlebox, it's between the agent and the middlebox. First you have two different sets of endpoints (so calling one of the communications flows out of band makes no sense). Second, the communication flow you're talking about is the only one between middlebox and policy server, so again it can't be out of band of anything. I believe what you have in mind is that it's not in the main flow of packets from the endpoint through the middlebox. There's no need to say this. It's clear everywhere that the relation with the policy server is a network management one, orthogonal to any user session. > > between middlebox and policy server is purely management. There is no > > other data flow to be out-of-band of. > > > > Second, as discussed on the mailing list, there are two different kinds > > of information which can be obtained from a policy server. You have the > > them bundled together. The first is general authorization and limits > > for an agent. The second is information regarding a particular request > > from an agent. While a middlebox might obtain an agent "profile" either > > before or when it first makes contact with that agent, it does not > > necessarily obtain complete rules for treatment of requests from that > > agent at that time. The text above requires that (or if it doesn't, > > then you don't mention request-specific rules anywhere :-)). I would > > add another sentence, something along the lines of "Policy regarding > > treatment of specific agent requests may be obtained when the agent is > > first authorized or at any time thereafter." > > > What sort of agent requests would require the middlebox to consult > the Policy Server at run time? DO you have a specific example? > > We had a discussion on this thread. Somewhat inconclusive. > SO, I didnt add any text that is suggestive or not-suggestive of > the use of Policy Server at run-time by the middlebox. As I said, many conversations are inconclusive until we get this close to last call. Now's the time we work things out. OK, here's an example: I have a middlebox which handles communications for potentially millions of clients, although only a small number (hundreds?) will be active at any one time. Each customer is potentially different enough in enough ways that it would take significant effort to create aggregate rules for them. I don't want to store rules for all the millions of them in the middlebox since that would cost me more in hardware and in any case the initialization time would ruin my availability numbers. So I feed the middlebox some general policy to start with -- such as which agents are authorized for what, in general terms -- and when it gets a specific connection request, it queries the policy server which generates the customer-specific policy on the fly (from info in a database) and returns it. See? Agent-related policy comes first, then customer-related policy later. They don't have to, but I want to allow this possibility for the service providers. My concern here is that your language explicitly mentions the agent profile and stops as if that's all there is. Perhaps you could say something like ... "gain access to middlebox resources. A middlebox and a policy server may communicate further if the policy server's policy changes or if a middlebox needs further information." Also, I just noticed that in the last sentence of the paragraph you say "Once an agent is connected to the middlebox, the policy server may at anytime notify the middlebox to terminate authorization for the agent." First, the policy server can terminate authorization for that agent even before it connects to the middlebox :-). Second, if you use something like my proposed sentence above, this sentence is unnecessary because mine is a superset. > > > Resources such as a Session-Descriptor may be shared across > > > middlebox functions. A Session-Descriptor may uniquely identify > > > a session denoted by the tuple of (SessionDirection, > > > SourceAddress, DestinationAddress, Protocol, SourcePort, > > > DestinationPort). An aggregated Session-Descriptor, on the other > > > hand, may have one of the tuple elements denoted by a regular > > > expression (ex: Any source port). The attributes associated > > > > There's an unnecessary assumption here about what a "session" might be. > > A "session" may be more specific than the exact-match tuple you propose, > > as might regular expression descriptors. You demonstrate this in 5.1, > > when you talk about "sub-sessions". I would leave out everything > > between the first sentence and "The attributes associated ...". > > > > I did use different words - "session-descriptors" and "Aggregate session > descriptors". Are you refering to sessions from an application point of > view (parent sessions, sub-sessions) vs session as an independent tuple > from middlebox view point. My use of the terms above was within the > context of middlebox. From your response I think I failed to communicate, so I'll try again. I am talking about a "session" in the sense of what a middlebox might receive requests/instructions regarding, and which the middlebox might need to maintain state for. I think it's wrong to presuppose that a "session" is defined by the tuple you give. This is a framework. Let's wait and see what requirements there are, and what we want to do with the midcom protocol. > > > A MIDCOM session may be terminated by either of the parties. > > > Alternately, a MIDCOM session termination may be triggered by > > > one of (a) agent going out of service and not being available > > > for further MIDCOM operations, or (b) a policy server notifying > > > the middlebox that a particular MIDCOM agent is no longer > > > authorized for a particular set of sessions any longer. > > > > The policy server telling the middlebox an agent is no longer authorized > > does not terminate the midcom protocol. That's a completely separate > > relationship. Leave this part out. > > > I am loosing you. Why do you expect that a MIDCOM session should not be > terminated when the middlebox is notified by the Policy Server that the > agent is no longer authorized? They are two different events. (1) a policy server tells the middlebox an agent is not authorized. (2) the middlebox terminates the session with the agent. Event 2 is the real termination, and you've already covered it in the first sentence -- where you say either end can terminate the session. The second sentence, saying the session would be terminated if one of the parties might stop functioning, is also needed. But then adding reasons for the first sentence (the middlebox terminating the session) and putting "Alternately" in front, as if they were different, is not logically consistent. Another way to fix it would be just to delete "Alternately". > > Do we need to say, now, that the midcom protocol will have reason codes > > in it? I don't think so. > > > > > (out of band stuff) > > > > I see no scope for an out-of-path agent for JUST control. As in, the > > middlebox says "Hey, Charlie is trying to make such-and-such a > > connection, what do I do?", and the oop agent says "do this for him", or > > "return this error". What about, e.g., incoming calls? > > > > The framework allows for Out-of-Path MIDCOM agents. However, the diversion > function and its implmentation is out of scope for the MIDCOM protocol and > this document. The specification and implmentation of diversion function > can be proprietary for the middlebox vendor. The document says this. The diversion function is for packets from endpoints, right? I'm asking about a relationship where no packets are diverted to the agent. Let's start with a simpler situation and draw parallels. If this doesn't work I'll get more detailed later. Suppose you're a middlebox. You get a request from an agent to open a pinhole. You do so. Traffic from the endpoint flows through you. Endpoint traffic may flow through the agent but it need not. If it does not, then the relationship between agent and middlebox is control only. OK, now take your out-of-path case. Suppose traffic comes in and you signal an out-of-path agent that you want assistance. According to your text you then start diverting that traffic to it. However, you could just ask for assistance and get information back that you don't need to divert packets, you can do what you have to for them yourself. That's the case I'm asking about, which you have left out entirely, the parallel with the control-only agent in the previous paragraph. > > > The policy server acts in an advisory capacity to a middlebox to > > > > The policy server is the policy authority (again). > > > > See my comment earlier. Right. Looking for more list discussion. > > > of the key can decipher the message content. Lastly, replay > > > protection is a form of sequence integrity so when an intruder > > > plays back a previously recorded sequence of messages, the > > > receiver of the replay messages will simply drop the replay > > > messages into bit-bucket. Certain applications of the MIDCOM > > > protocol might require support for non-repudiation as an option of > > > the data integrity service. Typically, support for non-repudiation > > > is required for billing, service level agreements, payment orders, > > > and receipts for delivery of service. > > > > OK, but certain agent communications will need to be idempotent. We > > need to think carefully about our security needs when we get to the > > midcom protocol. > > > > > IPsec AH ([IPSEC-AH]) offers data-origin authentication, data > > > integrity and protection from message replay. IPsec ESP > > > ([IPSEC-ESP]) provides data-origin authentication to a lesser > > > degree (same as IPsec AH if the MIDCOM transport protocol turns out > > > to be TCP or UDP), message confidentiality, data integrity and > > > protection from replay. Besides the IPsec based protocols, there > > > are other security options as well. TLS based transport layer > > > security is one option. There are also many application-layer > > > security mechanisms available. Simple Source-address based > > > security is the least form of security in a trusted domain and > > > may be permitted to trusted hosts. > > > > Leave this entire paragraph out. We're not at the point where we should > > be discussing which security mechanisms to use at all. > > > Right. But, this makes no recommendations. Just lists some of the known > mechanisms. OK > > > The premise of middlebox operation fundamentally requires > > > stateful inspection of data in the clear. This compromises the > > ... > > > However, the MIDCOM protocol removes the need for a middlebox > > > to inspect or manipulate data. This in turn allows applications > > > > Thus, I hope you mean, in the first excerpt, that *current* middlebox > > operation requires stateful inspection. > > > > Let me redo the first excerpt as follows. > The premise of middlebox operation fundamentally requires the > data to be in the clear as the middlebox needs the ability to > inspect and/or modify packet headers and payload. Some middlefunctions do, some don't. I'm going to have to think about whether there's anything in the set we're restricting midcom to which does not require packets in the clear. Anybody else? Thanks ... Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Jun 17 19:15: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 ESMTP id TAA12849 for ; Sun, 17 Jun 2001 19:15:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28240; Sun, 17 Jun 2001 19:00:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28215 for ; Sun, 17 Jun 2001 19:00:37 -0400 (EDT) Received: from web13801.mail.yahoo.com (web13801.mail.yahoo.com [216.136.175.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12777 for ; Sun, 17 Jun 2001 19:00:02 -0400 (EDT) Message-ID: <20010617230034.72721.qmail@web13801.mail.yahoo.com> Received: from [65.12.33.187] by web13801.mail.yahoo.com; Sun, 17 Jun 2001 16:00:34 PDT Date: Sun, 17 Jun 2001 16:00:34 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] State in framework-02 To: "Fleischman, Eric W" , "'midcom@ietf.org'" In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12D9B@XCH-NW-01.nw.nos.boeing.com> 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 --- "Fleischman, Eric W" wrote: > The final two paragraphs of Section 4 addresses the > need for middlebox services to be stateful. I've been > puzzling over these two paragraphs over the last few > versions because Section 4 itself deals with the Midcom > protocol, rather than the middlebox, which was described > in Section 3. It appears to me that these two paragraphs > are misplaced and should be moved to Section 3. Interesting observation. The two paragraphs were indeed moved from section 3 in a previous rev to section 4. The text was intended to point out that MIDCOM protocol causes the middlebox to be stateful. So, it seemed reasonable to move this text to section 4, where MIDCOM protocol was discussed. > That is, > it appears that the authors' intent is NOT to make the > Midcom protocol be stateful between the Midcom Agent and > the middlebox nor to require that the Midcom Agent itself > be stateful. If so, this point needs to become more > explicitly stated. > As you rightly pointed out, none of the above were the intent. As for MIDCOM protocol being stateful or not, that is not in scope for the document - Not until a specific protocol proposal is in place. > That is, the final paragraph of Section 4 says in part: > "Explicit release of dynamically allocated resources > happens when the application session is ended or when > a Midcom agent requests the middlebox to release the > resource. However, the middlebox must be able to recover > the dynamically allocated resources at some point in time > even if the agent that was responsible for the dynamic > allocation is not alive. ..." > The above paragraph says nothing about the statefulness (or the lack of) of the MIDCOM protocol. Just that it should be able to recover a resource, in case of a possible unannounced demisal of an agent. > It has been Boeing's experience that application-level > gateways have been unusually expensive and resource- > intensive to maintain over time. This is especially the > case if the protocols which they are "linking" are > themselves stateful, because should the gateway's > state machine enter an indeterminate state (e.g., due > to an unanticipated melding of the states of the two > protocols), which occurs vastly more often than one would > hope, the gateway inevitably hangs. From protracted > painful and expensive experience, we have learned to > prefer approaches which are as stateless as possible > (fully realizing that there are good reasons why many > protocols need to be stateful) because they tend to be > easier to maintain and support over time. > I understand, you are advocating a stateless MIDCOM protocol. Stateless and stateful types are different mechanisms to accomplish the same MIDCOM protocol. As you point out, there are pros and cons. At best, we could point out the two alternatives, but not mandate or recommend one over the other at this time. > Similarly, denial of service exploits are the more > effective for stateful protocols, a point which was > made in Radia Perlman and Charlie Kaufman's recent article > in IEEE Internet Computing magazine ("Key Exchange > in IPSec: Analysis of IKE", November/December 2000; see > the Cookies section on page 53). > See my comment above. > For these reasons, it would be desirable if we would > explicitly not require the Midcom Agent to be stateful > (but allow statefulness there if needed) and, more > importantly, that we explicitly design a midcom > protocol that did not require protocol state to be > kept after the setup. > I dont think, we should mandate one or the other. > That is, the current draft implies that the Midcom > protocol will perform two functions: (1) Setup and (2) > Teardown where the former opens a hole through the > middlebox and the latter closes it. The current text > implies that the latter is optional, and that timers on > the middlebox will close the hole if no Teardown happens. The text does not say that MIDCOM session teardown as optional. Specifically, below is the text describing MIDCOM session teardown in section 4.0. A MIDCOM session may be terminated by either of the parties. Alternately, a MIDCOM session termination may be triggered by one of (a) agent going out of service and not being available for further MIDCOM operations, or (b) a policy server notifying the middlebox that a particular MIDCOM agent is no longer authorized for a particular set of sessions any longer. The document says that middlebox has to be concerned with agents disappearing, without prior announcement. As such, the middlebox shoudl be able to monitor dynamic recources allocated by the agent. > This is great. What I'd like to see is a mention that > if Teardown happens, then it occurs because the Middlebox > has tracked which Midcom agent set up which Session Descriptor. That is, that > the teardown occurs solely > because of statefulness of the middlebox rather than > the statefulness of the protocol (i.e., any protocol > linkages between the Setup function and the Teardown > function). I do not understand what you say. Why should a teardown (of a MIDCOM session) occur because of the statefulness of the middlebox or the statefulness of the MIDCOM protocol? > > --Eric > Eric and others - If this whole discussion seems like it is going overboard, I am OK to get rid of the said two paragraphs (in section 4). The specific text is not that critical to the document, I believe. Thanks. cheers, suresh __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 18 07:19:57 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 ESMTP id HAA03369 for ; Mon, 18 Jun 2001 07:19:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25613; Mon, 18 Jun 2001 07:16:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25584 for ; Mon, 18 Jun 2001 07:16:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03275; Mon, 18 Jun 2001 07:16:22 -0400 (EDT) Message-Id: <200106181116.HAA03275@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 18 Jun 2001 07:16:22 -0400 Subject: [midcom] I-D ACTION:draft-sijben-midcom-threat-analyisis-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Threat analysis of architectures for firewall traversal Author(s) : P. Sijben Filename : draft-sijben-midcom-threat-analyisis-00.txt Pages : 7 Date : 15-Jun-01 Recently a number of architectures have been proposed to allow sessions with multiple data streams to pass through firewalls. Examples of such sessions are IP telephony and multimedia sessions. This draft provides a threat analysis on three architectures offered to address this issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sijben-midcom-threat-analyisis-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-sijben-midcom-threat-analyisis-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-sijben-midcom-threat-analyisis-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: <20010615112700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sijben-midcom-threat-analyisis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sijben-midcom-threat-analyisis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010615112700.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 18 10:52: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 ESMTP id KAA09343 for ; Mon, 18 Jun 2001 10:52:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02948; Mon, 18 Jun 2001 10:44:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02917 for ; Mon, 18 Jun 2001 10:44:21 -0400 (EDT) Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09145 for ; Mon, 18 Jun 2001 10:43:48 -0400 (EDT) Message-ID: <20010618144419.65007.qmail@web13802.mail.yahoo.com> Received: from [65.12.33.187] by web13802.mail.yahoo.com; Mon, 18 Jun 2001 07:44:19 PDT Date: Mon, 18 Jun 2001 07:44:19 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Framework draft review To: Scott Brim , midcom@ietf.org In-Reply-To: <15146.35939.370000.167641@gargle.gargle.HOWL> 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: > On 15 Jun 2001 at 13:31 -0700, Pyda Srisuresh apparently wrote: > > --- Scott Brim wrote: > > > > detection, security and so forth. Network Address Translator > > > > service, on the other hand, provides routing transparency across > > > > address realms (within IPv4 routing network or across V4 and V6 > > > > routing realms). Application Level gateways (ALGs) are used in > > > > > > This use of "routing" came up in the NAT WG about 2 years ago, maybe > > > more. There was a long discussion and I thought Suresh had conceded. > > > In any case "routing" is misused here, assuming you mean IP routing. IP > > > routing information does not pass transparently through NATs. I would > > > change the first instance of "routing" to "forwarding" and delete the > > > other instances. > > > > > > > My use of the term "transparent routing" is consistent with what was > > agreed upon two years ago. You might refer section 2.2 of RFC 2663 > > for the term and its definition. > > Yes, I know. I recall there was never agreement, we just stopped > arguing. The usual IETF story. But we can do better now. > Well, your recollection is wrong. The dicussion was conclusive. The definition and subsequent use of the term were a direct result of the discussion. Check with the IESG and others that were party to the conversation at the time. <... stuff deleted> > > > > The communication between a MIDCOM > > > > agent and a middlebox will be transparent to the end-hosts that > > > > take part in the application, unless one of the end-hosts assumes > > > > the role of a MIDCOM agent. > > > > > > I don't think "transparent" is a good word here. "Transparent" usually > > > means communications from the end host are passed through unchanged, > > > which this framework should not guarantee. I think you mean "does not > > > require changes to the end host". Do you? > > > > > > > I believe, the word "transparent" means "not noticeable". Transparency > > does not imply "unchanged". I believe, the usage of the term is > > appropriate. > > NAT is not noticeable. Would you dare to claim in front of an IETF > Plenary that NAT is transparent? :-) Again, just like "routing" above, > when you use this word you are opening up the possibility of > misinterpretation, which you really don't want to do in a significant > RFC. Don't use words which other people already use to mean something > different, or if you do, make it clear what you mean (and that you are > right). > Scott - I suggest, you read the draft carefully before you jump into innuendo. I will not have a problem reiterating what I said in front of a plenary, if necessary. NAT performs transparent routing. The document does not state that NAT performs end-to-end application transparency. Your refering to this (MIDCOM framework) as a significant RFC implies that RFC 2663 and all other RFCs that refered the term are insignificant. That was uncalled for. I expected better than that from you. <... stuff deleted> > > > > Policy Server is a management entity that acts in advisory > > > > capacity and interfaces with a middlebox to communicate policies > > > > > > Change "advisory" to "authoritative". Policy servers don't say "gee, I > > > don't think you should do that. > > > > > > > We had this thread before. "Advisory" was the term folks on the list > > wanted to see happen. > > You might also check with Melinda on this. She was one of the people > > who suggested this. I happen to agree with the usage as well. > > I look forward to hearing what people think. Discussion on the list > often does not lead to conclusion, until we get to this stage. > Have you looked at the thread? Did the thread seem like it was inconclusive to you? (or) Do you consider a discussion conclusive, only when you initiate the thread? From your blanket comments, it sounds like you havent looked at the thread. > I for one can't imagine what "advisory" might mean in practice. When I > "advise" my children, it means they have the option to discard what I > say. What's a policy server for? Communicating policy-based > information to parts of the infrastructure that don't have it. There > may be other sources of policy which have more authority, but any policy > server is certainly authoritative. Everyone? > The policy server is not the enforcing entity and hence is not authoritative. > > > > middlebox. In the case where a MIDCOM agent is not pre-configured, > > > > the middlebox will consult Policy Server out-of-band and obtain > > > > the agent profile to validate connection setup and authorization > > > > of the agent to gain access to middlebox resources. Once an agent > > > > is connected to the middlebox, the policy server may at anytime > > > > notify the middlebox to terminate authorization for the agent. > > > > > > > > > First, I'd delete out-of-band. Out-of-band of what? The relationship > > > > The "out-of-Band" here refers to Out-of-band of the MIDCOM protocol. > > Out-of-band refers to communication between two entities which are > normally communicating by some other means. For example, you dial up a > modem connected to your router when you can't reach it otherwise. But > the midcom protocol is not between the policy server and the middlebox, > it's between the agent and the middlebox. First you have two different > sets of endpoints (so calling one of the communications flows out of > band makes no sense). Second, the communication flow you're talking > about is the only one between middlebox and policy server, so again it > can't be out of band of anything. > > I believe what you have in mind is that it's not in the main flow of > packets from the endpoint through the middlebox. There's no need to say > this. It's clear everywhere that the relation with the policy server is > a network management one, orthogonal to any user session. > OK. I will delete 'out-of-band'. Thanks. > > > between middlebox and policy server is purely management. There is no > > > other data flow to be out-of-band of. > > > > > > Second, as discussed on the mailing list, there are two different kinds > > > of information which can be obtained from a policy server. You have the > > > them bundled together. The first is general authorization and limits > > > for an agent. The second is information regarding a particular request > > > from an agent. While a middlebox might obtain an agent "profile" either > > > before or when it first makes contact with that agent, it does not > > > necessarily obtain complete rules for treatment of requests from that > > > agent at that time. The text above requires that (or if it doesn't, > > > then you don't mention request-specific rules anywhere :-)). I would > > > add another sentence, something along the lines of "Policy regarding > > > treatment of specific agent requests may be obtained when the agent is > > > first authorized or at any time thereafter." > > > > > What sort of agent requests would require the middlebox to consult > > the Policy Server at run time? DO you have a specific example? > > > > We had a discussion on this thread. Somewhat inconclusive. > > SO, I didnt add any text that is suggestive or not-suggestive of > > the use of Policy Server at run-time by the middlebox. > > As I said, many conversations are inconclusive until we get this close > to last call. Now's the time we work things out. > > OK, here's an example: I have a middlebox which handles communications > for potentially millions of clients, although only a small number > (hundreds?) will be active at any one time. Each customer is > potentially different enough in enough ways that it would take > significant effort to create aggregate rules for them. I don't want to > store rules for all the millions of them in the middlebox since that > would cost me more in hardware and in any case the initialization time > would ruin my availability numbers. So I feed the middlebox some > general policy to start with -- such as which agents are authorized for > what, in general terms -- and when it gets a specific connection > request, it queries the policy server which generates the > customer-specific policy on the fly (from info in a database) and > returns it. See? Agent-related policy comes first, then > customer-related policy later. They don't have to, but I want to allow > this possibility for the service providers. > > My concern here is that your language explicitly mentions the agent > profile and stops as if that's all there is. Perhaps you could say > something like ... "gain access to middlebox resources. A middlebox and > a policy server may communicate further if the policy server's policy > changes or if a middlebox needs further information." > OK. > Also, I just noticed that in the last sentence of the paragraph you say > "Once an agent is connected to the middlebox, the policy server may at > anytime notify the middlebox to terminate authorization for the agent." > First, the policy server can terminate authorization for that agent even > before it connects to the middlebox :-). Second, if you use something > like my proposed sentence above, this sentence is unnecessary because > mine is a superset. > You are right. However, I would still like to keep the sentence, without the precondition. I.e., The policy server may at anytime notify the middlebox to terminate authorization for an agent. > > > > Resources such as a Session-Descriptor may be shared across > > > > middlebox functions. A Session-Descriptor may uniquely identify > > > > a session denoted by the tuple of (SessionDirection, > > > > SourceAddress, DestinationAddress, Protocol, SourcePort, > > > > DestinationPort). An aggregated Session-Descriptor, on the other > > > > hand, may have one of the tuple elements denoted by a regular > > > > expression (ex: Any source port). The attributes associated > > > > > > There's an unnecessary assumption here about what a "session" might be. > > > A "session" may be more specific than the exact-match tuple you propose, > > > as might regular expression descriptors. You demonstrate this in 5.1, > > > when you talk about "sub-sessions". I would leave out everything > > > between the first sentence and "The attributes associated ...". > > > > > > > I did use different words - "session-descriptors" and "Aggregate session > > descriptors". Are you refering to sessions from an application point of > > view (parent sessions, sub-sessions) vs session as an independent tuple > > from middlebox view point. My use of the terms above was within the > > context of middlebox. > > From your response I think I failed to communicate, so I'll try again. > I am talking about a "session" in the sense of what a middlebox might > receive requests/instructions regarding, and which the middlebox might > need to maintain state for. I think it's wrong to presuppose that a > "session" is defined by the tuple you give. This is a framework. Let's > wait and see what requirements there are, and what we want to do with > the midcom protocol. > > > > > A MIDCOM session may be terminated by either of the parties. > > > > Alternately, a MIDCOM session termination may be triggered by > > > > one of (a) agent going out of service and not being available > > > > for further MIDCOM operations, or (b) a policy server notifying > > > > the middlebox that a particular MIDCOM agent is no longer > > > > authorized for a particular set of sessions any longer. > > > > > > The policy server telling the middlebox an agent is no longer authorized > > > does not terminate the midcom protocol. That's a completely separate > > > relationship. Leave this part out. > > > > > I am loosing you. Why do you expect that a MIDCOM session should not be > > terminated when the middlebox is notified by the Policy Server that the > > agent is no longer authorized? > > They are two different events. (1) a policy server tells the middlebox > an agent is not authorized. (2) the middlebox terminates the session > with the agent. Event 2 is the real termination, and you've already > covered it in the first sentence -- where you say either end can > terminate the session. The second sentence, saying the session would be > terminated if one of the parties might stop functioning, is also needed. > But then adding reasons for the first sentence (the middlebox > terminating the session) and putting "Alternately" in front, as if they > were different, is not logically consistent. > I dont see this as altering the meaning. > Another way to fix it would be just to delete "Alternately". > OK, if that makes it a better read. > > > Do we need to say, now, that the midcom protocol will have reason codes > > > in it? I don't think so. > > > > > > > (out of band stuff) > > > > > > I see no scope for an out-of-path agent for JUST control. As in, the > > > middlebox says "Hey, Charlie is trying to make such-and-such a > > > connection, what do I do?", and the oop agent says "do this for him", or > > > "return this error". What about, e.g., incoming calls? > > > > > > > The framework allows for Out-of-Path MIDCOM agents. However, the diversion > > function and its implmentation is out of scope for the MIDCOM protocol and > > this document. The specification and implmentation of diversion function > > can be proprietary for the middlebox vendor. The document says this. > > The diversion function is for packets from endpoints, right? I'm asking > about a relationship where no packets are diverted to the agent. > > Let's start with a simpler situation and draw parallels. If this > doesn't work I'll get more detailed later. Suppose you're a middlebox. > You get a request from an agent to open a pinhole. You do so. Traffic > from the endpoint flows through you. Endpoint traffic may flow through > the agent but it need not. If it does not, then the relationship > between agent and middlebox is control only. > > OK, now take your out-of-path case. Suppose traffic comes in and you > signal an out-of-path agent that you want assistance. According to your > text you then start diverting that traffic to it. However, you could During connection establishment, an agent would identify itself as Out-Of-Path(OOP) to the middlebox. The middlebox does not know that it wants assistance when it sees some traffic. The middlebox merely looks to see if there is an OOP agent that controls the session. And if there is, the packet is diverted to OOP agent. > just ask for assistance and get information back that you don't need to > divert packets, you can do what you have to for them yourself. That's Presumably, MIDCOM agents monitor only those application sessions that require the agent to examine the packet payload. If there is no need for a session to be monitored by an agent, either an agent is not associated with the session (or) if there was an agent to satrt with. the agent may simply choose to disassociate itself from the session. For example, an OOP FTP agent doesnt care to monitor FTP data sessions. so, it doesnt insert itself as the controlling agent for the data sessions. > the case I'm asking about, which you have left out entirely, the > parallel with the control-only agent in the previous paragraph. > See my comments above. <... stuff deleted> cheers, suresh ===== __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 18 12:09: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 ESMTP id MAA11371 for ; Mon, 18 Jun 2001 12:09:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06424; Mon, 18 Jun 2001 12:02:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06393 for ; Mon, 18 Jun 2001 12:01:58 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11100 for ; Mon, 18 Jun 2001 12:01:25 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA07444 for ; Mon, 18 Jun 2001 09:01:22 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA22571 for ; Mon, 18 Jun 2001 09:01:54 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP for midcom@ietf.org; Mon, 18 Jun 2001 09:01:43 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 09:01:42 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12D9D@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'midcom@ietf.org'" Date: Mon, 18 Jun 2001 09:01:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] Out-of-Path Midcom Agents in framework-02 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've now been through the email archives and I've failed to find a discussion concerning the strengths and weaknesses of permitting out-of- path Midcom agents. I question the wisdom of specifying out-of-path Midcom agents because the provision is an excellent mechanism to be exploited by hackers, crackers, and DoS attacks. The natural fit of this provision for these types of exploits is so obvious that I question why this provision was added to the framework document. The sparse examples within the text are noncompelling (e.g., FTP), since one could easily accomplish the same thing via in-path agents, and this particular provision of FTP has been criticized in security circles for some time. Therefore, I'd like to either have a very strong justification for this provision be added to the text or else have the provision removed as unacceptably dangerous. Either way, we need a discussion on this capability. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 18 13:05: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 ESMTP id NAA13517 for ; Mon, 18 Jun 2001 13:05:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07678; Mon, 18 Jun 2001 12:34:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07648 for ; Mon, 18 Jun 2001 12:34:48 -0400 (EDT) Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12276 for ; Mon, 18 Jun 2001 12:34:14 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id LAA22429 for ; Mon, 18 Jun 2001 11:35:37 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 18 Jun 2001 10:26:03 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 10:26:02 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BBFA8@crchy271.us.nortel.com> From: "Sanjoy Sen" To: "'midcom@ietf.org'" Cc: "Sanjoy Sen" , "Mary Barnes" Subject: RE: [midcom] Framework draft review Date: Mon, 18 Jun 2001 10:25:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F80A.FA4967D0" 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_001_01C0F80A.FA4967D0 Content-Type: text/plain; charset="iso-8859-1" Here're some feedback from myself & Mary Barnes on the Framework draft. Please find our comments within the delimiters, such as [SS] and [/SS]. Regards, Sanjoy ======================= 1. Introduction ---------------- 3rd sentence: Network Address Translator service, on the other hand, provides routing transparency across address realms (within IPv4 routing network or across V4 and V6 routing realms). Application Level gateways (ALGs) are used in conjunction with NAT to provide end-to-end transparency for many of the applications. [MB] I think this has already been discussed before, but transparency is not a term here for either of these sentences. I would suggest rewording these 2 sentences as: The address mapping of Network Address Translation (within IPv4 routing network or across V4 and V6 routing realms), however, is independent from the end application. An Application Level Gateway (ALG) used in conjunction with NAT can remove the knowledge of NATs for applications for which NATs are problematic. [/MB] 2.5. Proxy A proxy is an intermediate relay agent between clients and servers of an application, relaying application messages between the two. Proxies use special protocol mechanisms to communicate with proxy clients and relay client data to servers and vice versa. [SS] The proxies described here are application layer proxies. There're other types of proxies which relays the transport stream (Transport layer proxies), such as an RTP proxy, without higher layer application awareness. These two types should perhaps be distinguished. The reason is that while application layer proxies can be a type of Midcom agent, the transport layer proxies can be a type of Middle-Box (and I think that Midcom is a general framework with the eventual goal of addressing all kinds of Middleboxes). Proxies which are application-unaware but need application-specific intelligence are also Middle-boxes. [/SS] 2.8. MIDCOM Agents MIDCOM agents are entities performing ALG function, ... [SS] Why only ALG's? Application layer proxies (since you've distinguished between ALG's & proxies) can also be Midcom agents, as you've provided some examples in the next paragraph. [/SS] The protocol will allow MIDCOM agents to signal the middleboxes to let complex applications using dynamic port based sessions through them (i.e., middleboxes) seamlessly. [SS] There are additional protocol requirements which may need to be addressed here (or perhaps in the Requirements draft), such as the following. The protocol should allow exchange of state synchronization information (such as resource availability, state of the binding in case NAT's, health-checks etc) between the Midcom Agent & the Middle-box. The protocol should also allow modification of state in the Middle-box during runtime. The protocol should be able to specify direction of the connection through the Middle-box. [/SS] Connection setup must be preceded by registration of the MIDCOM agent with either the middlebox or the Policy Server. [SS] There might be situations where this registration process is initiated by the Middle-box itself. So, isn't it better to phrase the above sentence as "Connection set-up must be preceded by a registration phase between the Midcom agent and either the Middle-box or the Policy server". This also concurrs more with the text in the Protocol Requirements DRAFT. [/SS] Alternately, a MIDCOM session termination may be triggered by one of (a) agent going out of service and not being available for further MIDCOM operations, .... [SS] It would also be triggered by the Middle-box going out of service. [/SS] During connection establishment, an agent would identify itself as either In-Path or Out-Of-Path(OOP) to the middlebox. [SS] This should be during Registration phase, right? Is support of OOP Midcom agent (& the associated "diversion" function in the Middle-box), mandatory under the framework or is it optional? This should be mentioned too. [/SS] Profile of a MIDCOM agent includes agent authorization policy (i.e, session tuples for which the agent is authorized to act as ALG), ... [SS] Please define Session Tuple. If its the Session id , then in many cases, the MA doesn't know about it until the session is being initiated (e.g., SIP session). It may not be possible for the MA to have this information during the time of registration. [/SS] 4. MIDCOM Protocol [MB] Initially, I was in agreement with Eric Fleishman's comments that the last 2 paragraphs of Section 4 are misplaced as they describe functionality of the Middlebox (stateful vs. stateless) rather than the protocol itself. However, in re-reading, I think that the concept is also protocol related (i.e. which messages effect a change in the Protocol state machine). Perhaps, there needs to be a paragraph in Section 3 such as: Some middlebox services are stateless. However, there are many that are stateful and maintain per-connection state in the system. Firewall service may be implemented as a stateless list of ACLs. Many firewall implementations, however, are stateful. NAT service, on the other hand, is inherently stateful. As such, support of the MIDCOM protocol will require a middlebox to be stateful. Refer to Section 4.0 for further detail. And a paragraph in Section 4 (replacing the current last 2 paragraphs) that reads something like: The MIDCOM protocol may require a middlebox to be stateful. For the case of a middlebox implementing firewall service, with the advent of MIDCOM protocol, the middlebox is required to allocate dynamic resources, such as pin-holes, upon request from agents. Explicit release of dynamically allocated resources happens when the application session is ended or when a Midcom agent requests the middlebox to release the resource. However, the middlebox must be able to recover the dynamically allocated resources at some point in time even if the agent that was responsible for the dynamic allocation is not alive. Typically, this is done by tracking the state of each dynamically allocated pin-hole with some type of a timer. This exemplifies that even the firewall function will need to maintain per-connection state, as a requirement to support the MIDCOM protocol. [/MB] The technique described above is necessary for the pre-registration of MIDCOM agents with the Middlebox. However, it is possible to retain the provisioning on middlebox unchanged, by requiring MIDCOM agents to initiate the connection to middlebox. In such a case, the agent should initiate the connection prior to the start of the application. ... [SS] I assume that you're talking about Registration connection here. How does the Midcom agent know when to initiate this connection? Again, going back to the SIP example, the agent can only initiate the connection on receipt of a SIP INVITE message. It makes sense to me for apriori registration between the MB & MA, & MA be ready for connection set-up whenever required. The registration is refreshed periodically. [/SS] [SS] Typo in the third line of last para of page 20 - "... media stream, When used" [/SS] Section 7.3 - Middlebox implementing NAPT & Firewall call flows: | | | | | |++Permit RTP1 & RTCP1 | | | | sessions External to| | | | middlebox, namely | | | | Ma to Ea:Eport1, | | | | Ma to Ea:Eport1+1 | | | | sessions ++++++++++>| | | |<+Ma to Ea:Eport1, | | | | Ma to Ea:Eport1+1 | | | | sessions OKed ++++++| [SS] Should this be Ma or is it Pa? For certain types of NAPT, you won't be able to complete the binding & update the NAPT table until you know the port address of the callee, which is not part of the SDP in INVITE. In many cases, the SDP of the callee (containing the port) is carried in the provisional response 180/183, and Early Media follows the provisional response. The MA should be able to complete the NAPT binding based on the SDP of the callee in the response message, to allow early media. [/SS] 9.3. Asynchronous notification to MIDCOM agents Asynchronous notification by the middlebox to a MIDCOM agent can be useful for events such as Session creation, Session termination, MIDCOM protocol failure, Middlebox function failure or any other significant event. Independently, ICMP error codes can also be useful to notify transport layer failures to the agents. ... [SS] We should perhaps also include the following: - Exchange state synchronization information (described earlier) - Periodic health check message exchange - MB send logs of unauthorized access & unsolicitated alarms to the MA [/SS] Regards, Sanjoy Sen ------_=_NextPart_001_01C0F80A.FA4967D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Framework draft review

Here're some feedback from myself & Mary Barnes = on the Framework draft. Please find our comments within the delimiters, = such as [SS] and [/SS].

Regards,
Sanjoy

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
1. Introduction
----------------

3rd sentence: Network Address Translator service, on = the other hand, provides routing transparency across address realms = (within IPv4 routing network or across V4 and V6 routing realms). = Application Level gateways (ALGs) are used in conjunction with NAT to = provide end-to-end transparency for many of the applications. =

[MB] I think this has already been discussed before, = but transparency is not a term here for either of these = sentences.  I would suggest rewording these 2 sentences = as:

The address mapping of Network Address Translation = (within IPv4 routing network or across V4 and V6 routing realms), = however, is independent from the end application. An Application Level = Gateway (ALG) used in conjunction with NAT can remove the knowledge of = NATs for applications for which NATs are problematic. [/MB]

2.5. Proxy

   A proxy is an intermediate relay agent = between clients and servers
   of an application, relaying application = messages between the two.
   Proxies use special protocol mechanisms = to communicate with proxy
   clients and relay client data to = servers and vice versa.

[SS] The proxies described here are application layer = proxies. There're other types of proxies which relays the transport = stream (Transport layer proxies), such as an RTP proxy, without higher = layer application awareness. These two types should perhaps be = distinguished. The reason is that while application layer proxies can = be a type of Midcom agent, the transport layer proxies can be a type of = Middle-Box (and I think that Midcom is a general framework with the = eventual goal of addressing all kinds of Middleboxes). Proxies which = are application-unaware but need application-specific intelligence are = also Middle-boxes. [/SS]


2.8. MIDCOM Agents

   MIDCOM agents are entities performing = ALG function, ...

[SS] Why only ALG's? Application layer proxies (since = you've distinguished between ALG's & proxies) can also be Midcom = agents, as you've provided some examples in the next paragraph. = [/SS]

   The protocol will allow MIDCOM agents to = signal
   the middleboxes to let complex = applications using dynamic port
   based sessions through them (i.e., = middleboxes) seamlessly.

[SS] There are additional protocol requirements which = may need to be addressed here (or perhaps in the Requirements draft), = such as the following. The protocol should allow exchange of state = synchronization information (such as resource availability, state of = the binding in case NAT's, health-checks etc) between the Midcom Agent = & the Middle-box. The protocol should also allow modification of = state in the Middle-box during runtime. The protocol should be able to = specify direction of the connection through the Middle-box. [/SS]=

   Connection setup must be preceded by = registration of the
   MIDCOM agent with either the middlebox = or the Policy Server.

[SS] There might be situations where this = registration process is initiated by the Middle-box itself. So, isn't = it better to phrase the above sentence as "Connection set-up must = be preceded by a registration phase between the Midcom agent and either = the Middle-box or the Policy server". This also concurrs more with = the text in the Protocol Requirements DRAFT. [/SS]

   Alternately, a MIDCOM session = termination may be triggered by
   one of (a) agent going out of service = and not being available
   for further MIDCOM operations, = ....

[SS] It would also be triggered by the Middle-box = going out of service. [/SS]

   During connection establishment, an = agent would identify
   itself as either In-Path or = Out-Of-Path(OOP) to the middlebox.

[SS] This should be during Registration phase, right? =
Is support of OOP Midcom agent (& the associated = "diversion" function in the Middle-box), mandatory under the = framework or is it optional? This should be mentioned too. = [/SS]

   Profile of a MIDCOM agent includes agent = authorization policy (i.e,
   session tuples for which the agent is = authorized to act as ALG), ...

[SS] Please define Session Tuple. If its the Session = id <Src./Dest. IP address/port, protocol>, then in many cases, = the MA doesn't know about it until the session is being initiated = (e.g., SIP session). It may not be possible for the MA to have this = information during the time of registration. [/SS]

4. MIDCOM Protocol

[MB] Initially, I was in agreement with Eric = Fleishman's comments that the last 2 paragraphs of Section 4 are = misplaced as they describe functionality of the Middlebox (stateful vs. = stateless) rather than the protocol itself. However, in re-reading, I = think that the concept is also protocol related (i.e. which messages = effect a change in the Protocol state machine). Perhaps, there needs to = be a paragraph in Section 3 such as:

   Some middlebox services are stateless. = However, there are many that
   are stateful and maintain = per-connection state in the system.
   Firewall service may be implemented as = a stateless list of ACLs.
   Many firewall implementations, however, = are stateful. NAT
   service, on the other hand, is = inherently stateful. As such,
   support of the MIDCOM protocol will = require a middlebox to be
   stateful. Refer to Section 4.0 for = further detail.    

And a paragraph in Section 4 (replacing the current = last 2 paragraphs) that reads something like:

   The MIDCOM protocol may require a = middlebox to be
   stateful. For the case of a middlebox = implementing firewall
   service, with the advent of MIDCOM = protocol, the middlebox is
   required to allocate dynamic resources, = such as pin-holes,
   upon request from agents. Explicit = release of dynamically
   allocated resources happens when the = application session is
   ended or when a Midcom agent requests = the middlebox to release
   the resource. However, the middlebox = must be able to recover the
   dynamically allocated resources at some = point in time even if
   the agent that was responsible for the = dynamic allocation is not
   alive. Typically, this is done by = tracking the state of each
   dynamically allocated pin-hole with = some type of a timer.
   This exemplifies that even the firewall = function will need to
   maintain per-connection state, as a = requirement to support the
   MIDCOM protocol.

[/MB]


   The technique described above is = necessary for the pre-registration of MIDCOM agents with the
   Middlebox. However, it is possible to = retain the provisioning on middlebox unchanged, by
   requiring MIDCOM agents to initiate the = connection to middlebox. In such a case, the
   agent should initiate the connection = prior to the start of the
   application. ...


[SS] I assume that you're talking about Registration = connection here. How does the Midcom agent know when to initiate this = connection? Again, going back to the SIP example, the agent can only = initiate the connection on receipt of a SIP INVITE message. It makes = sense to me for apriori registration between the MB & MA, & MA = be ready for connection set-up whenever required. The registration is = refreshed periodically. [/SS]

[SS] Typo in the third line of last para of page 20 - = "... media stream, When used"  [/SS]

Section 7.3 - Middlebox implementing NAPT & = Firewall call flows:

   = |            = ;     = |            = ;          = |            = ;  |
   = |            = ;     |++Permit RTP1 & RTCP1 = |            = ;  |
   = |            = ;     |  sessions External = to|           &nb= sp;  |
   = |            = ;     |  middlebox, namely   = |            = ;  |
   = |            = ;     |  Ma to Ea:Eport1,    = |            = ;  |
   = |            = ;     |  Ma to Ea:Eport1+1   = |            = ;  |
   = |            = ;     |  sessions = ++++++++++>|         &nb= sp;    |
   |      &nb= sp;          |<+Ma to = Ea:Eport1,    = |            = ;  |
   = |            = ;     |  Ma to = Ea:Eport1+1     = |            = ;  |
   = |            = ;     |  sessions OKed = ++++++|           = ;  


[SS] Should this be Ma or is it Pa? 

For certain types of NAPT, you won't be able to = complete the binding & update the NAPT table until you know the = port address of the callee, which is not part of the SDP in INVITE. In = many cases, the SDP of the callee (containing the port) is carried in = the provisional response 180/183, and Early Media follows the = provisional response. The MA should be able to complete the NAPT = binding based on the SDP of the callee in the response message, to = allow early media. [/SS]

9.3. Asynchronous notification to MIDCOM = agents

   Asynchronous notification by the = middlebox to a MIDCOM agent
   can be useful for events such as = Session creation, Session
   termination, MIDCOM protocol failure, = Middlebox function
   failure or any other significant event. = Independently, ICMP
   error codes can also be useful to = notify transport layer
   failures to the agents. ...

[SS] We should perhaps also include the = following:
        - = Exchange state synchronization information (described earlier)
        - = Periodic health check message exchange
        - MB send = logs of unauthorized access & unsolicitated alarms to the MA
[/SS]

Regards,
Sanjoy Sen

------_=_NextPart_001_01C0F80A.FA4967D0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 18 13:46: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 ESMTP id NAA14656 for ; Mon, 18 Jun 2001 13:46:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10192; Mon, 18 Jun 2001 13:43:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10163 for ; Mon, 18 Jun 2001 13:43:58 -0400 (EDT) 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 ESMTP id NAA14580 for ; Mon, 18 Jun 2001 13:43:26 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 5E4898153 for ; Mon, 18 Jun 2001 12:03:05 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id MAA28217 for ; Mon, 18 Jun 2001 12:43:58 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 18 Jun 2001 12:43:58 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12D9D@XCH-NW-01.nw.nos.boeing.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 Mon, 18 Jun 2001, Fleischman, Eric W wrote: > I've now been through the email archives > and I've failed to find a discussion concerning > the strengths and weaknesses of permitting out-of- > path Midcom agents. > > I question the wisdom of specifying out-of-path > Midcom agents because the provision is an > excellent mechanism to be exploited by hackers, > crackers, and DoS attacks. The natural fit of this > provision for these types of exploits is so obvious > that I question why this provision was added > to the framework document. The sparse examples within > the text are noncompelling (e.g., FTP), since one > could easily accomplish the same thing via in-path > agents, and this particular provision of FTP has been > criticized in security circles for some time. I find this puzzling. To my way of thinking, an OOP agent is (or is very close to) a pretty ordinary transparent application layer gateway that's been taught how to talk to a middlebox to fast-path traffic. In In-Path agent is a non-transparent application layer gateway with the same teaching. Are you claiming that a transparent ALG is in some way easier to fool/spoof/hack than a non-transparent one? What am I missing? Andrew P.S. I am of, course, aware that MIDCOM Agent is not actually synonymous with ALG. It just seems to me that most implementations will tend to fall somewhat along these lines. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 18 14:18:57 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 ESMTP id OAA15545 for ; Mon, 18 Jun 2001 14:18:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11469; Mon, 18 Jun 2001 14:18:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11438 for ; Mon, 18 Jun 2001 14:17:58 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15520 for ; Mon, 18 Jun 2001 14:17:21 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA01534 for ; Mon, 18 Jun 2001 11:17:16 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA28357 for ; Mon, 18 Jun 2001 11:17:49 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Mon, 18 Jun 2001 11:17:37 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 11:17:37 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DA5@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Andrew Molitor'" , midcom@ietf.org Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 Date: Mon, 18 Jun 2001 11:17:35 -0700 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 No, I am not making any claims vis-a-vis ALGs. Indeed, my own thinking had not matured to the extent that I identified OOP agents as being transparent ALGs and in-band agents as being non-transparent ALGs. Are you sure that such an equation is complete and accurate? In any case, I am rather concerned about crackers creating attack platforms which resemble ALGs. It is my belief that such devices are inherently more "stealthy" when acting as OOP agents. We can satisfy my concerns by building in protections so that OOP agents are known (e.g., their IP addresses can not be spoofed and we can be guaranteed to be able to accurately identify and authenticate them) and that we have devised provisions to reduce the DoS threat from such agents. I haven't seen any postings which make me think that we have been concerned about DoS attacks yet. Certainly, my earlier posting about the need to make midcom as stateless as possible was partly motivated by DoS concerns. > I find this puzzling. To my way of thinking, an OOP agent >is (or is very close to) a pretty ordinary transparent application >layer gateway that's been taught how to talk to a middlebox to >fast-path traffic. In In-Path agent is a non-transparent application >layer gateway with the same teaching. > Are you claiming that a transparent ALG is in some way >easier to fool/spoof/hack than a non-transparent one? > What am I missing? > Andrew >P.S. I am of, course, aware that MIDCOM Agent is not actually synonymous >with ALG. It just seems to me that most implementations will tend to >fall somewhat along these lines. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 18 14:21: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 ESMTP id OAA15579 for ; Mon, 18 Jun 2001 14:21:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11394; Mon, 18 Jun 2001 14:16:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11324 for ; Mon, 18 Jun 2001 14:16:47 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.211.193.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15501 for ; Mon, 18 Jun 2001 14:16:15 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5ICUDw16441 for ; Mon, 18 Jun 2001 13:30:30 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Mon, 18 Jun 2001 13:29:27 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 13:29:07 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C300B8925@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Andrew Molitor'" , "'Maciocco, Christian'" , "'Scott Brim'" , "'richard.swale@bt.com'" , srisuresh@yahoo.com Cc: "'midcom@ietf.org'" Subject: RE: [midcom] middlebox informs agent? Date: Mon, 18 Jun 2001 13:29:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F7F2.43CAE2D0" 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_001_01C0F7F2.43CAE2D0 Content-Type: text/plain; charset="ISO-8859-1" Folks, I think we all agreed on both methods and that each has potential scalability issues I propose to close that matter off and come back to it when we start looking at the protocol design Cedric -----Original Message----- From: Andrew Molitor [mailto:amolitor@visi.com] Sent: Tuesday, June 12, 2001 6:46 PM To: Aoun, Cedric [QPD:0000:EXCH] Cc: 'Maciocco, Christian'; 'Scott Brim'; 'richard.swale@bt.com'; srisuresh@yahoo.com; 'midcom@ietf.org' Subject: RE: [midcom] middlebox informs agent? On Tue, 12 Jun 2001, Cedric Aoun wrote: > sorry to spam again with that one, but we need to get agreement on that > issue ... > > Christian, > The Middle Box has already a flow based state machines in > which one state consist on a timer that is reset upon reception of a > packet. This is a false assumption. As I have indicated in an earlier note to the midcom list, there are many ways to handle timers up to and including not having them. In some cases, like SIP, the agent need not have any timer state since the endpoints will (may?) provide events which can be used to refresh state. In other cases, the agent may need to maintain internal timers for its own purposes. It is not safe to assume that the agent is maintaining timer state. It is safe to assume that essentially any model of timers you can think up will be desireable to someone. It is not safe to assume ANYTHING about the timer model implemented by a specific middlebox class device. As I indicated in the aforementioned email, I have no clear idea of what the right way to deal with these fact in the to-be-defined MIDCOM protocol is. I eagerly await suggestions. I keep seeing these posts which apparently assume some Platonic Ideal middlebox -- usually subtly different from everyone else's Platonic Ideal of a middlebox. Let me remind us all, one more time, MIDCOM needs to deal with existing middlebox class devices. I am happy to go on all day about one such device, the one I work on. I have described many of its properties as illustrative examples already. I am neither so naive, nor so rude, as to assume that MY device is the canonical middlebox, the only one MIDCOM must deal with. Andrew ------_=_NextPart_001_01C0F7F2.43CAE2D0 Content-Type: text/html; charset="ISO-8859-1" RE: [midcom] middlebox informs agent?

Folks,
I think we all agreed on both methods and that each has potential scalability issues
I propose to close that matter off and come back to it when we start looking at the protocol design
Cedric
-----Original Message-----
From: Andrew Molitor [mailto:amolitor@visi.com]
Sent: Tuesday, June 12, 2001 6:46 PM
To: Aoun, Cedric [QPD:0000:EXCH]
Cc: 'Maciocco, Christian'; 'Scott Brim'; 'richard.swale@bt.com';
srisuresh@yahoo.com; 'midcom@ietf.org'
Subject: RE: [midcom] middlebox informs agent?




On Tue, 12 Jun 2001, Cedric Aoun wrote:

> sorry to spam again with that one, but we need to get agreement on that
> issue ...
>
> Christian,
> The Middle Box has already a flow based state machines in
> which one state consist on a timer that is reset upon reception of a
> packet.

        This is a false assumption. As I have indicated in an
earlier note to the midcom list, there are many ways to handle timers
up to and including not having them.

        In some cases, like SIP, the agent need not have any timer
state since the endpoints will (may?) provide events which can
be used to refresh state. In other cases, the agent may need to
maintain internal timers for its own purposes. It is not safe to
assume that the agent is maintaining timer state.

        It is safe to assume that essentially any model of timers you
can think up will be desireable to someone. It is not safe to assume
ANYTHING about the timer model implemented by a specific middlebox
class device. As I indicated in the aforementioned email, I have
no clear idea of what the right way to deal with these fact in the
to-be-defined MIDCOM protocol is. I eagerly await suggestions.

        I keep seeing these posts which apparently assume some
Platonic Ideal middlebox -- usually subtly different from everyone
else's Platonic Ideal of a middlebox. Let me remind us all, one more
time, MIDCOM needs to deal with existing middlebox class devices. I
am happy to go on all day about one such device, the one I work on.
I have described many of its properties as illustrative examples
already. I am neither so naive, nor so rude, as to assume that MY
device is the canonical middlebox, the only one MIDCOM must deal
with.

                Andrew

------_=_NextPart_001_01C0F7F2.43CAE2D0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 18 14:55: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 ESMTP id OAA16650 for ; Mon, 18 Jun 2001 14:55:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12876; Mon, 18 Jun 2001 14:53:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12845 for ; Mon, 18 Jun 2001 14:53:19 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16625 for ; Mon, 18 Jun 2001 14:52:46 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA14020 for ; Mon, 18 Jun 2001 13:53:29 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA11539 for ; Mon, 18 Jun 2001 13:53:15 -0500 (CDT) Received: from xch-pssbh-01.nw.nos.boeing.com by stl-hub-01.boeing.com with ESMTP; Mon, 18 Jun 2001 13:53:07 -0500 Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 11:53:06 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DA6@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Cedric Aoun'" , "'Andrew Molitor'" , "'Maciocco, Christian'" , "'Scott Brim'" , "'richard.swale@bt.com'" , srisuresh@yahoo.com Cc: "'midcom@ietf.org'" Subject: RE: [midcom] middlebox informs agent? Date: Mon, 18 Jun 2001 11:53:04 -0700 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 This excellent posting has touched on several ideas which I would appreciate us discussing more fully. From: Andrew Molitor [mailto:amolitor@visi.com] > In some cases, like SIP, the agent need not have any timer > state since the endpoints will (may?) provide events which can > be used to refresh state. In other cases, the agent may need to > maintain internal timers for its own purposes. It is not safe to > assume that the agent is maintaining timer state. >It is safe to assume that essentially any model of timers you > can think up will be desirable to someone. It is not safe to assume > ANYTHING about the timer model implemented by a specific middlebox > class device. As I indicated in the aforementioned email, I have > no clear idea of what the right way to deal with these fact in the > to-be-defined MIDCOM protocol is. I eagerly await suggestions. This is an excellent point. I think that we can agree that because there are many implementations, there are potentially different approaches to timers in existing products. However, to the degree to which the midcom protocol addresses timer issues, to that extent we theoretically have the option to create standardization of approaches which impact timers. Towards that end, I would like to propose that we explicitly seek to make no assumption as to a midcom agent's use of timers, by explicitly making subsequent use of the midcom teardown function be optional. By so doing, however, we would explicitly be requiring that the middlebox itself keeps timers (as the text already says) so that it could automatically close down any "hole" even if the agent "goes away" for unforeseen reasons. I think that most of us will readily agree with this tenet because it makes the protocol more able to weather unforeseen events. Question to Cedric: could you agree with my above two paragraphs? If not, how would you modify them? > I keep seeing these posts which apparently assume some > Platonic Ideal middlebox -- usually subtly different from everyone > else's Platonic Ideal of a middlebox. Let me remind us all, one more > time, MIDCOM needs to deal with existing middlebox class devices. I > am happy to go on all day about one such device, the one I work on. > I have described many of its properties as illustrative examples > already. I am neither so naive, nor so rude, as to assume that MY > device is the canonical middlebox, the only one MIDCOM must deal > with. This is a bit of a problem since unless we are talking about your implementation, then we're talking about someone else's implementation. If they object to us using your implementation as our standard or if you object to our using their implementation as our standard, then we can't really talk about specific implementations after all. That is, the only way we can talk about all implementations is to add in abstraction, thereby perhaps creating a "Platonic Ideal of a middlebox". I believe that this is a almost unavoidable. On the other hand, any implementation can rightly object to assumptions contained within this "Platonic Ideal" which war against their particular implementation. An example is my second paragraph above. However, unless all implementations are harmonious in the points touched by the midcom protocol, the unfortunate reality will be that any attempt for standardization will be more challenging for some implementations than for others. Therefore, I HOPE that we can resolve this problem by having very good reasons for doing whatever we're doing, which is why these types of discussions are so important. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 18 19:37:44 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 ESMTP id TAA24227 for ; Mon, 18 Jun 2001 19:37:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21353; Mon, 18 Jun 2001 19:34:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21324 for ; Mon, 18 Jun 2001 19:34:50 -0400 (EDT) Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24168 for ; Mon, 18 Jun 2001 19:34:18 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id SAA09017 for ; Mon, 18 Jun 2001 18:35:48 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Mon, 18 Jun 2001 18:33:37 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 16:33:32 -0700 Message-ID: From: "Russell Daigle" To: "'midcom@ietf.org'" Date: Mon, 18 Jun 2001 16:33:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F84F.1232FC50" Subject: [midcom] Framework draft -01 comments 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_001_01C0F84F.1232FC50 Content-Type: text/plain; charset="iso-8859-1" Here are the main comments I have on the arch/framework document. Some of these comments are not architectural, but are more protocol issues.... but I've included them anyways since they may be helpful. 1) Section 2.8: "MIDCOM agents possess a combination of application awareness and knowledge of the middlebox function." It shouldn't be necessary that the agent knows the middlebox function. While there are situations where it is advantageous (ie, when the agent itself will perform the NAT manipulations of the stream), it definitely should not be a requirement. I'd like to see some generic APIs that can abstract this away; for example the midbox may just want to know about dynamic ports associated with the conversation. I presume this was intended, but it's not clear from the text, and it is important enough to be mentioned explicitly. In general, this helps achieve extensibility in what I expect will be a common situation where the midbox wants to maintain the "middlebox function" without explicit knowledge of lots of applications. 2) Section 5.2, Page 12, point #3: "Note the middlebox will not subject the datagram to any of the middlebox services this time around." This statement indicates that when the out-of-path agent forwards the processed packet back to the middlebox, the middlebox won't pass this packet through any more services. This is completely untrue: there are situations where additional services are required after the packet has been processed by the middlebox. This has many implications.... but the salient point here is that the architecture/protocol must not preclude this from happening. This should be mentioned explicitly. One implication is that such situations that have this requirement will not be able to use in-path agents since the packet must be forwarded back to the middlebox. I know the remaining implications are protocol-related, so don't flame me. :) Just ignore them if you want. I thought they were interesting enough to note.... and I'll be mentioning them again later if the protocol-spec doesn't have provisions for them. Another implication is that there needs to be some sort of mechanism where an out-of-path agent can be configured to return [on a per-connection basis?] packets to the middlebox for further processing. Presumably, this would be upon establishing the midcom protocol between a midbox and agent. (This statement is also related to section 9.4: "The agents should be capable of returning the processed traffic to the middlebox point of origin..."; this requirement should be configurable.) Then there are strict ordering requirements between messages exchanged via the midcom protocol and packets forwarded back to the midbox from the agent. This may be particularly cumbersome if the midcom protocol messages and actual user data-packets are sent via distinct virtual channels (ie, different L4/7 connections). This point may argue for having the user data-packets tunnelled in the same connection as midcom protocol message are sent via. There are also additional reasons for tunnelling of user data-packets which will be described later. In addition, there should be some sort of "cookie" (ie, 32-bit entity) that the midbox can associate with each packet forwarded to an agent. When the agent forwards this packet back to the midbox, the cookie should be copied back. One important use of this cookie would be to tell the midbox where the processing for this packet needs to resume. Note that this requirement also seems to imply the need for tunnelling of user data-packets between midbox and agent. 3) Section 9.1, 2nd para: "A MIDCOM agent ought to be able to have a single MIDCOM connection with a middlebox...". In addition, a MIDCOM agent must be able to support multiple connections from the same middlebox. The perspective from which I'm looking at this is purely a matter of scale. For large scale midboxes with lots of processors, I would like it to be possible for each processor to be able to maintain their own connection(s) to the agent such that packets can be sent/received from/to a processor directly without having to hop through another one first. In this scenario, the middlebox L3 end-point of each of these connections will be the same; however the L4 end-point (ie, TCP/UDP port number) would be different. In addition, I highly recommend there be some sort of session-ID which is included in every packet (control and data); there could be a mapping of session-id to processor for large scale boxes ..... again, this enforces the requirement for tunnelling user-data-packets. 4) Redundancy and failure issues. There probably needs to be more discussion on this topic. The first things that pop into my mind are: (a) The need to be able to determine when the peer has gone down. One of the traditional techniques used for this is some sort of "heartbeat" protocol. (b) User-data packets being forwarded between midbox and agent should be dropped in network if the destined peer is down/unreachable. Tunnelling would accomplish this since the midbox/agent peers are the src/dest of the packet. The concern here is that when the data-stream is modified (such as with NAT), some problems can be encountered if the two user-endpoints have some data modified appropriately and some not (due to failure); it would be preferred that the latter packets not reach the end-node since one possible outcome of this sort of scenario is data-corruption. One of the problems that arise in this situation is that seqno-delta operations performed by NAT may not be done upon all packets of a conversation. Of course, one could claim this is a more general problem that transcends the midbox architecture (ie, any intermediate networking node that performs such stream modifications opens this vulnerability), which is true to some extent; however, I think that if this problem can be easily avoided by the midcom arch it should be. (c) Failover support. I imagine this may be considered to be out of scope since this is difficult (and potentially computationally expensive) for this class of problem. 5) This is more of a protocol than architectural issue... have some mechanism in the protocol where a midbox can tell the agent to drop the packet after fully processing it. This can lead to performance gains in situations where the user data-stream doesn't need to be modified at all, but rather watched for dynamic connection information. The midbox could simply duplicate the packet, sending one to the agent and one on it's normal way. Yes, this can lead to some race-conditions where the dynamic connection is attempted to be opened before the agent has the chance to tell the midbox about it. Assuming a tunnelling mechanism is used, a simple way to implement this would be to have a bit indicating what to do with the packet after the agent processes it. (There can be another bit indicating whether the agent must forward the packet back to the midbox after processing, or if the agent to route the packet onto the destination however it sees fit. The power of tunnelling..... have I convinced you yet? :) -Russ Daigle ------_=_NextPart_001_01C0F84F.1232FC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Framework draft -01 comments

Here are the main comments I have on = the arch/framework document. 

Some of these comments are not = architectural,  but are more protocol issues....  but I've = included them anyways since they may be helpful.


1) Section 2.8:  "MIDCOM = agents possess a combination of application awareness and knowledge of = the middlebox function."  It shouldn't be necessary that the = agent knows the middlebox function.  While there are situations = where it is advantageous (ie,  when the agent itself will perform = the NAT manipulations of the stream),  it definitely should not be = a requirement.   I'd like to see some generic APIs that can = abstract this away;  for example the midbox may just want to know = about dynamic ports associated with the conversation.   I = presume this was intended,  but it's not clear from the = text,  and it is important enough to be mentioned = explicitly.   In general,  this helps achieve = extensibility in what I expect will be a common situation where the = midbox wants to maintain the "middlebox function" without = explicit knowledge of lots of applications.


2) Section 5.2, Page 12, point = #3:  "Note the middlebox will not subject the datagram to any = of the middlebox services this time around."  This statement = indicates that when the out-of-path agent forwards the processed packet = back to the middlebox,  the middlebox won't pass this packet = through any more services.   This is completely untrue:  = there are situations where additional services are required after the = packet has been processed by the middlebox.  This has many = implications....  but the salient point here is that the = architecture/protocol must not preclude this from happening.  This = should be mentioned explicitly.

One implication is that such = situations that have this requirement will not be able to use in-path = agents since the packet must be forwarded back to the = middlebox.

I know the remaining implications are = protocol-related,  so don't flame me.  :)  Just ignore = them if you want.  I thought they were interesting enough to = note.... and I'll be mentioning them again later if the protocol-spec = doesn't have provisions for them.

Another implication is that there = needs to be some sort of mechanism where an out-of-path agent can be = configured to return [on a per-connection basis?] packets to the = middlebox for further processing.  Presumably,  this would be = upon establishing the midcom protocol between a midbox and agent.  = (This statement is also related to section 9.4:  "The agents = should be capable of returning the processed traffic to the middlebox = point of origin...";  this requirement should be = configurable.)

Then there are strict ordering = requirements between messages exchanged via the midcom protocol and = packets forwarded back to the midbox from the agent.  This may be = particularly cumbersome if the midcom protocol messages and actual user = data-packets are sent via distinct virtual channels (ie, different L4/7 = connections).  This point may argue for having the user = data-packets tunnelled in the same connection as midcom protocol = message are sent via.  There are also  additional reasons for = tunnelling of user data-packets which will be described = later.

In addition, there should be some sort = of "cookie" (ie, 32-bit entity) that the midbox can associate = with each packet forwarded to an agent.  When the agent forwards = this packet back to the midbox,  the cookie should be copied = back.  One important use of this cookie would be to tell the = midbox where the processing for this packet needs to resume.  Note = that this requirement also seems to imply the need for tunnelling of = user data-packets between midbox and agent.


3) Section 9.1, 2nd para:  = "A MIDCOM agent ought to be able to have a single MIDCOM = connection with a middlebox...".   In addition,  a = MIDCOM agent must be able to support multiple connections from the same = middlebox.    The perspective from which I'm looking at = this is purely a matter of scale.  For large scale midboxes with = lots of processors,  I would like it to be possible for each = processor to be able to maintain their own connection(s) to the agent = such that packets can be sent/received from/to a processor directly = without having to hop through another one first.  In this = scenario, the middlebox L3 end-point of each of these connections will = be the same; however the L4 end-point (ie, TCP/UDP port number) would = be different.  In addition,  I highly recommend there be some = sort of session-ID which is included in every packet (control and = data);  there could be a mapping of session-id to processor for = large scale boxes .....  again, this enforces the requirement for = tunnelling user-data-packets.


4) Redundancy and failure = issues.   There probably needs to be more discussion on this = topic.  The first things that pop into my mind are:

(a) The need to be able to determine = when the peer has gone down.  One of the traditional techniques = used for this is some sort of "heartbeat" = protocol.

(b) User-data packets being forwarded = between midbox and agent should be dropped in network if the destined = peer is down/unreachable.  Tunnelling would accomplish this since = the midbox/agent peers are the src/dest of the packet.  The = concern here is that when the data-stream is modified (such as with = NAT),  some problems can be encountered if the two user-endpoints = have some data modified appropriately and some not (due to = failure);  it would be preferred that the latter packets not reach = the end-node since one possible outcome of this sort of scenario is = data-corruption.  One of the problems that arise in this situation = is that seqno-delta operations performed by NAT may not be done upon = all packets of a conversation.  Of course,  one could claim = this is a more general problem that transcends the midbox architecture = (ie, any intermediate networking node that performs such stream = modifications opens this vulnerability),  which is true to some = extent;  however,  I think that if this problem can be easily = avoided by the midcom arch it should be.

(c) Failover support.  I imagine = this may be considered to be out of scope since this is difficult (and = potentially computationally expensive) for this class of = problem.


5) This is more of a protocol than = architectural issue...  have some mechanism in the protocol where = a midbox can tell the agent to drop the packet after fully processing = it.  This can lead to performance gains in situations where the = user data-stream doesn't need to be modified at all,  but rather = watched for dynamic connection information.  The midbox could = simply duplicate the packet, sending one to the agent and one on it's = normal way. Yes,  this can lead to some race-conditions where the = dynamic connection is attempted to be opened before the agent has the = chance to tell the midbox about it.   Assuming a tunnelling = mechanism is used, a simple way to implement this would be to have a = bit indicating what to do with the packet after the agent processes = it.   (There can be another bit indicating whether the agent = must forward the packet back to the midbox after processing,  or = if the agent to route the packet onto the destination however it sees = fit.   The power of tunnelling..... have I convinced you yet? = :)


-Russ Daigle

------_=_NextPart_001_01C0F84F.1232FC50-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 13:03: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 NAA27145 for ; Tue, 19 Jun 2001 13:03:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01103; Tue, 19 Jun 2001 12:57:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01069 for ; Tue, 19 Jun 2001 12:57:47 -0400 (EDT) Received: from web13803.mail.yahoo.com (web13803.mail.yahoo.com [216.136.175.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26825 for ; Tue, 19 Jun 2001 12:57:11 -0400 (EDT) Message-ID: <20010619165744.4631.qmail@web13803.mail.yahoo.com> Received: from [65.12.33.187] by web13803.mail.yahoo.com; Tue, 19 Jun 2001 09:57:44 PDT Date: Tue, 19 Jun 2001 09:57:44 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 To: "Fleischman, Eric W" , "'Andrew Molitor'" , midcom@ietf.org In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DA5@XCH-NW-01.nw.nos.boeing.com> 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 --- "Fleischman, Eric W" wrote: > No, I am not making any claims vis-a-vis ALGs. Indeed, my own thinking > had not matured to the extent that I identified OOP agents as being > transparent ALGs and in-band agents as being non-transparent > ALGs. Are you sure that such an equation is complete and accurate? > In-Path agents (ex: Proxies) are visible to the end-hosts. So, in-path agents are not transparent. OOP agent are not visible to end-hosts. So, an OOP agent is transparent. > In any case, I am rather concerned about crackers creating attack platforms > which resemble ALGs. It is my belief that such devices are inherently > more "stealthy" when acting as OOP agents. > > We can satisfy my concerns by building in protections so that OOP agents > are known (e.g., their IP addresses can not be spoofed and we can be > guaranteed to be able to accurately identify and authenticate them) and > that we have devised provisions to reduce the DoS threat from such > agents. I haven't seen any postings which make me think that we have been > concerned about DoS attacks yet. Certainly, my earlier posting about > the need to make midcom as stateless as possible was partly motivated > by DoS concerns. > We could certainly mention security concerns in the context of OOP agents. But, as Andrew points out, any intermediate agent (transparent or non-transparent) could fool/spoof/hack, if it chose to do so. > > I find this puzzling. To my way of thinking, an OOP agent > >is (or is very close to) a pretty ordinary transparent application > >layer gateway that's been taught how to talk to a middlebox to > >fast-path traffic. In In-Path agent is a non-transparent application > >layer gateway with the same teaching. > > > Are you claiming that a transparent ALG is in some way > >easier to fool/spoof/hack than a non-transparent one? > > > What am I missing? > > > Andrew > > >P.S. I am of, course, aware that MIDCOM Agent is not actually synonymous > >with ALG. It just seems to me that most implementations will tend to > >fall somewhat along these lines. ===== __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 13:43:44 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 NAA28520 for ; Tue, 19 Jun 2001 13:43:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02739; Tue, 19 Jun 2001 13:43:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02713 for ; Tue, 19 Jun 2001 13:43:20 -0400 (EDT) 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 NAA28481 for ; Tue, 19 Jun 2001 13:42:44 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5JHgtN08064; Tue, 19 Jun 2001 10:42:55 -0700 (PDT) Received: from spandex (rtp-vpn-124.cisco.com [10.82.192.124]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKC04447; Tue, 19 Jun 2001 10:42:44 -0700 (PDT) Message-ID: <00a001c0f8e7$5fbc8ca0$d45904d1@cisco.com> From: "Melinda Shore" To: "Pyda Srisuresh" , "Fleischman, Eric W" , "'Andrew Molitor'" , References: <20010619165744.4631.qmail@web13803.mail.yahoo.com> Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 Date: Tue, 19 Jun 2001 13:43:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > OOP agent are not visible to end-hosts. So, an OOP agent is transparent. I wouldn't agree that one follows from the other. If the out-of-path agent effects a change in the behavior of the data/application/what-have-you, it's not transparent. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 13:55:28 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 NAA28851 for ; Tue, 19 Jun 2001 13:55:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02969; Tue, 19 Jun 2001 13:53:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02941 for ; Tue, 19 Jun 2001 13:53:22 -0400 (EDT) Received: from web13804.mail.yahoo.com (web13804.mail.yahoo.com [216.136.175.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28784 for ; Tue, 19 Jun 2001 13:52:46 -0400 (EDT) Message-ID: <20010619175320.44150.qmail@web13804.mail.yahoo.com> Received: from [65.12.33.187] by web13804.mail.yahoo.com; Tue, 19 Jun 2001 10:53:20 PDT Date: Tue, 19 Jun 2001 10:53:20 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 To: Melinda Shore , "Fleischman, Eric W" , "'Andrew Molitor'" , midcom@ietf.org In-Reply-To: <00a001c0f8e7$5fbc8ca0$d45904d1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Melinda Shore wrote: > > OOP agent are not visible to end-hosts. So, an OOP agent is transparent. > > I wouldn't agree that one follows from the other. > If the out-of-path agent effects a change in the behavior > of the data/application/what-have-you, it's not transparent. > Sure, I meant that as being implied. > Melinda > > cheers, suresh __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 14:00: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 OAA28976 for ; Tue, 19 Jun 2001 14:00:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03122; Tue, 19 Jun 2001 13:57:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03094 for ; Tue, 19 Jun 2001 13:57:11 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28883 for ; Tue, 19 Jun 2001 13:56:33 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5JHuNB16751 for ; Tue, 19 Jun 2001 13:56:23 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5JHuL916718 for ; Tue, 19 Jun 2001 13:56:21 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8E9.4307DD92" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 Date: Tue, 19 Jun 2001 11:57:10 -0600 Message-ID: Thread-Topic: [midcom] Out-of-Path Midcom Agents in framework-02 Thread-Index: AcD4527O1i0SPIXFRDa8b56HjVQ/sgAAL3EQ From: "Zmolek, Andrew (Andrew)" To: "Melinda Shore" , "Pyda Srisuresh" , "Fleischman, Eric W" , "Andrew Molitor" , 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 multi-part message in MIME format. ------_=_NextPart_001_01C0F8E9.4307DD92 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It seems that we've been debating the meaning of transparency for some time now. Perhaps we are talking about different shades of transparency, and if that really does matter than we need to elaborate. - Transparency at an application layer so that client and server both have a rational conversation is probably what we're aiming for when we talk about OOP agent transparency. Some OOP agents still manage to mangle things here, but the aim is still transparency. - Transparency at the transport layer is something else. Many OOP agents will have to interact with the underlying transport infrastructure to deal with packet forwarding, route information, address and port assignment details, etc. So transparency is a harder sell here. Is it possible we can find enough middle ground in this decomposition of the word "transparent" that we can move on? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, June 19, 2001 11:44 AM To: Pyda Srisuresh; Fleischman, Eric W; 'Andrew Molitor'; midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 > OOP agent are not visible to end-hosts. So, an OOP agent is transparent. =20 I wouldn't agree that one follows from the other. If the out-of-path agent effects a change in the behavior of the data/application/what-have-you, it's not transparent. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0F8E9.4307DD92 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Out-of-Path Midcom Agents in framework-02

It seems that we've been debating the meaning of = transparency for some time now. Perhaps we are talking about different = shades of transparency, and if that really does matter than we need to = elaborate.

- Transparency at an application layer so that client = and server both have a rational conversation is probably what we're = aiming for when we talk about OOP agent transparency. Some OOP agents = still manage to mangle things here, but the aim is still = transparency.

- Transparency at the transport layer is something = else. Many OOP agents will have to interact with the underlying = transport infrastructure to deal with packet forwarding, route = information, address and port assignment details, etc. So transparency = is a harder sell here.

Is it possible we can find enough middle ground in = this decomposition of the word "transparent" that we can move = on?

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Tuesday, June 19, 2001 11:44 AM
To: Pyda Srisuresh; Fleischman, Eric W; 'Andrew = Molitor';
midcom@ietf.org
Subject: Re: [midcom] Out-of-Path Midcom Agents in = framework-02


> OOP agent are not visible to end-hosts. So, an = OOP agent is transparent.  

I wouldn't agree that one follows from the = other.
If the out-of-path agent effects a change in the = behavior
of the data/application/what-have-you, it's not = transparent.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/= mailman/listinfo/midcom

------_=_NextPart_001_01C0F8E9.4307DD92-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 14:11: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 OAA29349 for ; Tue, 19 Jun 2001 14:11:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02409; Tue, 19 Jun 2001 13:30:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02378 for ; Tue, 19 Jun 2001 13:30:29 -0400 (EDT) Received: from web13806.mail.yahoo.com (web13806.mail.yahoo.com [216.136.175.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28067 for ; Tue, 19 Jun 2001 13:29:53 -0400 (EDT) Message-ID: <20010619173026.16647.qmail@web13806.mail.yahoo.com> Received: from [65.12.33.187] by web13806.mail.yahoo.com; Tue, 19 Jun 2001 10:30:26 PDT Date: Tue, 19 Jun 2001 10:30:26 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Framework draft -01 comments To: Russell Daigle , "'midcom@ietf.org'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Russell, Would appreciate, in the future, if you sent your comments on the latest rev. of the draft. It is likely the previous rev went through multiple changes. Thanks. My comments below. Also, I didnot respond to suggestions on specific protocol mechanisms and implementation issues. We could revisit these later at an appropriate time. Hope you understand. cheers, suresh --- Russell Daigle wrote: > Here are the main comments I have on the arch/framework document. > > Some of these comments are not architectural, but are more protocol > issues.... but I've included them anyways since they may be helpful. > > > 1) Section 2.8: "MIDCOM agents possess a combination of application > awareness and knowledge of the middlebox function." It shouldn't be > necessary that the agent knows the middlebox function. While there are > situations where it is advantageous (ie, when the agent itself will perform > the NAT manipulations of the stream), it definitely should not be a > requirement. I'd like to see some generic APIs that can abstract this > away; for example the midbox may just want to know about dynamic ports > associated with the conversation. I presume this was intended, but it's > not clear from the text, and it is important enough to be mentioned > explicitly. In general, this helps achieve extensibility in what I expect > will be a common situation where the midbox wants to maintain the "middlebox > function" without explicit knowledge of lots of applications. > You may be able to generate some generic APIs once the protocol is designed. But, that cannot be mandated at the framework time. Not all middleboxes are alike. An agent designed for a specific middlebox function or a specific application cannot be assumed to magically work with any middlebox function and/or application. > 2) Section 5.2, Page 12, point #3: "Note the middlebox will not subject the > datagram to any of the middlebox services this time around." This statement > indicates that when the out-of-path agent forwards the processed packet back > to the middlebox, the middlebox won't pass this packet through any more > services. This is completely untrue: there are situations where > additional services are required after the packet has been processed by the > middlebox. This has many implications.... but the salient point here is > that the architecture/protocol must not preclude this from happening. This > should be mentioned explicitly. > > One implication is that such situations that have this requirement will not > be able to use in-path agents since the packet must be forwarded back to the > middlebox. > The intent is for the OOP agent to have the same priveleges to application datagrams as that of an In-Path agent, in order for the OOP agent to behave exactly like the in-path agent. The only difference would be a requirement for diversion function on the middlebox to support OOP agents. Otherwise, both agents have identical MIDCOM sessions. Anything outside of this, I believe, would be out of bounds for this work group. > I know the remaining implications are protocol-related, so don't flame me. > :) Just ignore them if you want. I thought they were interesting enough to > note.... and I'll be mentioning them again later if the protocol-spec > doesn't have provisions for them. > I am going to have to defer on the protocol related comments. <... stuff deleted> > > Then there are strict ordering requirements between messages exchanged via > the midcom protocol and packets forwarded back to the midbox from the agent. Yes. That is a requirement in general on all intermediate devices. > This may be particularly cumbersome if the midcom protocol messages and > actual user data-packets are sent via distinct virtual channels (ie, > different L4/7 connections). This point may argue for having the user > data-packets tunnelled in the same connection as midcom protocol message are > sent via. There are also additional reasons for tunnelling of user > data-packets which will be described later. > Not necessarily. Besides, the exact diversion function implemenation mechanism is considered proprietaty to the middlebox and is out of bounds for the FW document. <... Comments on specific protocol mechanisms & implementations deleted> > -Russ Daigle > Thanks. regards, suresh __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 14:17: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 OAA29524 for ; Tue, 19 Jun 2001 14:17:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03881; Tue, 19 Jun 2001 14:14:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03854 for ; Tue, 19 Jun 2001 14:14:26 -0400 (EDT) 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 OAA29419 for ; Tue, 19 Jun 2001 14:13:49 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5JICHH20062 for ; Tue, 19 Jun 2001 11:12:17 -0700 (PDT) Received: from spandex (rtp-vpn-124.cisco.com [10.82.192.124]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKC06120; Tue, 19 Jun 2001 11:13:51 -0700 (PDT) Message-ID: <00f701c0f8eb$b83ecba0$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Tue, 19 Jun 2001 14:14:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Straw poll - out-of-path midcom agents 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 We've been going around and around on out-of-path agents since the first draft of the document and it's my sense that we're failing to make progress on it. I'd like to take a straw poll to see how much support there is for including support for diversion to out-of-path agents. Please indicate to the mailing list whether or not you'd like us to include consideration of out-of-path agents. Be prepared to defend your position :-). Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 14:46: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 OAA00164 for ; Tue, 19 Jun 2001 14:46:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04832; Tue, 19 Jun 2001 14:44:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04806 for ; Tue, 19 Jun 2001 14:44:17 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00108 for ; Tue, 19 Jun 2001 14:43:40 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA12711 for ; Tue, 19 Jun 2001 13:44:24 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA14948 for ; Tue, 19 Jun 2001 13:44:11 -0500 (CDT) Received: from xch-pssbh-01.nw.nos.boeing.com by stl-hub-01.boeing.com with ESMTP; Tue, 19 Jun 2001 13:44:02 -0500 Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 11:44:01 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DB2@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Straw poll - out-of-path midcom agents Date: Tue, 19 Jun 2001 11:43:54 -0700 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 Melinda, Since you requested that we reply to the whole list, my vote is that we NOT consider OOP agents. My reasons are: 1) I do not understand why advocates for OOP agents desire them: what scenarios do OOP agents enable? What are they trying to do that they can not do with in-path agents? Are those scenarios "safe" or do they violate "due diligence"? Does this undercut the very nature of the protection currently provided by firewalls? 2) I fear this capability will be easily abused by hackers/ crackers. The clandestine nature of OOP agents make them a preferential attack base when compared with proxies, which are much more publicly known and inspectable. 3) The WG has adopted a definition of "firewall" as being a packet filters. That's fine, but the standard definition I'm used to includes the combination of both packet filters and proxies. Thus, we as a corporation are oriented to be disposed to extend our propagation of trust to include proxies -- in band agents. However, I know of no co-worker who would similarly trust OOP agents, nor have I become clever enough to understand how we could do so or what that would mean, which is why I started out asking the questions in bullet 1 above. My bottom line is that we must not undermine the function the middleboxes are performing if the midcom protocol is to be usable. I am particularly concerned about keeping firewalls secure. --Eric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, June 19, 2001 11:15 AM To: midcom@ietf.org Subject: [midcom] Straw poll - out-of-path midcom agents We've been going around and around on out-of-path agents since the first draft of the document and it's my sense that we're failing to make progress on it. I'd like to take a straw poll to see how much support there is for including support for diversion to out-of-path agents. Please indicate to the mailing list whether or not you'd like us to include consideration of out-of-path agents. Be prepared to defend your position :-). 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 Tue Jun 19 14:57: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 OAA00435 for ; Tue, 19 Jun 2001 14:57:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05118; Tue, 19 Jun 2001 14:56:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05089 for ; Tue, 19 Jun 2001 14:56:22 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00420 for ; Tue, 19 Jun 2001 14:55:45 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5JIttx00585; Tue, 19 Jun 2001 11:55:55 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-7.cisco.com [10.21.96.7]) by airborne.cisco.com (Mirapoint) with ESMTP id ADV17345; Tue, 19 Jun 2001 11:55:47 -0700 (PDT) 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: <15151.41008.271000.711593@gargle.gargle.HOWL> Date: Tue, 19 Jun 2001 14:55:44 -0400 To: "Melinda Shore" Cc: Subject: Re: [midcom] Straw poll - out-of-path midcom agents In-Reply-To: <00f701c0f8eb$b83ecba0$d45904d1@cisco.com> References: <00f701c0f8eb$b83ecba0$d45904d1@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 19 Jun 2001 at 14:14 -0400, Melinda Shore apparently wrote: > We've been going around and around on out-of-path agents > since the first draft of the document and it's my sense > that we're failing to make progress on it. I'd like to > take a straw poll to see how much support there is for > including support for diversion to out-of-path agents. > Please indicate to the mailing list whether or not you'd > like us to include consideration of out-of-path agents. > Be prepared to defend your position :-). I think it's okay to have it in the framework. However, I'm in favor of leaving it out now because it's something we can add on easily in the future. I don't think the possibility of OOP agents has any fundamental implications for the midcom protocol. If it didn't confuse and distract people we could leave it in. Why might we want it? We don't know yet everything we're going to want to communicate in the midcom protocol. We don't know what processing rules we're going to want to be able to pass down, besides "make a pinhole for address X port Y". Perhaps a general purpose, open-ended capability will be too painful to implement. Perhaps 90% of the applications will only need a lean mean simple protocol. In that case, it would be nice to have left room for an agent to say "look, I can't explain what I want, but when you see these packets just give them to me and I'll deal with them". But we could do that later. OPES, if they get chartered at all, are describing a class of OOPA. Perhaps, when we uncover a specific need for an OOPA, their protocol might (be extensible to) cover the specific need. We may never get to the point of doing anything about OOPAs in midcom or its children. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 15:12: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 PAA00984 for ; Tue, 19 Jun 2001 15:12:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05756; Tue, 19 Jun 2001 15:11:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05728 for ; Tue, 19 Jun 2001 15:11:01 -0400 (EDT) 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 PAA00853 for ; Tue, 19 Jun 2001 15:10:24 -0400 (EDT) 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 MAA05694; Tue, 19 Jun 2001 12:10:19 -0700 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA18618; Tue, 19 Jun 2001 12:10:25 -0700 Message-ID: <3B2FA10C.1364B969@hursley.ibm.com> Date: Tue, 19 Jun 2001 13:59:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Zmolek, Andrew (Andrew)" CC: Melinda Shore , Pyda Srisuresh , "Fleischman, Eric W" , Andrew Molitor , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 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 I think the word "transparent" has too many interpretations and too much history of abuse (as in "transparent proxy") to be a useful word in this context. I think we should simply not use the words "transparent" or "transparency" at all. Brian > "Zmolek, Andrew (Andrew)" wrote: > > It seems that we've been debating the meaning of transparency for some time now. Perhaps we are talking about different shades > of transparency, and if that really does matter than we need to elaborate. > > - Transparency at an application layer so that client and server both have a rational conversation is probably what we're > aiming for when we talk about OOP agent transparency. Some OOP agents still manage to mangle things here, but the aim is still > transparency. > > - Transparency at the transport layer is something else. Many OOP agents will have to interact with the underlying transport > infrastructure to deal with packet forwarding, route information, address and port assignment details, etc. So transparency is > a harder sell here. > > Is it possible we can find enough middle ground in this decomposition of the word "transparent" that we can move on? > > --Andy Zmolek > Technology & Standards Engineer > CTO Standards > Avaya Inc. > > zmolek@avaya.com > +1 720 444 4001 > > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, June 19, 2001 11:44 AM > To: Pyda Srisuresh; Fleischman, Eric W; 'Andrew Molitor'; > midcom@ietf.org > Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 > > > OOP agent are not visible to end-hosts. So, an OOP agent is transparent. > > I wouldn't agree that one follows from the other. > If the out-of-path agent effects a change in the behavior > of the data/application/what-have-you, it's not transparent. > > 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 Tue Jun 19 15:23: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 PAA01412 for ; Tue, 19 Jun 2001 15:23:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06241; Tue, 19 Jun 2001 15:22:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06206 for ; Tue, 19 Jun 2001 15:22:33 -0400 (EDT) Received: from web14308.mail.yahoo.com (web14308.mail.yahoo.com [216.136.173.156]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01386 for ; Tue, 19 Jun 2001 15:21:55 -0400 (EDT) Message-ID: <20010619192229.8801.qmail@web14308.mail.yahoo.com> Received: from [207.164.4.56] by web14308.mail.yahoo.com; Tue, 19 Jun 2001 15:22:29 EDT Date: Tue, 19 Jun 2001 15:22:29 -0400 (EDT) From: Abdallah Rayhan Subject: Re: [midcom] Straw poll - out-of-path midcom agents To: midcom@ietf.org In-Reply-To: <00f701c0f8eb$b83ecba0$d45904d1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Melinda, I am in favor of OOP. The reason is that it introduces the concept of open middlebox architecture. If I have a middlebox which carries out function x to perform content filtering for a class of applications, then the OOP would give me the ability to contract whatever vendor I want to provide this service for me without having to throw my current box. Later I may decide to go with another vendor who provides more scalable OOP inspection service. I should be able to do this seamlessly since there is an open interface for OOP-middlebox interaction. Focusing on VoIP type of applications for MIDCOM, should not distract us from providing the proper mechanisms to make the framework extensible to other types of applications. I believe that several security and non-security applications can make use of this framework. While there are security concerns about how OOP should be integrated within the architecture or deployed, that does not justify saying that we dont need it. my 2 cents regards, Abdallah --- Melinda Shore wrote: > We've been going around and around on out-of-path agents > since the first draft of the document and it's my sense > that we're failing to make progress on it. I'd like to > take a straw poll to see how much support there is for > including support for diversion to out-of-path agents. > Please indicate to the mailing list whether or not you'd > like us to include consideration of out-of-path agents. > Be prepared to defend your position :-). > > Melinda > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 15:24: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 PAA01442 for ; Tue, 19 Jun 2001 15:24:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06283; Tue, 19 Jun 2001 15:23:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06253 for ; Tue, 19 Jun 2001 15:23:00 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01390 for ; Tue, 19 Jun 2001 15:22:22 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Jun 2001 12:09:26 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 19 Jun 2001 12:09:09 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 19 Jun 2001 12:09:07 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Jun 2001 12:07:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Straw poll - out-of-path midcom agents Date: Tue, 19 Jun 2001 12:07:37 -0700 Message-ID: Thread-Topic: [midcom] Straw poll - out-of-path midcom agents Thread-Index: AcD468x91m2YUir4QM2xXxe4rTbRQgAByoxg From: "Christian Huitema" To: "Melinda Shore" , X-OriginalArrivalTime: 19 Jun 2001 19:07:37.0978 (UTC) FILETIME=[1AFB1DA0:01C0F8F3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA06254 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: 8bit I do not believe that we should provide support for out of path agent. The group should focus on solving the problems exposed in the scenarios draft, none of which involves out of path agents. The debate on OOP is, IMHO, typical of what is wrong with this group. Instead of solving the very simple problem of firewall traversal and actually enabling communication, the group is trying to invent all kinds of "transformers" that could be placed at arbitrary places in the network. We should cut that and focus. -- Christian Huitema > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, June 19, 2001 11:15 AM > To: midcom@ietf.org > Subject: [midcom] Straw poll - out-of-path midcom agents > > We've been going around and around on out-of-path agents > since the first draft of the document and it's my sense > that we're failing to make progress on it. I'd like to > take a straw poll to see how much support there is for > including support for diversion to out-of-path agents. > Please indicate to the mailing list whether or not you'd > like us to include consideration of out-of-path agents. > Be prepared to defend your position :-). > > 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 Tue Jun 19 15:24: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 PAA01466 for ; Tue, 19 Jun 2001 15:24:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06355; Tue, 19 Jun 2001 15:24:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06323 for ; Tue, 19 Jun 2001 15:24:16 -0400 (EDT) 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 PAA01422 for ; Tue, 19 Jun 2001 15:23:39 -0400 (EDT) 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 MAA42998; Tue, 19 Jun 2001 12:23:34 -0700 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA21338; Tue, 19 Jun 2001 12:23:41 -0700 Message-ID: <3B2FA412.CB2D83BC@hursley.ibm.com> Date: Tue, 19 Jun 2001 14:12:18 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Melinda Shore CC: midcom@ietf.org Subject: Re: [midcom] Straw poll - out-of-path midcom agents References: <00f701c0f8eb$b83ecba0$d45904d1@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 There's a strong analogy between your question and the debate now raging on the IETF list whether to charter OPES, which is about OOP agents at the HTTP and RTSP level. I think midcom probably needs to see which way the consensus and IESG decision go for OPES; if the IETF isn't willing to charter OPES, it's unlikely to be happy with midcom covering OOP agents. In fact if you extend the definition of "firewall" to include application entities, as Eric wants, you are in *exactly* the OPES scenario. If we have to decide today, I agree with Eric, and his arguments, with perhaps a note that OOP is for future study. Brian Melinda Shore wrote: > > We've been going around and around on out-of-path agents > since the first draft of the document and it's my sense > that we're failing to make progress on it. I'd like to > take a straw poll to see how much support there is for > including support for diversion to out-of-path agents. > Please indicate to the mailing list whether or not you'd > like us to include consideration of out-of-path agents. > Be prepared to defend your position :-). > > 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 Tue Jun 19 15:26: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 PAA01512 for ; Tue, 19 Jun 2001 15:26:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06459; Tue, 19 Jun 2001 15:25:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06402 for ; Tue, 19 Jun 2001 15:25:50 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01477 for ; Tue, 19 Jun 2001 15:25:13 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5JJPLx27153; Tue, 19 Jun 2001 12:25:22 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-7.cisco.com [10.21.96.7]) by airborne.cisco.com (Mirapoint) with ESMTP id ADV18028; Tue, 19 Jun 2001 12:25:14 -0700 (PDT) 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: <15151.42778.186000.551380@gargle.gargle.HOWL> Date: Tue, 19 Jun 2001 15:25:14 -0400 To: Brian E Carpenter Cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-Reply-To: <3B2FA10C.1364B969@hursley.ibm.com> References: <3B2FA10C.1364B969@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 On 19 Jun 2001 at 13:59 -0500, Brian E Carpenter apparently wrote: > I think the word "transparent" has too many interpretations > and too much history of abuse (as in "transparent proxy") to be a > useful word in this context. I think we should simply not use > the words "transparent" or "transparency" at all. Except we'll need to say something about transparency -- or the equivalent concept. WREC spent a lot of time on the word "transparent". Can anyone summarize what they came up with? (If not I'll make time to dig around over there (sigh).) ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 15:42:04 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 PAA02038 for ; Tue, 19 Jun 2001 15:42:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07250; Tue, 19 Jun 2001 15:41:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07217 for ; Tue, 19 Jun 2001 15:41:12 -0400 (EDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01958 for ; Tue, 19 Jun 2001 15:40:37 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CRN8-000AuB-00; Tue, 19 Jun 2001 12:41:10 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Scott Brim Cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 References: <3B2FA10C.1364B969@hursley.ibm.com> <15151.42778.186000.551380@gargle.gargle.HOWL> Message-Id: Date: Tue, 19 Jun 2001 12:41:10 -0700 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 by 'transparent," i hope we mean o does not modify data passing through or near it, and o does not change the detectable state of any network element based on data passing near or through it? if so, we should say so in no uncertain terms. if not, then best we be really specific and not use words which rely on simile. randy _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 16:00:15 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 QAA02661 for ; Tue, 19 Jun 2001 16:00:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07981; Tue, 19 Jun 2001 15:55:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07946 for ; Tue, 19 Jun 2001 15:55:42 -0400 (EDT) Received: from nemo.corp.equinix.com (somehost-5.equinix.net [207.20.85.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02491 for ; Tue, 19 Jun 2001 15:55:06 -0400 (EDT) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id MAA21137; Tue, 19 Jun 2001 12:55:00 -0700 (PDT) Message-Id: <200106191955.MAA21137@nemo.corp.equinix.com> Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 To: sbrim@cisco.com (Scott Brim) Date: Tue, 19 Jun 2001 12:55:00 -0700 (PDT) Cc: brian@hursley.ibm.com (Brian E Carpenter), midcom@ietf.org In-Reply-To: <15151.42778.186000.551380@gargle.gargle.HOWL> from "Scott Brim" at Jun 19, 2001 03:25:14 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 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 Many members of WREC would have dearly loved to take the term "transparent" and shoot it several times in order to watch it expire, slowly, in a pool of its own misuse. Sadly, it was a semi-protected species due to its use in RFC2616. This is the language in RFC3040 (the WREC taxonomy document) that dealt with the problem: interception proxy (a.k.a. "transparent proxy", "transparent cache") The term "transparent proxy" has been used within the caching community to describe proxies used with zero configuration within the user agent. Such use is somewhat transparent to user agents. Due to discrepancies with [1] (see definition of "proxy" above), and objections to the use of the word "transparent", we introduce the term "interception proxy" to describe proxies that receive redirected traffic flows from network elements performing traffic interception. Interception proxies receive inbound traffic flows through the process of traffic redirection. (Such proxies are deployed by network administrators to facilitate or require the use of appropriate services offered by the proxy). Problems associated with the deployment of interception proxies are described in the [1] is RFC2616. WREC also suggested that "network transparent proxy" be used where the author meant a proxy that did nothing to the request or response except what was required for proxy auth and identificaiton. regards, Ted Hardie > > On 19 Jun 2001 at 13:59 -0500, Brian E Carpenter apparently wrote: > > I think the word "transparent" has too many interpretations > > and too much history of abuse (as in "transparent proxy") to be a > > useful word in this context. I think we should simply not use > > the words "transparent" or "transparency" at all. > > Except we'll need to say something about transparency -- or the > equivalent concept. > > WREC spent a lot of time on the word "transparent". Can anyone > summarize what they came up with? (If not I'll make time to dig > around over there (sigh).) > > ..Scott > > > _______________________________________________ > 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 Jun 19 16:02: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 QAA02755 for ; Tue, 19 Jun 2001 16:02:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08260; Tue, 19 Jun 2001 16:00:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08221 for ; Tue, 19 Jun 2001 16:00:36 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02657 for ; Tue, 19 Jun 2001 16:00:01 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AEEB7EE00146; Tue, 19 Jun 2001 15:58:35 -0400 Message-ID: <005f01c0f8fa$6f3aa280$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" , "Pyda Srisuresh" Date: Tue, 19 Jun 2001 16:00:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [midcom] Framework-02 - NAPT Service Example 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, I have a few minor issues/questions with the NAPT service example. In section 7.2 it says: SIP calls to the private SIP phone will arrive as TCP/UDP sessions with destination address and port set to Ma and 5060 respectively. I think this might be a bit misleading. The SIP messages flowing from the external phone to the private phone will arrive at the SIP Proxy first. According to the time flow, the proxy asks the middlebox for the port previously bound to Ma:5060 (presumably the private phone's SIP port Pa:5060). Is their an assumption here that the private phone has registered with the proxy to establish the NAT for the SIP port? Or does this mean that the proxy knows the private address and is establishing the NAT for the SIP flow? Using just one port (Ma:5060) is fine if there is only one SIP phone in that private network. If there is more than one SIP phone, additional ports on the middlebox (Ma) will be needed for mapping to private phones. I believe someone (maybe me) suggested that an example where the proxy was inside the private network might be a little simpler. Also, I think it might be a more likely scenario in real deployments. When the proxy is inside the private network, only one NAT is needed for the SIP message flow. The SIP proxy would establish the mapping of Ma:5060 to its SIP port (let's call it Sa:5060 where Sa is the IP address of the SIP proxy) when it started up. This would make the above statement from section 7.2 correct. The proxy knows how to route the SIP messages to all the SIP phones in the private network. For a given session, only the NAPT operations for the RTP and RTCP streams would be required. I think the "100 Trying" response in all the flows should be immediately after the proxy receives the INVITE to stop the calling side from retransmitting the INVITE. thanks, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 16:27:53 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 QAA03769 for ; Tue, 19 Jun 2001 16:27:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08790; Tue, 19 Jun 2001 16:11:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08758 for ; Tue, 19 Jun 2001 16:11:30 -0400 (EDT) Received: from web13807.mail.yahoo.com (web13807.mail.yahoo.com [216.136.175.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03086 for ; Tue, 19 Jun 2001 16:10:55 -0400 (EDT) Message-ID: <20010619201130.29421.qmail@web13807.mail.yahoo.com> Received: from [65.12.33.187] by web13807.mail.yahoo.com; Tue, 19 Jun 2001 13:11:30 PDT Date: Tue, 19 Jun 2001 13:11:30 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 To: Brian E Carpenter , "Zmolek, Andrew \(Andrew\)" Cc: Melinda Shore , Pyda Srisuresh , "Fleischman, Eric W" , Andrew Molitor , midcom@ietf.org In-Reply-To: <3B2FA10C.1364B969@hursley.ibm.com> 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 I did a grep on the terms "Transparent" and "transparency" to see where and how they are used in the FW document. Below is a list of my findings and sugegsted remedies. I believe, it is OK to use terms like "end-to-end transparency" (item 1 below) and "Transparent routing" (item 3 below). They have a specific meaning that goes with them. But, as Brian pointed out, it is tricky to use these temrs in the context of proxies, ALGs, agents and the like. 1. Paragraph 1 of section 1 - Introduction "Application Level gateways (ALGs) are used in conjunction with NAT to provide end-to-end transparency for many of the applications." I think, it should be OK to leave this unchanged. 2. Paragraph 3 of Section 1 - Introduction "The communication between a MIDCOM agent and a middlebox will be transparent to the end-hosts that take part in the application, unless one of the end-hosts assumes the role of a MIDCOM agent." I could reword this as follows: "The communication between a MIDCOM agent and a middlebox will not be noticeable to the end-hosts that take part in the application, unless one of the end-hosts assumes the role of a MIDCOM agent." 3. Sectin 2.4. - NAT "Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end-hosts." This definition is settled after a long series of discussion prior to advancing RFC 2663. The definition is carried as is from RFC 2663. I donot recommend changing this. 4. Paragraph 3 of section 2.6 - ALG "ALGs are different from proxies. ALGs are transparent to end-hosts, unlike the proxies which are relay agents terminating sessions with both end-hosts." I could rephrase the above as follows: "ALGs are different from proxies. ALGs are not visible to end-hosts, unlike the proxies which are relay agents terminating sessions with both end-hosts." 5. Paragraph 3 of section 5.2. - OOP MIDCOM agents "In essence, a middlebox provides to an Out-of-Path MIDCOM agent the ability to transparently "snoop" and modify the control traffic." I can reword the above as follows. "In essence, a middlebox provides to an Out-of-Path MIDCOM agent the same priveleges as that of an In-Path agent, to application control traffic, to "snoop" and modify as deemed appropriate." 6. The legend in figure 5 for "Ctrl" is described as follows. "Ctrl - indicates the FTP control traffic, which is transparently diverted to the OOP agent (2 and 3)" I can remove the word, and yet not change the semantics here. Thanks. regards, suresh --- Brian E Carpenter wrote: > I think the word "transparent" has too many interpretations > and too much history of abuse (as in "transparent proxy") to be a > useful word in this context. I think we should simply not use > the words "transparent" or "transparency" at all. > > Brian > > > "Zmolek, Andrew (Andrew)" wrote: > > > > It seems that we've been debating the meaning of transparency for some time > now. Perhaps we are talking about different shades > > of transparency, and if that really does matter than we need to elaborate. > > > > - Transparency at an application layer so that client and server both have > a rational conversation is probably what we're > > aiming for when we talk about OOP agent transparency. Some OOP agents still > manage to mangle things here, but the aim is still > > transparency. > > > > - Transparency at the transport layer is something else. Many OOP agents > will have to interact with the underlying transport > > infrastructure to deal with packet forwarding, route information, address > and port assignment details, etc. So transparency is > > a harder sell here. > > > > Is it possible we can find enough middle ground in this decomposition of > the word "transparent" that we can move on? > > > > --Andy Zmolek > > Technology & Standards Engineer > > CTO Standards > > Avaya Inc. > > > > zmolek@avaya.com > > +1 720 444 4001 > > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Tuesday, June 19, 2001 11:44 AM > > To: Pyda Srisuresh; Fleischman, Eric W; 'Andrew Molitor'; > > midcom@ietf.org > > Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 > > > > > OOP agent are not visible to end-hosts. So, an OOP agent is transparent. > > > > I wouldn't agree that one follows from the other. > > If the out-of-path agent effects a change in the behavior > > of the data/application/what-have-you, it's not transparent. > > > > 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 __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 16:58:52 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 QAA04729 for ; Tue, 19 Jun 2001 16:58:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10382; Tue, 19 Jun 2001 16:56:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10347 for ; Tue, 19 Jun 2001 16:56:04 -0400 (EDT) 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 QAA04668 for ; Tue, 19 Jun 2001 16:55:29 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id DA5B081DB for ; Tue, 19 Jun 2001 15:56:03 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id PAA16865 for ; Tue, 19 Jun 2001 15:56:03 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Tue, 19 Jun 2001 15:56:03 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Straw poll - out-of-path midcom agents In-Reply-To: <00f701c0f8eb$b83ecba0$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 I think including OOP agents in the framework, at least, is exceedingly reasonable. My defense follows: Transparent proxy/firewall technology is extremely widespread and used (or at least present, even if disabled) in virtually every firewall product in existence. A canonical OOP agent implementation is to graft a MIDCOM agent interface onto one of these transparent firewall devices. Conversely, such a transparent device is a natural device onto which one might want to graft a MIDCOM agent interface. Of course, not all OOP Agents will be built this way, but it's an interesting subset. In order to be really useful (say, for performance reasons), the middlebox should operate in parallel with the transparent agent, not serially (otherwise the transparent agent could just do all the policy internal to itself!) This implies a packet diversion function in the middlebox, since the Agent is out of the natural flow of traffic, as indicated below. This makes sense: +---------------+ | Transparent | | Fwall as OOP | | Agent | +---------------+ | | +--------+ | | Middle | | -----| Box |-------+-------- <---> Natural Flow of Traffic +--------+ This does not, since the Fwall can just do the policy itself: +----------+ +-------------------+ | Middle | | Transparent Fwall | ---| Box |------------| as OOP Agent |---- +----------+ +-------------------+ We can eliminate discussion of OOP agents, and retain the In-Path agent, thereby implicitly (or perhaps explicitly) making MIDCOM specific to applications which use some sort of explicit transaction routing element which can be the In-Path agent. This for all practical purposes makes MIDCOM SIP-specific -- name me another application which uses In-Path control elements and which would truly benefit from MIDCOM! I do not think this an acceptable scenario. If we eliminate OOP Agents, therefore, we must eliminate the distinction between OOP and In-Path agents entirely, and make it Out Of Scope to figure out how the Agent gets the information it needs. This, of course, allows for OOP Agents, In-Path Agents, Secret Agents, and every other sort of Agent you like. OOP agents will exist (and indeed are likely to outnumber In-Path agents, in the field), and middleboxes will support packet diversion to support them. If standards do not exist to allow an OOP agent to register for specific traffic diversions, ad-hoc solutions will be devised by vendors. Eliminating agent types would have the effect of focusing the working group purely on the protocol definition, which is a useful thing. My opinion, however, is that this also: - leaves the protocol work operating nearly in a vacuum, with too little useful context. - eliminates consideration of specific protocol support for OOP agents which is likely to, leading to non-standard solutions. - is not necessary, there is not at this point an excess of work to be done -- trimming the scope is not necessary. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 17:29:28 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 RAA05485 for ; Tue, 19 Jun 2001 17:29:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11551; Tue, 19 Jun 2001 17:27:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11520 for ; Tue, 19 Jun 2001 17:27:11 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05445 for ; Tue, 19 Jun 2001 17:26:35 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA19034; Tue, 19 Jun 2001 17:27:06 -0400 (EDT) Message-Id: <200106192127.RAA19034@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Scott Brim , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Tue, 19 Jun 2001 12:41:10 PDT." Date: Tue, 19 Jun 2001 17:27:05 -0400 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 > by 'transparent," i hope we mean > o does not modify data passing through or near it, and > o does not change the detectable state of any network element based on > data passing near or through it? that seems like a reasonable definition of the word for this discussion. and we already have better words (interception, hijacking) to describe network elements that do exactly the opposite, and for which the endpoints are not aware. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 17:29: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 RAA05484 for ; Tue, 19 Jun 2001 17:29:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11493; Tue, 19 Jun 2001 17:26:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11464 for ; Tue, 19 Jun 2001 17:26:26 -0400 (EDT) Received: from web13803.mail.yahoo.com (web13803.mail.yahoo.com [216.136.175.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05419 for ; Tue, 19 Jun 2001 17:25:49 -0400 (EDT) Message-ID: <20010619212624.59145.qmail@web13803.mail.yahoo.com> Received: from [65.12.33.187] by web13803.mail.yahoo.com; Tue, 19 Jun 2001 14:26:24 PDT Date: Tue, 19 Jun 2001 14:26:24 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Straw poll - out-of-path midcom agents To: Melinda Shore , midcom@ietf.org In-Reply-To: <00f701c0f8eb$b83ecba0$d45904d1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I believe, the framework document should make the distinction between In-Path and Out-Of-Path (OOP_ agents. There is no difference in MIDCOM protocol, per se, irrespective of the agent type. Support for diversion function or its implementation can be vendor proprietary. There has never been a suggestion that this WG (or the follow-on WG) should address it. Not all applications have In-Path entities such as Proxies or Gateways. There are many that dont. For those applications, the only viable choice that this WG offers would be to fold the agent into end-hosts. This is not necessarily a scalable or acceptable solution. Even when an application has In-path entities(say proxies), there are many enterprises that dont run them. It is not necessarily economical to run the agent on these entities, even when an enterprise has these proxies installed in-house. The MIDCOM agent should not be mandated to run on just the In-path entities. There are many ASP vendors that might have a proposition to accomplish the same using OOP agents, more economically - Say, running the same OOP agent to work with multiple enterprises to enable a specific application (or) a set of applications. OOP agents have the advantage of not being tied to a certain topological restriction. As such, it would be a mistake for the FW draft to restrict the use or mention of OOP agents. To reiterate - I believe, Support for OOP agents on a middlebox could be made vendor proprietray and as such, the diversion function or its implementation can be out of bounds for this WG (or the follow-on WG). Ignoring or failing to mention the OOP agents in a MIDCOM framework document is, at best, an incomplete work. regards, suresh --- Melinda Shore wrote: > We've been going around and around on out-of-path agents > since the first draft of the document and it's my sense > that we're failing to make progress on it. I'd like to > take a straw poll to see how much support there is for > including support for diversion to out-of-path agents. > Please indicate to the mailing list whether or not you'd > like us to include consideration of out-of-path agents. > Be prepared to defend your position :-). > > Melinda > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 17:32:08 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 RAA05579 for ; Tue, 19 Jun 2001 17:32:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11912; Tue, 19 Jun 2001 17:31:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11883 for ; Tue, 19 Jun 2001 17:31:40 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05567 for ; Tue, 19 Jun 2001 17:31:03 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA19073; Tue, 19 Jun 2001 17:31:28 -0400 (EDT) Message-Id: <200106192131.RAA19073@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pyda Srisuresh cc: Brian E Carpenter , "Zmolek, Andrew \(Andrew\)" , Melinda Shore , "Fleischman, Eric W" , Andrew Molitor , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Tue, 19 Jun 2001 13:11:30 PDT." <20010619201130.29421.qmail@web13807.mail.yahoo.com> Date: Tue, 19 Jun 2001 17:31:28 -0400 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 believe, it is OK to use terms like "end-to-end transparency" (item 1 > below) and "Transparent routing" (item 3 below). They have a specific > meaning that goes with them. I assert that it would be far less confusing overall all forms of the word "transparent" were reserved for data transparency as defined by Randy. If our goal is to produce readable documents, we should avoid conflicting uses of this term. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 17:52: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 RAA05978 for ; Tue, 19 Jun 2001 17:52:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12372; Tue, 19 Jun 2001 17:51:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12343 for ; Tue, 19 Jun 2001 17:51:40 -0400 (EDT) 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 RAA05955 for ; Tue, 19 Jun 2001 17:51:04 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id EEE0D810C for ; Tue, 19 Jun 2001 16:51:39 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA19724 for ; Tue, 19 Jun 2001 16:51:39 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Tue, 19 Jun 2001 16:51:39 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 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 Tue, 19 Jun 2001, Randy Bush wrote: > by 'transparent," i hope we mean > o does not modify data passing through or near it, and > o does not change the detectable state of any network element based on > data passing near or through it? No offense, but this sounds sort of like the networking equivalent of a neutrino. What earthly use would a device with these properties have? I can see the marketing materials now: "Buy our Xj13-Z Transparent Widget! It has NO DETECTABLE EFFECTS!" Presumably you mean that it has no effects detectable to some class of user or traffic? Say, it has no effects detectable by authorized personnel using the network in authorized ways? As a former mathematician, I am surprisingly comfortable with terms meaning all manner of conflicting things, provided context makes clear which meaning is intended. In my limited experience, "transparent" is usually a modifier: "transparent firewall" is a fairly well defined widget, for example. Anyone planning to introduce a new usage should, of course, be required to provide a clear (ho ho ho) definition of the usage. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 17:52: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 RAA06002 for ; Tue, 19 Jun 2001 17:52:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12420; Tue, 19 Jun 2001 17:52:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12391 for ; Tue, 19 Jun 2001 17:52:15 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05974 for ; Tue, 19 Jun 2001 17:51:39 -0400 (EDT) Received: from cisco.com (dhcp-2sjc13-85-244.cisco.com [171.70.85.244]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA29178; Tue, 19 Jun 2001 14:51:09 -0700 (PDT) Message-ID: <3B30720A.19569E03@cisco.com> Date: Wed, 20 Jun 2001 02:51:06 -0700 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Zmolek, Andrew (Andrew)" CC: Melinda Shore , Pyda Srisuresh , "Fleischman, Eric W" , Andrew Molitor , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 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 > "Zmolek, Andrew (Andrew)" wrote: > > It seems that we've been debating the meaning of transparency for some > time now[...] Indeed this is where the term FOGLAMPS came from. It appears I should probably have submitted that document as an informational RFC, since people are spinning on history. If you have an opinion on me doing so, please direct it to me, AND NOT TO THIS LIST. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 17:55: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 RAA06065 for ; Tue, 19 Jun 2001 17:55:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12573; Tue, 19 Jun 2001 17:55:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12543 for ; Tue, 19 Jun 2001 17:55:25 -0400 (EDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06060 for ; Tue, 19 Jun 2001 17:54:48 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CTSv-000EWT-00; Tue, 19 Jun 2001 14:55:17 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: Scott Brim , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 References: <200106192127.RAA19034@astro.cs.utk.edu> Message-Id: Date: Tue, 19 Jun 2001 14:55:17 -0700 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 >> by 'transparent," i hope we mean >> o does not modify data passing through or near it, and >> o does not change the detectable state of any network element based on >> data passing near or through it? > that seems like a reasonable definition of the word for this discussion. glad you like it. > and we already have better words (interception, hijacking) to describe > network elements that do exactly the opposite, and for which the endpoints > are not aware. no. those terms suck even worse than transparent. they are emotionally loaded and convey little technical detail. this was the point of my message. do not use similes. do not use idioms. ... we need to very carefully say exactly what is done and in clear simple technical terms, or we will keep wrapping around the axle of emotionally loaded but content free gigo-speak. randy _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 18:07: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 SAA06357 for ; Tue, 19 Jun 2001 18:07:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13042; Tue, 19 Jun 2001 18:04:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13010 for ; Tue, 19 Jun 2001 18:04:37 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06324 for ; Tue, 19 Jun 2001 18:04:00 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA00850 for ; Tue, 19 Jun 2001 15:04:12 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA24628 for ; Tue, 19 Jun 2001 15:04:26 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Tue, 19 Jun 2001 15:04:17 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 15:04:16 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DB3@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Pyda Srisuresh'" , Melinda Shore , midcom@ietf.org Date: Tue, 19 Jun 2001 15:04:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [midcom] Compromise on OOP Agents? 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 don't want to influence the straw poll with this posting, but Pyda's and Keith Moore's recent postings both suggested a compromise solution to me that I wanted to explicitly ask the group about. Specifically, what would the WG's reaction be to the following idea, which I propose as a potential compromise position: 1) The framework document primarily deals with In-Path Agents -- i.e., restricts itself to the scenarios identified by Christian Huitema's Scenarios draft, which I believe is the charter of both the FW document and this WG. In-Path Agents will thus comprise the vast majority of the material within the frameworks document. 2) However, the framework document should explicitly mention that OOP agents are an implementation possibility and that the following benefits accrue by including OOP agents (an enumeration can then be made by the OOP advocates). 3) However, should OOP agents be implemented, those OOP agents should be implemented to appear to be MIDCOM Agents resident on end systems (and, by implication, their implementation is accomplished via proprietary/vendor- specific methods rather than something specifically detailed by the Midcom WG). --Eric -----Original Message----- From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] Sent: Tuesday, June 19, 2001 2:26 PM To: Melinda Shore; midcom@ietf.org Subject: Re: [midcom] Straw poll - out-of-path midcom agents I believe, the framework document should make the distinction between In-Path and Out-Of-Path (OOP_ agents. There is no difference in MIDCOM protocol, per se, irrespective of the agent type. Support for diversion function or its implementation can be vendor proprietary. There has never been a suggestion that this WG (or the follow-on WG) should address it. Not all applications have In-Path entities such as Proxies or Gateways. There are many that dont. For those applications, the only viable choice that this WG offers would be to fold the agent into end-hosts. This is not necessarily a scalable or acceptable solution. Even when an application has In-path entities(say proxies), there are many enterprises that dont run them. It is not necessarily economical to run the agent on these entities, even when an enterprise has these proxies installed in-house. The MIDCOM agent should not be mandated to run on just the In-path entities. There are many ASP vendors that might have a proposition to accomplish the same using OOP agents, more economically - Say, running the same OOP agent to work with multiple enterprises to enable a specific application (or) a set of applications. OOP agents have the advantage of not being tied to a certain topological restriction. As such, it would be a mistake for the FW draft to restrict the use or mention of OOP agents. To reiterate - I believe, Support for OOP agents on a middlebox could be made vendor proprietray and as such, the diversion function or its implementation can be out of bounds for this WG (or the follow-on WG). Ignoring or failing to mention the OOP agents in a MIDCOM framework document is, at best, an incomplete work. regards, suresh --- Melinda Shore wrote: > We've been going around and around on out-of-path agents > since the first draft of the document and it's my sense > that we're failing to make progress on it. I'd like to > take a straw poll to see how much support there is for > including support for diversion to out-of-path agents. > Please indicate to the mailing list whether or not you'd > like us to include consideration of out-of-path agents. > Be prepared to defend your position :-). > > Melinda > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.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 Tue Jun 19 18:22:47 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 SAA06533 for ; Tue, 19 Jun 2001 18:22:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13398; Tue, 19 Jun 2001 18:19:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13326 for ; Tue, 19 Jun 2001 18:19:10 -0400 (EDT) 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 SAA06498 for ; Tue, 19 Jun 2001 18:18:33 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 6A4568150 for ; Tue, 19 Jun 2001 16:37:39 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA21251 for ; Tue, 19 Jun 2001 17:19:09 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Tue, 19 Jun 2001 17:19:09 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Framework-02 - NAPT Service Example In-Reply-To: <005f01c0f8fa$6f3aa280$2300000a@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 Tue, 19 Jun 2001, Bob Penfield wrote: > Suresh, > > I have a few minor issues/questions with the NAPT service example. > > In section 7.2 it says: > > SIP calls to the private SIP phone will > arrive as TCP/UDP sessions with destination address and port set > to Ma and 5060 respectively. > > I think this might be a bit misleading. The SIP messages flowing from the > external phone to the private phone will arrive at the SIP Proxy first. > According to the time flow, the proxy asks the middlebox for the port > previously bound to Ma:5060 (presumably the private phone's SIP port > Pa:5060). Is their an assumption here that the private phone has registered > with the proxy to establish the NAT for the SIP port? Or does this mean that > the proxy knows the private address and is establishing the NAT for the SIP > flow? Gosh, this certainly is confusing now that I look closely! There are a couple of ways to make this scenario work, in SIP-land. That is, the scenario where the proxy (which we assume includes the SIP registrar function) is outside, and the phone(s) are inside. One way is described in great and wonderous detail by Rosenberg et al: - the phone registers using TCP, which flows through the NAT/NAPT widget in the normal way -- no MIDCOM involved, really. - the phone keeps the TCP stream open - the proxy, upon receipt of an INVITE, searches live TCP streams FIRST before consulting its database In this scenario, the SIP proxy doesn't need to know the phone's private IP address, or do any NAT binding work to pass signaling to the phone. For this scenario, picture is too complicated, containing a bunch of stuff for binding port 5060 and so on. With a middlebox, the other elements of the Rosenberg et al proposal become mostly unnecessary. Another way to to teach the proxy about private IP addresses. It could know that 'amolitor@aravox.com, 192.168.1.1' is behind middlebox A, and 'bpenfield@acmepacket.com, 192.168.1.1' is behind middlebox B. Then, when an INVITE comes in for amolitor@aravox.com it can do MIDCOM magic to middlebox A, requesting a binding of '192.168.1.1, port 5060', and get back 'Ma:' which it uses to send signaling to Andrew's phone (note: NOT to port 5060!). Of course, when a call comes in for the esteemed Mr. Penfield, the proxy does the exact same thing -- to a different middlebox. This resolves the apparent ambiguity of two people, both registered at 192.168.1.1. For this scenario, the picture is about right, but neglects the fact that for more than one phone, they really can't all use Ma:5060, they'll have to use Ma:. > Using just one port (Ma:5060) is fine if there is only one SIP phone in that > private network. If there is more than one SIP phone, additional ports on > the middlebox (Ma) will be needed for mapping to private phones. Precisely! > I believe someone (maybe me) suggested that an example where the proxy was > inside the private network might be a little simpler. Also, I think it might > be a more likely scenario in real deployments. Much easier. It allows the use of perfectly ordinary proxies, as well, instead of proxies which extend SIP (or interpret SIP is rather specific ways, as in the Rosenberg-like scenario). _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 18:23: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 SAA06548 for ; Tue, 19 Jun 2001 18:23:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13485; Tue, 19 Jun 2001 18:20:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13450 for ; Tue, 19 Jun 2001 18:20:13 -0400 (EDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06505 for ; Tue, 19 Jun 2001 18:19:36 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CTr0-000FP0-00; Tue, 19 Jun 2001 15:20:10 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andrew Molitor Cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 References: Message-Id: Date: Tue, 19 Jun 2001 15:20:10 -0700 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 >> by 'transparent," i hope we mean >> o does not modify data passing through or near it, and >> o does not change the detectable state of any network element based on >> data passing near or through it? > No offense, but this sounds sort of like the networking equivalent of a > neutrino. What earthly use would a device with these properties have? oh, network measurement a la vern, sally, jrex, bala, et al. lots of stuff like that. but my point was not to apply my restrictive terms to the work here. my point was, please do not use the term if you don't mean it in a very clear and absolute sense. 'transparent' is a simile and marketspeak. please say precisely what is done, and clearly, not in marketspeak. e.g. if you mean that a particular middle-box detects a flow passing through it and, based on observation of that flow, signals another box to allow the flow through, then say so. i am not in denial about middle-boxen, nats, or even atm . some of my best friends use them. i just want it all clearly labeled, as i get easily confused by marketspeak such as 'transparent,' and it is pretty clear that others do as well. randy _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 18:24: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 SAA06577 for ; Tue, 19 Jun 2001 18:24:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13533; Tue, 19 Jun 2001 18:20:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13506 for ; Tue, 19 Jun 2001 18:20:52 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06520 for ; Tue, 19 Jun 2001 18:20:15 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA19558; Tue, 19 Jun 2001 18:20:43 -0400 (EDT) Message-Id: <200106192220.SAA19558@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Keith Moore , Scott Brim , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Tue, 19 Jun 2001 14:55:17 PDT." Date: Tue, 19 Jun 2001 18:20:42 -0400 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 > > and we already have better words (interception, hijacking) to describe > > network elements that do exactly the opposite, and for which the endpoints > > are not aware. > > no. those terms suck even worse than transparent. they are emotionally > loaded and convey little technical detail. this was the point of my > message. do not use similes. do not use idioms. ... it's a laudable goal. but it's difficult for a term to give some clue as to its meaning and at the same time be free of all bias. and once terms are in use they tend to acquire some bias anyway, through association with their technologies. "nat" started out to be value-neutral, but has picked up some bias along the way. I'll note that 'transparent' also has emotional loading - it just tends to be favorable loading. which is after all part of the reason why both sides have used it. IIRC, 'interception' was picked by proponents of interception proxies, so I figure it's close to optimal. (if you are watching American football and are a fan of the team currently playing defense, an interception is a good thing...) admittedly, 'interception' is less loaded than 'hijacking'. mainly I was saying that we need to be consistent about the use of terms - e.g. we should not use 'transparent' to mean one thing in one case and something that is almost completely the opposite in another. > we need to very carefully say exactly what is done and in clear simple > technical terms, or we will keep wrapping around the axle of emotionally > loaded but content free gigo-speak. agree entirely. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 18:45: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 SAA06932 for ; Tue, 19 Jun 2001 18:45:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14236; Tue, 19 Jun 2001 18:41:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14207 for ; Tue, 19 Jun 2001 18:41:31 -0400 (EDT) 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 SAA06884 for ; Tue, 19 Jun 2001 18:40:54 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 8F7B98106 for ; Tue, 19 Jun 2001 16:59:59 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA22581 for ; Tue, 19 Jun 2001 17:41:29 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Tue, 19 Jun 2001 17:41:29 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 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 Tue, 19 Jun 2001, Randy Bush wrote: > >> by 'transparent," i hope we mean > >> o does not modify data passing through or near it, and > >> o does not change the detectable state of any network element based on > >> data passing near or through it? > > No offense, but this sounds sort of like the networking equivalent of a > > neutrino. What earthly use would a device with these properties have? > > oh, network measurement a la vern, sally, jrex, bala, et al. lots of stuff > like that. Ouch, you got me ;) I agree entirely with your remarks, clarity is always important. I am comfortable with saying, though: - an In-Path agent is, by definition, one in which traffic is IP addressed to the agent device by some other network element, and the content of that traffic is used to make policy decisions which are then implemented by the Agent using the MIDCOM protocol. - an Out-Of-Path agent is, by definition, one in which traffic NOT IP addressed to the agent is, by some mechanism, directed to the agent. The content of that traffic is used to make policy decisions which are then implemented by the Agent using the MIDCOM protocol. For brevity, we will describe such an Agent as 'transparent' to the end systems or applications on behalf of which policy is implemented. In this case, 'transparent' means 'looks at some traffic that's not addressed to it and does some kind of undefined stuff (perhaps modify the traffic, or dance and sing, or install policy in a NAT) which doesn't break the application.' I gather 'transparent' is a loaded word to some of us, with a history of unclear and conflicting usage. If the consensus is that its baggage makes is unusable, I am happy to agree with its suppression and will try hard to not use it. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 19:19: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 TAA07453 for ; Tue, 19 Jun 2001 19:19:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15265; Tue, 19 Jun 2001 19:10:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15235 for ; Tue, 19 Jun 2001 19:10:55 -0400 (EDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07319 for ; Tue, 19 Jun 2001 19:10:18 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CUcW-000IAE-00; Tue, 19 Jun 2001 16:09:16 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andrew Molitor Cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 References: Message-Id: Date: Tue, 19 Jun 2001 16:09:16 -0700 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 > In this case, 'transparent' means 'looks at some traffic that's > not addressed to it and does some kind of undefined stuff (perhaps > modify the traffic, or dance and sing, or install policy in a NAT) > which doesn't break the application.' a transparent piece of glass does not alter the light passing through it or cause a door to open or close. i.e. the simile conflicts with the well-known use of the term. so what you seem to have meant is a box in the middle of the path which may modify the traffic or cause other devices to alter their behavior based on the traffic the mid-path box observerd. [ and i can see uses for such a box ] you could use a keithism, like "mid-path mangler" but "transparent" would seem a bit disingenuous. [ and yes, i have used a dictionary ] randy --- "Then you should say what you mean," the March Hare went on. "I do," Alice hastily replied; "At least at least I mean what I say that's the same thing, you know." "Not the same thing a bit!" said the Hatter. "Why, you might just as well say that `I see what I eat' is the same thing as `I eat what I see'!" -- Lewis Carroll _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 19:21: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 TAA07549 for ; Tue, 19 Jun 2001 19:21:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15500; Tue, 19 Jun 2001 19:19:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15471 for ; Tue, 19 Jun 2001 19:19:02 -0400 (EDT) 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 TAA07439 for ; Tue, 19 Jun 2001 19:18:27 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 583C18109 for ; Tue, 19 Jun 2001 17:37:30 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id SAA24388 for ; Tue, 19 Jun 2001 18:19:01 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Tue, 19 Jun 2001 18:19:01 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 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 Tue, 19 Jun 2001, Randy Bush wrote: > a transparent piece of glass does not alter the light passing through it > or cause a door to open or close. i.e. the simile conflicts with the > well-known use of the term. > > so what you seem to have meant is a box in the middle of the path which > may modify the traffic or cause other devices to alter their behavior > based on the traffic the mid-path box observerd. [ and i can see uses > for such a box ] This usage closely matches the common usage 'transparent firewall' which uses it to mean, roughly, 'a user who isn't specifically looking can't see it.' I don't know why 'invisible' wasn't used, but I didn't invent the usage. > "Then you should say what you mean," the March Hare went on. > > "I do," Alice hastily replied; "At least at least I mean what I say that's > the same thing, you know." > > "Not the same thing a bit!" said the Hatter. "Why, you might just as well > say that `I see what I eat' is the same thing as `I eat what I see'!" > > -- Lewis Carroll "'When I use a word,' Humpty Dumpty said in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.'" -- Lewis Carroll _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 19:36: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 TAA07791 for ; Tue, 19 Jun 2001 19:36:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15935; Tue, 19 Jun 2001 19:30:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15889 for ; Tue, 19 Jun 2001 19:30:42 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07677 for ; Tue, 19 Jun 2001 19:29:54 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA20063; Tue, 19 Jun 2001 19:30:27 -0400 (EDT) Message-Id: <200106192330.TAA20063@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Andrew Molitor cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Tue, 19 Jun 2001 16:51:39 CDT." Date: Tue, 19 Jun 2001 19:30:27 -0400 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 > "transparent firewall" is a fairly well defined widget, for example sounds like an oxymoron to me. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 19:36: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 TAA07802 for ; Tue, 19 Jun 2001 19:36:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16127; Tue, 19 Jun 2001 19:32:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16095 for ; Tue, 19 Jun 2001 19:32:04 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07732 for ; Tue, 19 Jun 2001 19:31:28 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA20105; Tue, 19 Jun 2001 19:31:57 -0400 (EDT) Message-Id: <200106192331.TAA20105@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Fleischman, Eric W" cc: "'Pyda Srisuresh'" , Melinda Shore , midcom@ietf.org Subject: Re: [midcom] Compromise on OOP Agents? In-reply-to: Your message of "Tue, 19 Jun 2001 15:04:14 PDT." <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DB3@XCH-NW-01.nw.nos.boeing.com> Date: Tue, 19 Jun 2001 19:31:57 -0400 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 fwiw, I'm also opposed to midcom working on OOP agents, now or ever. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 19:42: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 TAA07976 for ; Tue, 19 Jun 2001 19:42:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16409; Tue, 19 Jun 2001 19:41:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16380 for ; Tue, 19 Jun 2001 19:41:47 -0400 (EDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07947 for ; Tue, 19 Jun 2001 19:41:11 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CV7v-000K8m-00; Tue, 19 Jun 2001 16:41:43 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andrew Molitor Cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 References: Message-Id: Date: Tue, 19 Jun 2001 16:41:43 -0700 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 > "'When I use a word,' Humpty Dumpty said in rather a scornful tone, > `it means just what I choose it to mean -- neither more nor less.'" and remember his fate randy _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 19: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 TAA08048 for ; Tue, 19 Jun 2001 19:48:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16572; Tue, 19 Jun 2001 19:48:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16543 for ; Tue, 19 Jun 2001 19:48:10 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08040 for ; Tue, 19 Jun 2001 19:47:34 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA20316; Tue, 19 Jun 2001 19:48:08 -0400 (EDT) Message-Id: <200106192348.TAA20316@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Andrew Molitor cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Tue, 19 Jun 2001 18:19:01 CDT." Date: Tue, 19 Jun 2001 19:48:08 -0400 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 usage closely matches the common usage 'transparent > firewall' which uses it to mean, roughly, 'a user who isn't specifically > looking can't see it.' I don't know why 'invisible' wasn't used probably because the term was chosen by a marketing person, precisely because it does have favorable associations. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 20:36: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 UAA09048 for ; Tue, 19 Jun 2001 20:36:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA18131; Tue, 19 Jun 2001 20:34:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA18104 for ; Tue, 19 Jun 2001 20:34:14 -0400 (EDT) Received: from zsc3s002.nortelnetworks.com (h86s136a81n47.user.nortelnetworks.com [47.81.136.86]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08960 for ; Tue, 19 Jun 2001 20:33:38 -0400 (EDT) Received: from smtprch1.nortel.com by zsc3s002.nortelnetworks.com (SMI-8.6/SMI-SVR4) id RAA18512; Tue, 19 Jun 2001 17:04:05 -0700 Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Tue, 19 Jun 2001 19:33:09 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 17:33:05 -0700 Message-ID: From: "Reinaldo Penno" To: "'Pyda Srisuresh'" , Melinda Shore , midcom@ietf.org Subject: RE: [midcom] Straw poll - out-of-path midcom agents Date: Tue, 19 Jun 2001 17:32:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F920.8D40AE70" 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_001_01C0F920.8D40AE70 Content-Type: text/plain; charset="iso-8859-1" So, IMO having a in-path agent might be really the focus of this group, but I have doubts this model will fly. Unless is for a subset of applications/deployment scenarios. So, if this WG is not going to deal with OOP, I would like to know if this problem/scenario is going to be discussed in some other mailing list (I want to be in). Or if some folks are interested on taking this discussion offline and trying to put something on paper, I also would like that. I totally agree with these statements. There is also a scenario where a Service Provider want to wholesale a MIDCOM box to different enterprises using a VR model, where different traffic might be redirected to different agents in different locations. " Even when an application has In-path entities(say proxies), there are many enterprises that dont run them. It is not necessarily economical to run the agent on these entities, even when an enterprise has these proxies installed in-house. The MIDCOM agent should not be mandated to run on just the In-path entities. There are many ASP vendors that might have a proposition to accomplish the same using OOP agents, more economically - Say, running the same OOP agent to work with multiple enterprises to enable a specific application (or) a set of applications. OOP agents have the advantage of not being tied to a certain topological restriction." As far as the protocol between the MIDCOM box and agent, that might proprietary or not. I would like it to a multi-vendor effort since some manufactures might build MIDCOM boxes, but not agents and vice-versa. regards, Reinaldo NortelNetworks > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Tuesday, June 19, 2001 2:26 PM > To: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] Straw poll - out-of-path midcom agents > > > > I believe, the framework document should make the distinction > between In-Path and Out-Of-Path (OOP_ agents. There is no difference > in MIDCOM protocol, per se, irrespective of the agent type. Support > for diversion function or its implementation can be vendor > proprietary. > There has never been a suggestion that this WG (or the follow-on WG) > should address it. > ------_=_NextPart_001_01C0F920.8D40AE70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Straw poll - out-of-path midcom agents

So,

IMO having a in-path agent might be really the focus = of this group, but I have doubts this model will fly. Unless is for a = subset of applications/deployment scenarios.

So, if this WG is not going to deal with OOP, I would = like to know if this problem/scenario is going to be discussed in some = other mailing list (I want to be in). Or if some folks are interested = on taking this discussion offline and trying to put something on paper, = I also would like that.

I totally agree with these statements. There is also = a scenario where a Service Provider want to wholesale a MIDCOM box to = different enterprises using a VR model, where different traffic might = be redirected to different agents in different locations.

" Even when an application has In-path = entities(say proxies), there are
 many enterprises that dont run them. It is not = necessarily economical
 to run the agent on these entities, even when = an enterprise has these
 proxies installed in-house. The MIDCOM agent = should not be mandated
 to run on just the In-path entities.
 
 There are many ASP vendors that might have = a  proposition to
 accomplish the same using OOP agents, more = economically - Say, running
 the same OOP agent to work with multiple = enterprises to enable a
 specific application (or) a set of = applications. OOP agents have
 the advantage of not being tied to a certain = topological
 restriction."

As far as the protocol between the MIDCOM box and = agent, that might proprietary or not. I would like it to a multi-vendor = effort since some manufactures might build MIDCOM boxes, but not agents = and vice-versa.

regards,

Reinaldo
NortelNetworks

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]
> Sent: Tuesday, June 19, 2001 2:26 PM
> To: Melinda Shore; midcom@ietf.org
> Subject: Re: [midcom] Straw poll - out-of-path = midcom agents
>
>
>
> I believe, the framework document should make = the distinction
> between In-Path and Out-Of-Path (OOP_ agents. = There is no difference
> in MIDCOM protocol, per se, irrespective of the = agent type. Support
> for diversion function or its implementation = can be vendor
> proprietary.
> There has never been a suggestion that this WG = (or the follow-on WG)
> should address it.



>

------_=_NextPart_001_01C0F920.8D40AE70-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 20:38: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 UAA09085 for ; Tue, 19 Jun 2001 20:38:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA18278; Tue, 19 Jun 2001 20:37:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA18243 for ; Tue, 19 Jun 2001 20:37:53 -0400 (EDT) Received: from web13801.mail.yahoo.com (web13801.mail.yahoo.com [216.136.175.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09064 for ; Tue, 19 Jun 2001 20:37:16 -0400 (EDT) Message-ID: <20010620003751.86999.qmail@web13801.mail.yahoo.com> Received: from [65.12.33.187] by web13801.mail.yahoo.com; Tue, 19 Jun 2001 17:37:51 PDT Date: Tue, 19 Jun 2001 17:37:51 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 To: midcom@ietf.org In-Reply-To: <200106192330.TAA20063@astro.cs.utk.edu> 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 I do agree with Randy about using simple unambiguous words. But, we cannot always go by the dictionary definition for terms. When technology defines a term or has used the term in a certain way, we ought to be using the technology definition, not the dictionary defn. Contrasting with the dictionary defn and redefining it to match the dictionary definition simply creates confusion. Expressly prohibiting the use in a proper context tantamounts to censoring it. Perhaps the terms "transparent" and "opaque" fall under this category. The term "transparent" has been, I believe, used for the longest time to mean "not noticeable" to the end-hosts that take part in an application. And, the opposite for the term "opaque". Even if you think, this is oxymorinish, the meanings have been used consitently in many previously published work from IETF and other standards bodies as Andrew points out. If we create a new defn now, all the previous work become inconsitent. Oh, well, thats all from me on this thread for today. Thanks. Have a nice day. regards, suresh --- Keith Moore wrote: > > "transparent firewall" is a fairly well defined widget, for example > > sounds like an oxymoron to me. > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ===== __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 21:53: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 VAA11067 for ; Tue, 19 Jun 2001 21:53:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20353; Tue, 19 Jun 2001 21:51:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20323 for ; Tue, 19 Jun 2001 21:51:18 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11031 for ; Tue, 19 Jun 2001 21:50:41 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA21088; Tue, 19 Jun 2001 21:51:15 -0400 (EDT) Message-Id: <200106200151.VAA21088@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pyda Srisuresh cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Tue, 19 Jun 2001 17:37:51 PDT." <20010620003751.86999.qmail@web13801.mail.yahoo.com> Date: Tue, 19 Jun 2001 21:51:15 -0400 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 > The term "transparent" has been, I believe, used for the longest time > to mean "not noticeable" to the end-hosts that take part in an > application. the more precise meaning of "doesn't corrupt the data" is far more common. "not noticable" doesn't apply to so-called transparent proxies, for instance. nor does it apply to so-called "transparent firewalls". _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 19 23:19: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 XAA13115 for ; Tue, 19 Jun 2001 23:19:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22905; Tue, 19 Jun 2001 23:18:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22873 for ; Tue, 19 Jun 2001 23:18:36 -0400 (EDT) Received: from zsc3s002.nortelnetworks.com (h86s136a81n47.user.nortelnetworks.com [47.81.136.86]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13105 for ; Tue, 19 Jun 2001 23:18:00 -0400 (EDT) Received: from smtprch1.nortel.com by zsc3s002.nortelnetworks.com (SMI-8.6/SMI-SVR4) id TAA05902; Tue, 19 Jun 2001 19:48:29 -0700 Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 19 Jun 2001 22:18:00 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 22:18:01 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BBFB3@crchy271.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom Subject: RE: [midcom] Straw poll - out-of-path midcom agents Date: Tue, 19 Jun 2001 22:17:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F937.9BBAC500" 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_001_01C0F937.9BBAC500 Content-Type: text/plain; charset="iso-8859-1" My vote will be a NO for OOP MA at this stage. I'm not sure I clearly see the impact of this "datagram diversion" function on the MIDCOM protocol as this can be configured as a routing policy on the Middlebox. Apart from this, how's the control of the Middlebox any different between the IP and OOP MA's? I agree with Scott that this can be added later, if deem required. Sanjoy -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, June 19, 2001 1:15 PM To: midcom Subject: [midcom] Straw poll - out-of-path midcom agents We've been going around and around on out-of-path agents since the first draft of the document and it's my sense that we're failing to make progress on it. I'd like to take a straw poll to see how much support there is for including support for diversion to out-of-path agents. Please indicate to the mailing list whether or not you'd like us to include consideration of out-of-path agents. Be prepared to defend your position :-). Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0F937.9BBAC500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Straw poll - out-of-path midcom agents

My vote will be a NO for OOP MA at this stage. I'm = not sure I clearly see the impact of this "datagram = diversion" function on the MIDCOM protocol as this can be = configured as a routing policy on the Middlebox. Apart from this, how's = the control of the Middlebox any different between the IP and OOP MA's? = I agree with Scott that this can be added later, if deem = required.

Sanjoy

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Tuesday, June 19, 2001 1:15 PM
To: midcom
Subject: [midcom] Straw poll - out-of-path midcom = agents


We've been going around and around on out-of-path = agents
since the first draft of the document and it's my = sense
that we're failing to make progress on it.  I'd = like to
take a straw poll to see how much support there is = for
including support for diversion to out-of-path = agents. 
Please indicate to the mailing list whether or not = you'd
like us to include consideration of out-of-path = agents.
Be prepared to defend your position :-).

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C0F937.9BBAC500-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 01:20: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 BAA15544 for ; Wed, 20 Jun 2001 01:20:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02697; Wed, 20 Jun 2001 01:12:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02639 for ; Wed, 20 Jun 2001 01:12:02 -0400 (EDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14980 for ; Wed, 20 Jun 2001 01:11:26 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CaHW-000GiD-00; Tue, 19 Jun 2001 22:11:58 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pyda Srisuresh Cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 References: <200106192330.TAA20063@astro.cs.utk.edu> <20010620003751.86999.qmail@web13801.mail.yahoo.com> Message-Id: Date: Tue, 19 Jun 2001 22:11:58 -0700 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 > The term "transparent" has been, I believe, used for the longest time > to mean "not noticeable" to the end-hosts that take part in an > application. i think that's the problem. it seems to have been also used to mean "we wish it was not noticeable but it really was and the marketing folk told us to use the term anyway." i can see uses for in-path boxen that do modify data or behavior. and that is, i believe, the very charter of this group. but, as this is the ietf, not the imtf, it would behoove us to be as accurate as possible. randy _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 01:29:41 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 BAA16190 for ; Wed, 20 Jun 2001 01:29:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA03922; Wed, 20 Jun 2001 01:27:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA03891 for ; Wed, 20 Jun 2001 01:27:12 -0400 (EDT) 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 BAA15995 for ; Wed, 20 Jun 2001 01:26:36 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id E37F481EE for ; Wed, 20 Jun 2001 00:27:11 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id AAA08283 for ; Wed, 20 Jun 2001 00:27:11 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Wed, 20 Jun 2001 00:27:11 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 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 Tue, 19 Jun 2001, Randy Bush wrote: > > The term "transparent" has been, I believe, used for the longest time > > to mean "not noticeable" to the end-hosts that take part in an > > application. > > i think that's the problem. it seems to have been also used to mean "we > wish it was not noticeable but it really was and the marketing folk told > us to use the term anyway." > > i can see uses for in-path boxen that do modify data or behavior. and > that is, i believe, the very charter of this group. but, as this is the > ietf, not the imtf, it would behoove us to be as accurate as possible. We could invent some new terms, without any baggage, and define them carefully. For example, we could use the word 'Agent' to mean some entity which examines network data and makes policy decisions which it implements via MIDCOM on behalf of other network entities. We can assume, reasonably I think, that the network data examined by the Agents to be some sort of protocol data passing between Applications, and that the policy to be implemented in the middleboxes is to be implemented on behalf of these Applications. If it becomes useful to distinguish between those Agents which get a chance to look at this protocol data by explicitly taking part in the protocol (with whatever Application configuration that implies) and those which get the chance by other means, we would need terms to distinguish between these two types of Agents. Rather than the loaded terms 'non-transparent' and 'transparent' I propose we use the terms 'In-Path' and 'Out-of-Path' respectively. More seriously, perhaps we should suppress this distinction, but raise the notion of Packet Diversion up to a core thing that MIDCOM needs to deal with, in parallel with NAT and Firewalling? Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 09:09: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 JAA05916 for ; Wed, 20 Jun 2001 09:09:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17871; Wed, 20 Jun 2001 09:00:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17791 for ; Wed, 20 Jun 2001 09:00:04 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05554 for ; Wed, 20 Jun 2001 08:59:23 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01725 for ; Wed, 20 Jun 2001 08:59:10 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01716 for ; Wed, 20 Jun 2001 08:59:10 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F988.ED55C0E4" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [midcom] Straw poll - out-of-path midcom agents Date: Wed, 20 Jun 2001 07:00:05 -0600 Message-ID: Thread-Topic: [midcom] Straw poll - out-of-path midcom agents Thread-Index: AcD47X7PI8I/zJ5wSh6LGrZRwx1+2QAmen8Q From: "Zmolek, Andrew (Andrew)" To: "Melinda Shore" , 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 multi-part message in MIME format. ------_=_NextPart_001_01C0F988.ED55C0E4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My vote: include support. OOP agents are likely to proliferate without regard to work done in this group and while an argument can be made that they can be ignored and still implement midcom, I'd prefer to see better consideration of them in our scenarios and discussion moving forward. In spite of the fact that OOP agents will create new security nightmares, I would much rather see us tackling this as part of a more complete solution. Forcing vendor competing vendor extensions to decide this issue might further delay acceptance of midcom in the industry in general. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, June 19, 2001 12:15 PM To: midcom@ietf.org Subject: [midcom] Straw poll - out-of-path midcom agents We've been going around and around on out-of-path agents since the first draft of the document and it's my sense that we're failing to make progress on it. I'd like to take a straw poll to see how much support there is for including support for diversion to out-of-path agents. =20 Please indicate to the mailing list whether or not you'd like us to include consideration of out-of-path agents. Be prepared to defend your position :-). Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0F988.ED55C0E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Straw poll - out-of-path midcom agents

My vote: include support. OOP agents are likely to = proliferate without regard to work done in this group and while an = argument can be made that they can be ignored and still implement = midcom, I'd prefer to see better consideration of them in our scenarios = and discussion moving forward.

In spite of the fact that OOP agents will create new = security nightmares, I would much rather see us tackling this as part of = a more complete solution. Forcing vendor competing vendor extensions to = decide this issue might further delay acceptance of midcom in the = industry in general.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Tuesday, June 19, 2001 12:15 PM
To: midcom@ietf.org
Subject: [midcom] Straw poll - out-of-path midcom = agents


We've been going around and around on out-of-path = agents
since the first draft of the document and it's my = sense
that we're failing to make progress on it.  I'd = like to
take a straw poll to see how much support there is = for
including support for diversion to out-of-path = agents. 
Please indicate to the mailing list whether or not = you'd
like us to include consideration of out-of-path = agents.
Be prepared to defend your position :-).

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/= mailman/listinfo/midcom

------_=_NextPart_001_01C0F988.ED55C0E4-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 09:22:18 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 JAA06296 for ; Wed, 20 Jun 2001 09:22:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18768; Wed, 20 Jun 2001 09:22:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18739 for ; Wed, 20 Jun 2001 09:21:58 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06237 for ; Wed, 20 Jun 2001 09:21:22 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A2FF1C00250; Wed, 20 Jun 2001 09:19:59 -0400 Message-ID: <006f01c0f98b$d0a330a0$2300000a@acmepacket.com> From: "Bob Penfield" To: References: <00f701c0f8eb$b83ecba0$d45904d1@cisco.com> Subject: Re: [midcom] Straw poll - out-of-path midcom agents Date: Wed, 20 Jun 2001 09:20:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 I believe the idea of diverting packets to so called OOP agents needs to be included in the framework. However, I don't see the need to explicitly identify them as OOP in the MIDCOM protocol. I see diversion as just another service that the middlebox provides (like NAT & firewall). Being a SIPer, I can see this being very useful in the following scenario: I have this big expensive SIP server that cannot talk MIDCOM and a middlebox that does NAT and can talk MIDCOM. I want to add on this little inexpensive MIDCOM Agent box that will "snoop" the SIP traffic, set up NATs in the middlebox for the RTP/RTCP and modify the IP addresses in the SIP headers and the SDP based on those NATs. This MIDCOM agent would ask the middlebox to "divert" the SIP flow to itself via an IP tunnel (or whatever). The RTP/RTCP flows are NATed just like with in-path agents. Certainly defining the specific mechanisms for diversion are outside the scope of the WG. However, MIDCOM should support any existing standard mechanisms (if there are any). I agree that keeping these things secure is a harder problem than with in-path agents, but that doesn't mean we should not include it. I agree with the esteemed Dr. Molitor that OOP agents may outnumber in-path agents at least in initial deployments until the various types of applications become MIDCOM enabled. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Melinda Shore" To: Sent: Tuesday, June 19, 2001 2:14 PM Subject: [midcom] Straw poll - out-of-path midcom agents > We've been going around and around on out-of-path agents > since the first draft of the document and it's my sense > that we're failing to make progress on it. I'd like to > take a straw poll to see how much support there is for > including support for diversion to out-of-path agents. > Please indicate to the mailing list whether or not you'd > like us to include consideration of out-of-path agents. > Be prepared to defend your position :-). > > 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 Jun 20 09:30:12 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 JAA06608 for ; Wed, 20 Jun 2001 09:30:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18967; Wed, 20 Jun 2001 09:28:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18936 for ; Wed, 20 Jun 2001 09:28:55 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06511 for ; Wed, 20 Jun 2001 09:28:18 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5KDSCr02240 for ; Wed, 20 Jun 2001 09:28:12 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5KDSBt02222 for ; Wed, 20 Jun 2001 09:28:11 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F98C.F73BC140" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [midcom] Straw poll - out-of-path midcom agents Date: Wed, 20 Jun 2001 07:29:00 -0600 Message-ID: Thread-Topic: [midcom] Straw poll - out-of-path midcom agents Thread-Index: AcD468x91m2YUir4QM2xXxe4rTbRQgAByoxgACZE52A= From: "Zmolek, Andrew (Andrew)" To: "Christian Huitema" , "Melinda Shore" , 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 multi-part message in MIME format. ------_=_NextPart_001_01C0F98C.F73BC140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable By the time midcom is implementable, the notion of firewall traversal is unlikely (for enterprises anyway) to refer to passage across a single device now known as a firewall. If there is something wrong with this group's efforts to date, it may well be found in the simplistic perimeter view taken by our scenarios as now written. Frankly the value of midcom is found in enabling what might be termed a decomposed firewall architecture. The OOP issue gets to the heart of this and if we're not going to tackle this in midcom then those of us who are expecting that solution will be forced to look elsewhere. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Tuesday, June 19, 2001 1:08 PM To: Melinda Shore; midcom@ietf.org Subject: RE: [midcom] Straw poll - out-of-path midcom agents I do not believe that we should provide support for out of path agent. The group should focus on solving the problems exposed in the scenarios draft, none of which involves out of path agents. The debate on OOP is, IMHO, typical of what is wrong with this group. Instead of solving the very simple problem of firewall traversal and actually enabling communication, the group is trying to invent all kinds of "transformers" that could be placed at arbitrary places in the network. We should cut that and focus. -- Christian Huitema > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, June 19, 2001 11:15 AM > To: midcom@ietf.org > Subject: [midcom] Straw poll - out-of-path midcom agents >=20 > We've been going around and around on out-of-path agents > since the first draft of the document and it's my sense > that we're failing to make progress on it. I'd like to > take a straw poll to see how much support there is for > including support for diversion to out-of-path agents. > Please indicate to the mailing list whether or not you'd > like us to include consideration of out-of-path agents. > Be prepared to defend your position :-). >=20 > Melinda >=20 >=20 >=20 > _______________________________________________ > 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 ------_=_NextPart_001_01C0F98C.F73BC140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Straw poll - out-of-path midcom agents

By the time midcom is implementable, the notion of = firewall traversal is unlikely (for enterprises anyway) to refer to = passage across a single device now known as a firewall. If there is = something wrong with this group's efforts to date, it may well be found = in the simplistic perimeter view taken by our scenarios as now = written.

Frankly the value of midcom is found in enabling what = might be termed a decomposed firewall architecture. The OOP issue gets = to the heart of this and if we're not going to tackle this in midcom = then those of us who are expecting that solution will be forced to look = elsewhere.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.micr= osoft.com]
Sent: Tuesday, June 19, 2001 1:08 PM
To: Melinda Shore; midcom@ietf.org
Subject: RE: [midcom] Straw poll - out-of-path midcom = agents


I do not believe that we should provide support for = out of path agent.
The group should focus on solving the problems = exposed in the scenarios
draft, none of which involves out of path = agents.

The debate on OOP is, IMHO, typical of what is wrong = with this group.
Instead of solving the very simple problem of = firewall traversal and
actually enabling communication, the group is trying = to invent all kinds
of "transformers" that could be placed at = arbitrary places in the
network. We should cut that and focus.

-- Christian Huitema

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, June 19, 2001 11:15 AM
> To: midcom@ietf.org
> Subject: [midcom] Straw poll - out-of-path = midcom agents
>
> We've been going around and around on = out-of-path agents
> since the first draft of the document and it's = my sense
> that we're failing to make progress on it.  = I'd like to
> take a straw poll to see how much support there = is for
> including support for diversion to out-of-path = agents.
> Please indicate to the mailing list whether or = not you'd
> like us to include consideration of out-of-path = agents.
> Be prepared to defend your position :-).
>
> 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

------_=_NextPart_001_01C0F98C.F73BC140-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 10:00: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 KAA07817 for ; Wed, 20 Jun 2001 10:00:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20132; Wed, 20 Jun 2001 09:54:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20068 for ; Wed, 20 Jun 2001 09:54:32 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07638 for ; Wed, 20 Jun 2001 09:53:54 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24634 for ; Wed, 20 Jun 2001 09:53:39 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24620 for ; Wed, 20 Jun 2001 09:53:39 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F990.89E041DA" Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 20 Jun 2001 07:54:35 -0600 Message-ID: Thread-Topic: [midcom] Out-of-Path Midcom Agents in framework-02 Thread-Index: AcD4/A4ywt53EBj8RiiX5LulfuAoNQAkc2RA From: "Zmolek, Andrew (Andrew)" To: "Pyda Srisuresh" , "Brian E Carpenter" Cc: "Melinda Shore" , "Fleischman, Eric W" , "Andrew Molitor" , 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 multi-part message in MIME format. ------_=_NextPart_001_01C0F990.89E041DA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the interest of finding more acceptable terms for what these middleboxes are doing, how about: "stealth"=20 ...as in "stealthy packet forwarding" done by ALG and NAT middleboxes (who don't always route in the traditional sense). The term "transparent routing" below isn't at all clear: It can be argued that routing does not always occur at a NAT device. And the idea of "end-to-end transparency" is debatable. If anything, ALG+NAT provides a degree of transparency and typically compatibility across IP realms. So maybe we want to be talking more about what's actually going on here:=20 "IP address realm traversal" which is what the NAT box is doing at a low level and the ALG is doing at the application protocol level.=20 --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] Sent: Tuesday, June 19, 2001 2:12 PM To: Brian E Carpenter; Zmolek, Andrew (Andrew) Cc: Melinda Shore; Pyda Srisuresh; Fleischman, Eric W; Andrew Molitor; midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 I did a grep on the terms "Transparent" and "transparency" to see=20 where and how they are used in the FW document. Below is a list of=20 my findings and sugegsted remedies. I believe, it is OK to use terms like "end-to-end transparency" (item 1 below) and "Transparent routing" (item 3 below). They have a specific=20 meaning that goes with them. But, as Brian pointed out, it is tricky to use these temrs in the=20 context of proxies, ALGs, agents and the like. 1. Paragraph 1 of section 1 - Introduction "Application Level gateways (ALGs) are used in conjunction with NAT to provide end-to-end transparency for many of the applications." I think, it should be OK to leave this unchanged. 2. Paragraph 3 of Section 1 - Introduction "The communication between a MIDCOM agent and a middlebox will be transparent to the end-hosts that take part in the application, unless one of the end-hosts assumes the role of a MIDCOM agent." =20 I could reword this as follows: "The communication between a MIDCOM agent and a middlebox will not be noticeable to the end-hosts that take part in the application, unless one of the end-hosts assumes the role of a MIDCOM agent." 3. Sectin 2.4. - NAT "Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end-hosts." This definition is settled after a long series of discussion=20 prior to advancing RFC 2663. The definition is carried as is=20 from RFC 2663. I donot recommend changing this. =20 4. Paragraph 3 of section 2.6 - ALG "ALGs are different from proxies. ALGs are transparent to=20 end-hosts, unlike the proxies which are relay agents terminating sessions with both end-hosts." I could rephrase the above as follows: "ALGs are different from proxies. ALGs are not visible to=20 end-hosts, unlike the proxies which are relay agents terminating sessions with both end-hosts." 5. Paragraph 3 of section 5.2. - OOP MIDCOM agents "In essence, a middlebox provides to an Out-of-Path MIDCOM agent the ability to transparently "snoop" and modify the control traffic." I can reword the above as follows. "In essence, a middlebox provides to an Out-of-Path MIDCOM agent the same priveleges as that of an In-Path agent, to application control traffic, to "snoop" and modify as deemed appropriate." 6. The legend in figure 5 for "Ctrl" is described as follows. "Ctrl - indicates the FTP control traffic, which is transparently diverted to the OOP agent (2 and 3)" I can remove the word, and yet not change the semantics here.=20 Thanks.=20 regards, suresh --- Brian E Carpenter wrote: > I think the word "transparent" has too many interpretations > and too much history of abuse (as in "transparent proxy") to be a > useful word in this context. I think we should simply not use > the words "transparent" or "transparency" at all. >=20 > Brian >=20 > > "Zmolek, Andrew (Andrew)" wrote: > >=20 > > It seems that we've been debating the meaning of transparency for some time > now. Perhaps we are talking about different shades > > of transparency, and if that really does matter than we need to elaborate. > >=20 > > - Transparency at an application layer so that client and server both have > a rational conversation is probably what we're > > aiming for when we talk about OOP agent transparency. Some OOP agents still > manage to mangle things here, but the aim is still > > transparency. > >=20 > > - Transparency at the transport layer is something else. Many OOP agents > will have to interact with the underlying transport > > infrastructure to deal with packet forwarding, route information, address > and port assignment details, etc. So transparency is > > a harder sell here. > >=20 > > Is it possible we can find enough middle ground in this decomposition of > the word "transparent" that we can move on? > >=20 > > --Andy Zmolek > > Technology & Standards Engineer > > CTO Standards > > Avaya Inc. > >=20 > > zmolek@avaya.com > > +1 720 444 4001 > >=20 > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Tuesday, June 19, 2001 11:44 AM > > To: Pyda Srisuresh; Fleischman, Eric W; 'Andrew Molitor'; > > midcom@ietf.org > > Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 > >=20 > > > OOP agent are not visible to end-hosts. So, an OOP agent is transparent. > >=20 > > I wouldn't agree that one follows from the other. > > If the out-of-path agent effects a change in the behavior > > of the data/application/what-have-you, it's not transparent. > >=20 > > Melinda > >=20 > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ ------_=_NextPart_001_01C0F990.89E041DA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Out-of-Path Midcom Agents in framework-02

In the interest of finding more acceptable terms for = what these middleboxes are doing, how about:

  "stealth"

...as in "stealthy packet forwarding" done = by ALG and NAT middleboxes (who don't always route in the traditional = sense). The term "transparent routing" below isn't at all = clear: It can be argued that routing does not always occur at a NAT = device.

And the idea of "end-to-end transparency" is = debatable. If anything, ALG+NAT provides a degree of transparency and = typically compatibility across IP realms. So maybe we want to be talking = more about what's actually going on here:

  "IP address realm traversal"

which is what the NAT box is doing at a low level and = the ALG is doing at the application protocol level.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001



-----Original Message-----
From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]
Sent: Tuesday, June 19, 2001 2:12 PM
To: Brian E Carpenter; Zmolek, Andrew (Andrew)
Cc: Melinda Shore; Pyda Srisuresh; Fleischman, Eric = W; Andrew Molitor;
midcom@ietf.org
Subject: Re: [midcom] Out-of-Path Midcom Agents in = framework-02



I did a grep on the terms "Transparent" and = "transparency" to see
where and how they are used in the FW document. Below = is a list of
my findings and sugegsted remedies.

I believe, it is OK to use terms like "end-to-end = transparency" (item 1
below) and "Transparent routing" (item 3 = below). They have a specific
meaning that goes with them.

But, as Brian pointed out, it is tricky to use these = temrs in the
context of proxies, ALGs, agents and the like.

1. Paragraph 1 of section 1 - Introduction

   "Application Level gateways (ALGs) = are used in conjunction with NAT
    to provide end-to-end transparency = for many of the applications."

   I think, it should be OK to leave this = unchanged.

2. Paragraph 3 of Section 1 - Introduction

   "The communication between a MIDCOM = agent and a middlebox will be
    transparent to the end-hosts that = take part in the application,
    unless one of the end-hosts = assumes the role of a MIDCOM agent."
 
   I could reword this as follows:

   "The communication between a MIDCOM = agent and a middlebox will
    not be noticeable to the end-hosts = that take part in the application,
    unless one of the end-hosts = assumes the role of a MIDCOM agent."

3. Sectin 2.4. - NAT

   "Network Address Translation is a = method by which IP addresses are
    mapped from one address realm to = another, providing transparent
    routing to end-hosts."

   This definition is settled after a long = series of discussion
   prior to advancing RFC 2663. The = definition is carried as is
   from RFC 2663. I donot recommend = changing this.
 
4. Paragraph 3 of section 2.6 - ALG

   "ALGs are different from proxies. = ALGs are transparent to
   end-hosts, unlike the proxies which are = relay agents terminating
   sessions with both = end-hosts."

   I could rephrase the above as = follows:

   "ALGs are different from proxies. = ALGs are not visible to
   end-hosts, unlike the proxies which are = relay agents terminating
   sessions with both = end-hosts."

5. Paragraph 3 of section 5.2. - OOP MIDCOM = agents

   "In essence, a middlebox provides to = an Out-of-Path MIDCOM agent
    the ability to transparently = "snoop" and modify the control
    traffic."

   I can reword the above as follows.

   "In essence, a middlebox provides to = an Out-of-Path MIDCOM agent
    the same priveleges as that of an = In-Path agent, to application
    control traffic, to = "snoop" and modify as deemed appropriate."

6. The legend in figure 5 for "Ctrl" is = described as follows.
   "Ctrl - indicates the FTP control = traffic, which
           is = transparently diverted to the OOP agent (2 and 3)"

   I can remove the word, and yet not change = the semantics here.

Thanks.

regards,
suresh


--- Brian E Carpenter <brian@hursley.ibm.com> = wrote:
> I think the word "transparent" has too = many interpretations
> and too much history of abuse (as in = "transparent proxy") to be a
> useful word in this context. I think we should = simply not use
> the words "transparent" or = "transparency" at all.
>
>   Brian
>
> > "Zmolek, Andrew (Andrew)" = wrote:
> >
> > It seems that we've been debating the = meaning of transparency for some time
> now. Perhaps we are talking about different = shades
> > of transparency, and if that really does = matter than we need to elaborate.
> >
> > - Transparency at an application layer so = that client and server both have
> a rational conversation is probably what = we're
> > aiming for when we talk about OOP agent = transparency. Some OOP agents still
> manage to mangle things here, but the aim is = still
> > transparency.
> >
> > - Transparency at the transport layer is = something else. Many OOP agents
> will have to interact with the underlying = transport
> > infrastructure to deal with packet = forwarding, route information, address
> and port assignment details, etc. So = transparency is
> > a harder sell here.
> >
> > Is it possible we can find enough middle = ground in this decomposition of
> the word "transparent" that we can = move on?
> >
> > --Andy Zmolek
> >     Technology & = Standards Engineer
> >       CTO = Standards
> = >         Avaya Inc.
> >
> = >           &nb= sp; zmolek@avaya.com
> = >           &nb= sp;   +1 720 444 4001
> >
> > -----Original Message-----
> > From: Melinda Shore [mailto:mshore@cisco.com]
> > Sent: Tuesday, June 19, 2001 11:44 = AM
> > To: Pyda Srisuresh; Fleischman, Eric W; = 'Andrew Molitor';
> > midcom@ietf.org
> > Subject: Re: [midcom] Out-of-Path Midcom = Agents in framework-02
> >
> > > OOP agent are not visible to = end-hosts. So, an OOP agent is transparent.
> >
> > I wouldn't agree that one follows from the = other.
> > If the out-of-path agent effects a change = in the behavior
> > of the data/application/what-have-you, it's = not transparent.
> >
> > 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


__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and = more.
http://buzz.yahoo.com/

------_=_NextPart_001_01C0F990.89E041DA-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 10:02:54 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 KAA07907 for ; Wed, 20 Jun 2001 10:02:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20594; Wed, 20 Jun 2001 10:01:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20556 for ; Wed, 20 Jun 2001 10:01:09 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07840 for ; Wed, 20 Jun 2001 10:00:26 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5KE0D020473 for ; Wed, 20 Jun 2001 10:00:13 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Wed, 20 Jun 2001 10:00:05 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 10:00:05 -0400 Message-ID: From: "Fernando Cuervo" To: midcom Subject: RE: [midcom] Straw poll - out-of-path midcom agents Date: Wed, 20 Jun 2001 10:00:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F991.4D62D230" X-Orig: 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_001_01C0F991.4D62D230 Content-Type: text/plain OOPs in the framework: NO Are OOPs useful: yes So why not? 1-this is not in the "focus" areas of Midcom (see charter) 2-a timely outcome would be less likely to occur since reusability of existing protocols would be more difficult with all the baggage of OOPs 3-the description in section 5.2 of the framework document is trying to specify the functionality of the middlebox to support OOPs not the interoperability aspects 4-the WG is NOT dealing with discovery, I believe OOPs are an essential component of discovery, therefore the WG shall not get into areas that is not willing to address. Fernando Cuervo > -----Original Message----- > From: Melinda Shore [SMTP:mshore@cisco.com] > Sent: Tuesday, June 19, 2001 2:15 PM > To: midcom > Subject: [midcom] Straw poll - out-of-path midcom agents > > We've been going around and around on out-of-path agents > since the first draft of the document and it's my sense > that we're failing to make progress on it. I'd like to > take a straw poll to see how much support there is for > including support for diversion to out-of-path agents. > Please indicate to the mailing list whether or not you'd > like us to include consideration of out-of-path agents. > Be prepared to defend your position :-). > > Melinda > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0F991.4D62D230 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Straw poll - out-of-path midcom agents

OOPs in the = framework: NO
Are OOPs useful: = yes
So why not?
1-this is not in = the "focus" areas of Midcom (see charter)
2-a timely outcome = would be less likely to occur since reusability of existing protocols = would
   be = more difficult with all the baggage of OOPs
3-the description = in section 5.2 of the framework document is trying to specify the = functionality of
  the = middlebox to support OOPs not the interoperability aspects
4-the WG is NOT = dealing with discovery, I believe OOPs are an essential component of = discovery,
  therefore = the WG shall not get into areas that is not willing to address.

Fernando = Cuervo

    -----Original Message-----
    From:   Melinda Shore [SMTP:mshore@cisco.com]
    Sent:   Tuesday, June 19, 2001 2:15 PM
    To:     midcom
    Subject:       = [midcom] Straw poll - out-of-path = midcom agents

    We've been going around and around on = out-of-path agents
    since the first draft of the document = and it's my sense
    that we're failing to make progress = on it.  I'd like to
    take a straw poll to see how much = support there is for
    including support for diversion to = out-of-path agents. 
    Please indicate to the mailing list = whether or not you'd
    like us to include consideration of = out-of-path agents.
    Be prepared to defend your position = :-).

    Melinda



    _______________________________________________
    midcom mailing list
    midcom@ietf.org
    http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C0F991.4D62D230-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 10:39:26 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 KAA09373 for ; Wed, 20 Jun 2001 10:39:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21858; Wed, 20 Jun 2001 10:35:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21824 for ; Wed, 20 Jun 2001 10:35:12 -0400 (EDT) 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 KAA09226 for ; Wed, 20 Jun 2001 10:34:33 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5KEX1H00486; Wed, 20 Jun 2001 07:33:02 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-1.cisco.com [10.21.112.1]) by airborne.cisco.com (Mirapoint) with ESMTP id ADW04596; Wed, 20 Jun 2001 07:34:36 -0700 (PDT) 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: <15152.46202.192000.241750@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 10:34:34 -0400 To: Andrew Molitor Cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-Reply-To: References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12D9D@XCH-NW-01.nw.nos.boeing.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 18 Jun 2001 at 12:43 -0500, Andrew Molitor apparently wrote: > I find this puzzling. To my way of thinking, an OOP agent > is (or is very close to) a pretty ordinary transparent application > layer gateway that's been taught how to talk to a middlebox to > fast-path traffic. In In-Path agent is a non-transparent application > layer gateway with the same teaching. > > Are you claiming that a transparent ALG is in some way > easier to fool/spoof/hack than a non-transparent one? It's precisely because it's potentially application-layer transparent (although I suspect it won't be in many cases) that it's more vulnerable. Who will be checking the validity of its actions? The endpoints don't know about it explicitly. The middlebox just does what it's told. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 10:39:28 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 KAA09384 for ; Wed, 20 Jun 2001 10:39:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21759; Wed, 20 Jun 2001 10:33:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21730 for ; Wed, 20 Jun 2001 10:33:21 -0400 (EDT) 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 KAA09025 for ; Wed, 20 Jun 2001 10:32:43 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5KEWuN12038; Wed, 20 Jun 2001 07:32:56 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-1.cisco.com [10.21.112.1]) by airborne.cisco.com (Mirapoint) with ESMTP id ADW04584; Wed, 20 Jun 2001 07:32:46 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" Message-ID: <15152.46089.831000.711706@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 10:32:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Zmolek, Andrew (Andrew)" Cc: "Pyda Srisuresh" , "Brian E Carpenter" , "Melinda Shore" , "Fleischman, Eric W" , "Andrew Molitor" , Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 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 20 Jun 2001 at 07:54 -0600, Zmolek, Andrew (Andrew) apparently wrote: > In the interest of finding more acceptable terms for what these > middleboxes are doing, how about: > > "stealth" :-) "Interception" has far fewer connotations. > ...as in "stealthy packet forwarding" done by ALG and NAT middleboxes > (who don't always route in the traditional sense). The term "transparent > routing" below isn't at all clear: It can be argued that routing does > not always occur at a NAT device. Right. People aren't distinguishing routing from forwarding (we may never be able to get them to do it again). > And the idea of "end-to-end transparency" is debatable. If anything, > ALG+NAT provides a degree of transparency and typically compatibility > across IP realms. So maybe we want to be talking more about what's > actually going on here: > > "IP address realm traversal" > > which is what the NAT box is doing at a low level and the ALG is doing > at the application protocol level. Transparency is a layer-specific issue. Application-level gateways can be "transparent" -- in the strict sense -- to the application if the payload is delivered faithfully, but they certainly aren't transparent at the network layer. I like Randy's strict meaning of transparency as long as the test is targeted at a specific layer. We have to have strictness in our use of terms or we'll have to find new ones in a year. The term "transparent routing" thus would mean that "routing" (really forwarding), an IP layer function, is done without modification to the PDUs of that layer, i.e. packets. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 11:15: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 LAA10463 for ; Wed, 20 Jun 2001 11:15:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23332; Wed, 20 Jun 2001 11:15:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23304 for ; Wed, 20 Jun 2001 11:15:20 -0400 (EDT) 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 LAA10439 for ; Wed, 20 Jun 2001 11:14:43 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5KFEvN08507; Wed, 20 Jun 2001 08:14:57 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-1.cisco.com [10.21.112.1]) by airborne.cisco.com (Mirapoint) with ESMTP id ADW05012; Wed, 20 Jun 2001 08:14:47 -0700 (PDT) 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: <15152.48613.119000.959971@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 11:14:45 -0400 To: Andrew Molitor Cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 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 20 Jun 2001 at 00:27 -0500, Andrew Molitor apparently wrote: > Rather than the loaded terms 'non-transparent' and 'transparent' I > propose we use the terms 'In-Path' and 'Out-of-Path' respectively. Nice try, but OPES (for example) is working with out-of-path non-transparent functions. Also, the way we use 'transparent' should be generally applicable throughout the IETF. Again I like Randy's approach, along with awareness that transparency is a per-layer issue. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 11:26: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 LAA11007 for ; Wed, 20 Jun 2001 11:26:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22229; Wed, 20 Jun 2001 10:47:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22196 for ; Wed, 20 Jun 2001 10:47:46 -0400 (EDT) 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 KAA09652 for ; Wed, 20 Jun 2001 10:47:08 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5KEijH06065; Wed, 20 Jun 2001 07:45:37 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-1.cisco.com [10.21.112.1]) by airborne.cisco.com (Mirapoint) with ESMTP id ADW04731; Wed, 20 Jun 2001 07:46:19 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" Message-ID: <15152.46904.883000.331503@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 10:46:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Russell Daigle" Cc: "'midcom@ietf.org'" Subject: Re: [midcom] Framework draft -01 comments 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 18 Jun 2001 at 16:33 -0700, Russell Daigle apparently wrote: > 1) Section 2.8: "MIDCOM agents possess a combination of application > awareness and knowledge of the middlebox function." It shouldn't be > necessary that the agent knows the middlebox function. While there are > situations where it is advantageous (ie, when the agent itself will perform > the NAT manipulations of the stream), it definitely should not be a > requirement. I'd like to see some generic APIs that can abstract this > away; for example the midbox may just want to know about dynamic ports > associated with the conversation. I presume this was intended, but it's > not clear from the text, and it is important enough to be mentioned > explicitly. In general, this helps achieve extensibility in what I expect > will be a common situation where the midbox wants to maintain the "middlebox > function" without explicit knowledge of lots of applications. I believe this is exactly what was intended, and that if there's a problem it's just wording. I suspect (Suresh?) that "knowledge of the middlebox function" does not mean that agents are able to function as middleboxes, but rather that agents are designed with explicit awareness that middleboxes exist, and how to talk to them. We are working on an API, it's called the midcom protocol. > > > 2) Section 5.2, Page 12, point #3: "Note the middlebox will not subject the > datagram to any of the middlebox services this time around." This statement > indicates that when the out-of-path agent forwards the processed packet back > to the middlebox, the middlebox won't pass this packet through any more > services. This is completely untrue: there are situations where > additional services are required after the packet has been processed by the > middlebox. This has many implications.... but the salient point here is > that the architecture/protocol must not preclude this from happening. This > should be mentioned explicitly. > > One implication is that such situations that have this requirement will not > be able to use in-path agents since the packet must be forwarded back to the > middlebox. > > I know the remaining implications are protocol-related, so don't flame me. > :) Just ignore them if you want. I thought they were interesting enough to > note.... and I'll be mentioning them again later if the protocol-spec > doesn't have provisions for them. > > Another implication is that there needs to be some sort of mechanism where > an out-of-path agent can be configured to return [on a per-connection > basis?] packets to the middlebox for further processing. Presumably, this > would be upon establishing the midcom protocol between a midbox and agent. > (This statement is also related to section 9.4: "The agents should be > capable of returning the processed traffic to the middlebox point of > origin..."; this requirement should be configurable.) > > Then there are strict ordering requirements between messages exchanged via > the midcom protocol and packets forwarded back to the midbox from the agent. > This may be particularly cumbersome if the midcom protocol messages and > actual user data-packets are sent via distinct virtual channels (ie, > different L4/7 connections). This point may argue for having the user > data-packets tunnelled in the same connection as midcom protocol message are > sent via. There are also additional reasons for tunnelling of user > data-packets which will be described later. > > In addition, there should be some sort of "cookie" (ie, 32-bit entity) that > the midbox can associate with each packet forwarded to an agent. When the > agent forwards this packet back to the midbox, the cookie should be copied > back. One important use of this cookie would be to tell the midbox where > the processing for this packet needs to resume. Note that this requirement > also seems to imply the need for tunnelling of user data-packets between > midbox and agent. > > > 3) Section 9.1, 2nd para: "A MIDCOM agent ought to be able to have a single > MIDCOM connection with a middlebox...". In addition, a MIDCOM agent must > be able to support multiple connections from the same middlebox. The > perspective from which I'm looking at this is purely a matter of scale. For > large scale midboxes with lots of processors, I would like it to be > possible for each processor to be able to maintain their own connection(s) > to the agent such that packets can be sent/received from/to a processor > directly without having to hop through another one first. In this scenario, > the middlebox L3 end-point of each of these connections will be the same; > however the L4 end-point (ie, TCP/UDP port number) would be different. In > addition, I highly recommend there be some sort of session-ID which is > included in every packet (control and data); there could be a mapping of > session-id to processor for large scale boxes ..... again, this enforces > the requirement for tunnelling user-data-packets. > > > 4) Redundancy and failure issues. There probably needs to be more > discussion on this topic. The first things that pop into my mind are: > > (a) The need to be able to determine when the peer has gone down. One of > the traditional techniques used for this is some sort of "heartbeat" > protocol. > > (b) User-data packets being forwarded between midbox and agent should be > dropped in network if the destined peer is down/unreachable. Tunnelling > would accomplish this since the midbox/agent peers are the src/dest of the > packet. The concern here is that when the data-stream is modified (such as > with NAT), some problems can be encountered if the two user-endpoints have > some data modified appropriately and some not (due to failure); it would be > preferred that the latter packets not reach the end-node since one possible > outcome of this sort of scenario is data-corruption. One of the problems > that arise in this situation is that seqno-delta operations performed by NAT > may not be done upon all packets of a conversation. Of course, one could > claim this is a more general problem that transcends the midbox architecture > (ie, any intermediate networking node that performs such stream > modifications opens this vulnerability), which is true to some extent; > however, I think that if this problem can be easily avoided by the midcom > arch it should be. > > (c) Failover support. I imagine this may be considered to be out of scope > since this is difficult (and potentially computationally expensive) for this > class of problem. > > > 5) This is more of a protocol than architectural issue... have some > mechanism in the protocol where a midbox can tell the agent to drop the > packet after fully processing it. This can lead to performance gains in > situations where the user data-stream doesn't need to be modified at all, > but rather watched for dynamic connection information. The midbox could > simply duplicate the packet, sending one to the agent and one on it's normal > way. Yes, this can lead to some race-conditions where the dynamic > connection is attempted to be opened before the agent has the chance to tell > the midbox about it. Assuming a tunnelling mechanism is used, a simple way > to implement this would be to have a bit indicating what to do with the > packet after the agent processes it. (There can be another bit indicating > whether the agent must forward the packet back to the midbox after > processing, or if the agent to route the packet onto the destination > however it sees fit. The power of tunnelling..... have I convinced you > yet? :) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 11:45: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 LAA11620 for ; Wed, 20 Jun 2001 11:45:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24542; Wed, 20 Jun 2001 11:41:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24509 for ; Wed, 20 Jun 2001 11:41:45 -0400 (EDT) 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 LAA11512 for ; Wed, 20 Jun 2001 11:41:08 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5KFdVH04777; Wed, 20 Jun 2001 08:39:32 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-1.cisco.com [10.21.112.1]) by airborne.cisco.com (Mirapoint) with ESMTP id ADW05335; Wed, 20 Jun 2001 08:41:05 -0700 (PDT) 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: <15152.50188.785000.673878@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 11:41:00 -0400 To: "Christian Huitema" Cc: "Melinda Shore" , Subject: RE: [midcom] Straw poll - out-of-path midcom agents 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 19 Jun 2001 at 12:07 -0700, Christian Huitema apparently wrote: > The debate on OOP is, IMHO, typical of what is wrong with this group. > Instead of solving the very simple problem of firewall traversal and > actually enabling communication Especially because we don't have to deal with them now. If we're supporting "normal" agents, adding OOPAs later will not require any fundamental changes to the midcom protocol. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 11:45:28 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 LAA11635 for ; Wed, 20 Jun 2001 11:45:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24303; Wed, 20 Jun 2001 11:36:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24275 for ; Wed, 20 Jun 2001 11:36:34 -0400 (EDT) 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 LAA11279 for ; Wed, 20 Jun 2001 11:35:57 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5KFYFH02066; Wed, 20 Jun 2001 08:34:25 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-1.cisco.com [10.21.112.1]) by airborne.cisco.com (Mirapoint) with ESMTP id ADW05250; Wed, 20 Jun 2001 08:35:49 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" Message-ID: <15152.49874.182000.181304@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 11:35:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pyda Srisuresh Cc: Brian E Carpenter , "Zmolek, Andrew \(Andrew\)" , Melinda Shore , "Fleischman, Eric W" , Andrew Molitor , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-Reply-To: <20010619201130.29421.qmail@web13807.mail.yahoo.com> References: <3B2FA10C.1364B969@hursley.ibm.com> <20010619201130.29421.qmail@web13807.mail.yahoo.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 19 Jun 2001 at 13:11 -0700, Pyda Srisuresh apparently wrote: > 1. Paragraph 1 of section 1 - Introduction > > "Application Level gateways (ALGs) are used in conjunction with NAT > to provide end-to-end transparency for many of the applications." > > I think, it should be OK to leave this unchanged. OK, we're talking about application-layer transparency. As long as you mean that the application data and the application behavior are unchanged, since that would fit the strict definition. I think I agree. > 2. Paragraph 3 of Section 1 - Introduction > > "The communication between a MIDCOM agent and a middlebox will be > transparent to the end-hosts that take part in the application, > unless one of the end-hosts assumes the role of a MIDCOM agent." > > I could reword this as follows: > > "The communication between a MIDCOM agent and a middlebox will > not be noticeable to the end-hosts that take part in the application, > unless one of the end-hosts assumes the role of a MIDCOM agent." Yes. > > 3. Sectin 2.4. - NAT > > "Network Address Translation is a method by which IP addresses are > mapped from one address realm to another, providing transparent > routing to end-hosts." > > This definition is settled after a long series of discussion > prior to advancing RFC 2663. The definition is carried as is > from RFC 2663. I donot recommend changing this. The best you can claim for NAT is application-layer transparency. I assume that by routing you mean forwarding of packets from one interface to another. That is an IP layer function, and it is certainly is not transparent, in that NAT modifies at least the headers of those packets. Perhaps you could change "transparent routing" to "application-layer transparency", but even that's debatable. I suggest you just claim something like application data transparency. > 4. Paragraph 3 of section 2.6 - ALG > > "ALGs are different from proxies. ALGs are transparent to > end-hosts, unlike the proxies which are relay agents terminating > sessions with both end-hosts." > > I could rephrase the above as follows: > > "ALGs are different from proxies. ALGs are not visible to > end-hosts, unlike the proxies which are relay agents terminating > sessions with both end-hosts." OK > 5. Paragraph 3 of section 5.2. - OOP MIDCOM agents > > "In essence, a middlebox provides to an Out-of-Path MIDCOM agent > the ability to transparently "snoop" and modify the control > traffic." > > I can reword the above as follows. > > "In essence, a middlebox provides to an Out-of-Path MIDCOM agent > the same priveleges as that of an In-Path agent, to application > control traffic, to "snoop" and modify as deemed appropriate." Hm, this now says that OOPAs have privileges (note spelling) for application CONTROL traffic. I thought you wanted OOPAs to be able to see all application traffic, not just signaling. If you eliminate "to application control traffic" it makes sense to me. > 6. The legend in figure 5 for "Ctrl" is described as follows. > "Ctrl - indicates the FTP control traffic, which > is transparently diverted to the OOP agent (2 and 3)" > > I can remove the word, and yet not change the semantics here. OK. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 12:01:28 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 MAA12049 for ; Wed, 20 Jun 2001 12:01:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25113; Wed, 20 Jun 2001 11:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25082 for ; Wed, 20 Jun 2001 11:59:55 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11979 for ; Wed, 20 Jun 2001 11:59:19 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA24700; Wed, 20 Jun 2001 11:59:24 -0400 (EDT) Message-Id: <200106201559.LAA24700@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Zmolek, Andrew (Andrew)" cc: "Pyda Srisuresh" , "Brian E Carpenter" , "Melinda Shore" , "Fleischman, Eric W" , "Andrew Molitor" , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Wed, 20 Jun 2001 07:54:35 MDT." Date: Wed, 20 Jun 2001 11:59:24 -0400 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 > And the idea of "end-to-end transparency" is debatable. If anything, ALG+NAT > provides a degree of transparency and typically compatibility across IP > realms. such barefaced lies do not contribute usefully to the discussion. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 12:14: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 MAA12428 for ; Wed, 20 Jun 2001 12:14:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26061; Wed, 20 Jun 2001 12:11:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26030 for ; Wed, 20 Jun 2001 12:11:18 -0400 (EDT) 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 MAA12320 for ; Wed, 20 Jun 2001 12:10:41 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5KGAsN24718 for ; Wed, 20 Jun 2001 09:10:54 -0700 (PDT) Received: from spandex (rtp-vpn-139.cisco.com [10.82.192.139]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKD09685; Wed, 20 Jun 2001 09:10:45 -0700 (PDT) Message-ID: <015b01c0f9a3$af92e8c0$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Wed, 20 Jun 2001 12:11:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Straw poll - results so far 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 Here are the results so far: Don't include out-of-path agents: 7 Do include out-of-path agents: 6 I think it's pretty safe to say that there's no consensus on this issue and that unless there's a sudden avalanche of people with strong feelings in one particular direction there will continue to be no consensus. What I'd like to propose is this: we leave it in the document for the time being, but, if during IESG/IAB review we encounter strong pushback, support for packet diversion be dropped without further debate. I'd really like to avoid having work that's questionably in scope impeding the progress of work that's definitely in scope. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 12:34: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 MAA13114 for ; Wed, 20 Jun 2001 12:34:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27108; Wed, 20 Jun 2001 12:31:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27073 for ; Wed, 20 Jun 2001 12:31:45 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12955 for ; Wed, 20 Jun 2001 12:31:08 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18628 for ; Wed, 20 Jun 2001 12:30:56 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18616 for ; Wed, 20 Jun 2001 12:30:55 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9A6.8264D04A" Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 20 Jun 2001 10:31:51 -0600 Message-ID: Thread-Topic: [midcom] Out-of-Path Midcom Agents in framework-02 Thread-Index: AcD5ogAEoL7jAwMIRW+USljksOERCQAA2iig From: "Zmolek, Andrew (Andrew)" To: "Keith Moore" Cc: "Pyda Srisuresh" , "Brian E Carpenter" , "Melinda Shore" , "Fleischman, Eric W" , "Andrew Molitor" , 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 multi-part message in MIME format. ------_=_NextPart_001_01C0F9A6.8264D04A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ...and your contribution below would be characterized as what? The idea that we need more precise description of these middlebox operations is a good one IMHO. Debate about the validity of middlebox implementations belongs elsewhere. This group was chartered to deal with middlebox communication and while contrarian commentary from a crusty old purist is entertaining, I think it's time for you to find a new forum to attack the use of NATs or ALGs themselves. If the IPv6 network is as well-engineered as you hope, NATs and ALGs will disappear on their own. Go grind your axe somewhere else, Keith.=20 --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Wednesday, June 20, 2001 9:59 AM To: Zmolek, Andrew (Andrew) Cc: Pyda Srisuresh; Brian E Carpenter; Melinda Shore; Fleischman, Eric W; Andrew Molitor; midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02=20 > And the idea of "end-to-end transparency" is debatable. If anything, ALG+NAT > provides a degree of transparency and typically compatibility across IP > realms.=20 such barefaced lies do not contribute usefully to the discussion. Keith ------_=_NextPart_001_01C0F9A6.8264D04A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Out-of-Path Midcom Agents in framework-02

...and your contribution below would be characterized = as what?

The idea that we need more precise description of = these middlebox operations is a good one IMHO. Debate about the validity = of middlebox implementations belongs elsewhere. This group was chartered = to deal with middlebox communication and while contrarian commentary = from a crusty old purist is entertaining, I think it's time for you to = find a new forum to attack the use of NATs or ALGs = themselves.

If the IPv6 network is as well-engineered as you hope, = NATs and ALGs will disappear on their own. Go grind your axe somewhere = else, Keith.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Keith Moore [mailto:moore@cs.utk.edu]
Sent: Wednesday, June 20, 2001 9:59 AM
To: Zmolek, Andrew (Andrew)
Cc: Pyda Srisuresh; Brian E Carpenter; Melinda Shore; = Fleischman, Eric
W; Andrew Molitor; midcom@ietf.org
Subject: Re: [midcom] Out-of-Path Midcom Agents in = framework-02


> And the idea of "end-to-end = transparency" is debatable. If anything, ALG+NAT
> provides a degree of transparency and typically = compatibility across IP
> realms.

such barefaced lies do not contribute usefully to the = discussion.

Keith

------_=_NextPart_001_01C0F9A6.8264D04A-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 12:50: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 MAA13672 for ; Wed, 20 Jun 2001 12:50:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27645; Wed, 20 Jun 2001 12:45:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27621 for ; Wed, 20 Jun 2001 12:45:31 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13464 for ; Wed, 20 Jun 2001 12:44:55 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA25067; Wed, 20 Jun 2001 12:45:24 -0400 (EDT) Message-Id: <200106201645.MAA25067@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Zmolek, Andrew (Andrew)" cc: "Keith Moore" , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Wed, 20 Jun 2001 10:31:51 MDT." Date: Wed, 20 Jun 2001 12:45:24 -0400 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 > ...and your contribution below would be characterized as what? exasperation. my apologies to the group. > The idea that we need more precise description of these middlebox operations > is a good one IMHO. IMHO also. I think the group needs a very clear picture of what it is doing, and having well-defined terms is a necessary first step. but folks who don't understand the utility of end-to-end transparency aren't going to be able to evaluate the cost versus benefit of anything that this group proposes. Keith p.s. Just to be clear, I was attacking *your misrepresenation* of NATs and ALGs, not NATs and ALGs themselves. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 12:50:57 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 MAA13709 for ; Wed, 20 Jun 2001 12:50:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27790; Wed, 20 Jun 2001 12:47:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27760 for ; Wed, 20 Jun 2001 12:47:46 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13547 for ; Wed, 20 Jun 2001 12:47:11 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA25143; Wed, 20 Jun 2001 12:47:43 -0400 (EDT) Message-Id: <200106201647.MAA25143@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Melinda Shore" cc: midcom@ietf.org Subject: Re: [midcom] Straw poll - results so far In-reply-to: Your message of "Wed, 20 Jun 2001 12:11:37 EDT." <015b01c0f9a3$af92e8c0$d45904d1@cisco.com> Date: Wed, 20 Jun 2001 12:47:43 -0400 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 seems like if there's no consensus to include oop agents, they should be omitted - rather than giving the impression that the group supports oop agents. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 12:50: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 MAA13720 for ; Wed, 20 Jun 2001 12:50:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27889; Wed, 20 Jun 2001 12:49:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27859 for ; Wed, 20 Jun 2001 12:49:48 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13606 for ; Wed, 20 Jun 2001 12:49:12 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA25163; Wed, 20 Jun 2001 12:49:42 -0400 (EDT) Message-Id: <200106201649.MAA25163@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Scott Brim" cc: Pyda Srisuresh , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Wed, 20 Jun 2001 11:35:46 EDT." <15152.49874.182000.181304@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 12:49:42 -0400 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 > The best you can claim for NAT is application-layer transparency. even that claim is dubious, since the IP address is available to applications and is often used by applications (for quite a few justifiable reasons). Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 12:53: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 MAA13825 for ; Wed, 20 Jun 2001 12:53:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27933; Wed, 20 Jun 2001 12:50:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27904 for ; Wed, 20 Jun 2001 12:50:01 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13609 for ; Wed, 20 Jun 2001 12:49:26 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5KGnFw25918 for ; Wed, 20 Jun 2001 17:49:15 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Wed, 20 Jun 2001 17:48:45 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 17:48:43 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30444FC2@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Melinda Shore'" , midcom Subject: RE: [midcom] Straw poll - results so far Date: Wed, 20 Jun 2001 17:48:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9A8.DE4946A0" 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_001_01C0F9A8.DE4946A0 Content-Type: text/plain; charset="ISO-8859-1" Sorry for the delay I was still catching the threads ... Melinda, I agree with your wise decision. Although I find usage of OOPs making things more complex there might be cases where it could be useful in a small contained enterprise environment, I think that Bob Penfield mentioned that. From a MIDCOM protocol perspective there is no difference between an in path agent and the OOP. The major requirements are on the Middle Box for the policy interface (additional "policy attributes" to bind the OOP with the Middle Box and the application), the diversion capability and the tunneling protocol. To summarize there is no harm to keep it in the framework, implementors will decide where they want to have the agent (on an existing application device or new external device) and if they want to put on the Middle Box the required features (mentioned above) to support OOPs ...Cedric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, June 20, 2001 6:12 PM To: midcom Subject: [midcom] Straw poll - results so far Here are the results so far: Don't include out-of-path agents: 7 Do include out-of-path agents: 6 I think it's pretty safe to say that there's no consensus on this issue and that unless there's a sudden avalanche of people with strong feelings in one particular direction there will continue to be no consensus. What I'd like to propose is this: we leave it in the document for the time being, but, if during IESG/IAB review we encounter strong pushback, support for packet diversion be dropped without further debate. I'd really like to avoid having work that's questionably in scope impeding the progress of work that's definitely in scope. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0F9A8.DE4946A0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Straw poll - results so far

Sorry for the delay I was still catching the threads = ...

Melinda,
I agree with your wise decision.

Although I find usage of OOPs making things more = complex there might be cases
where it could be useful in a small contained = enterprise environment, I think that Bob Penfield mentioned = that.

From a MIDCOM protocol perspective there is no = difference between an in path agent and the OOP.
The major requirements are on the Middle Box for the = policy interface (additional "policy attributes" to bind the = OOP
with the Middle Box and the application), the = diversion capability and the tunneling protocol.

To summarize there is no harm to keep it in the = framework, implementors will decide where they want to have
the agent (on an existing application device or new = external device) and if they want to put on the Middle Box
the required features (mentioned above) to support = OOPs
...Cedric


-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Wednesday, June 20, 2001 6:12 PM
To: midcom
Subject: [midcom] Straw poll - results so far


Here are the results so far:

Don't include out-of-path agents: 7
Do include out-of-path agents: 6

I think it's pretty safe to say that there's no = consensus
on this issue and that unless there's a sudden = avalanche
of people with strong feelings in one particular = direction
there will continue to be no consensus.  =

What I'd like to propose is this: we leave it in the =
document for the time being, but, if during = IESG/IAB
review we encounter strong pushback, support = for
packet diversion be dropped without further = debate.
I'd really like to avoid having work that's = questionably
in scope impeding the progress of work that's = definitely
in scope.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C0F9A8.DE4946A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 13:02: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 NAA14130 for ; Wed, 20 Jun 2001 13:02:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28315; Wed, 20 Jun 2001 13:00:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28266 for ; Wed, 20 Jun 2001 12:59:59 -0400 (EDT) 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 MAA13985 for ; Wed, 20 Jun 2001 12:59:24 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5KGxYN02934; Wed, 20 Jun 2001 09:59:35 -0700 (PDT) Received: from spandex (rtp-vpn-58.cisco.com [10.82.192.58]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKD11614; Wed, 20 Jun 2001 09:59:09 -0700 (PDT) Message-ID: <008901c0f9aa$737cf720$d45904d1@cisco.com> From: "Melinda Shore" To: "Keith Moore" Cc: References: <200106201647.MAA25143@astro.cs.utk.edu> Subject: Re: [midcom] Straw poll - results so far Date: Wed, 20 Jun 2001 12:59:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > seems like if there's no consensus to include oop agents, they > should be omitted - rather than giving the impression that the > group supports oop agents. I'd prefer to leave it to the judgment of the editor unless he's obviously out in the weeds somewhere. At this point there's not agreement that he is. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 13:03:57 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 NAA14173 for ; Wed, 20 Jun 2001 13:03:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28649; Wed, 20 Jun 2001 13:02:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28621 for ; Wed, 20 Jun 2001 13:02:43 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14124 for ; Wed, 20 Jun 2001 13:02:07 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA25458; Wed, 20 Jun 2001 13:02:39 -0400 (EDT) Message-Id: <200106201702.NAA25458@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Melinda Shore" cc: "Keith Moore" , midcom@ietf.org Subject: Re: [midcom] Straw poll - results so far In-reply-to: Your message of "Wed, 20 Jun 2001 12:59:59 EDT." <008901c0f9aa$737cf720$d45904d1@cisco.com> Date: Wed, 20 Jun 2001 13:02:39 -0400 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 > > seems like if there's no consensus to include oop agents, they > > should be omitted - rather than giving the impression that the > > group supports oop agents. > > I'd prefer to leave it to the judgment of the editor > unless he's obviously out in the weeds somewhere. if only half of the respondents support it, I don't think there's support from the WG to include it. seems like it should be the editor's responsibility to reflect the opinion of the group. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 13:24: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 NAA14990 for ; Wed, 20 Jun 2001 13:24:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29445; Wed, 20 Jun 2001 13:24:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29413 for ; Wed, 20 Jun 2001 13:24:11 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14957 for ; Wed, 20 Jun 2001 13:23:34 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA20934 for ; Wed, 20 Jun 2001 12:24:20 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA08054 for ; Wed, 20 Jun 2001 12:24:07 -0500 (CDT) Received: from xch-pssbh-01.nw.nos.boeing.com by stl-hub-01.boeing.com with ESMTP; Wed, 20 Jun 2001 12:23:58 -0500 Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 10:23:57 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DBC@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Melinda Shore'" , Keith Moore Cc: midcom@ietf.org, "'sob@harvard.edu'" Subject: RE: [midcom] Straw poll - results so far Date: Wed, 20 Jun 2001 10:23:52 -0700 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 This either-or winners-losers alternative is not going to satisfy the WG. I perceive that feelings about OOP Agents are very strong on both sides and this decision is only going to alienate participants (e.g., I deeply believe that OOP Agents are unacceptably dangerous and I've seen nothing to make me think otherwise. I firmly intend to bring out my objections again once last-call comes and I'm sure that I will have allies in the security community. We'll thus be right back to where we are now once that happens). I reiterate therefore that a compromise is needed if the group isn't going to divide over this issue. Let me re-state my proposed compromise. Please try it on for size, and then come up with another version that would best satisfy all: 1) The framework document primarily deals with In-Path Agents -- i.e., restricts itself to the scenarios identified by Christian Huitema's Scenarios draft, which I believe is the charter of both the FW document and this WG. In-Path Agents will thus comprise the vast majority of the material within the frameworks document. 2) However, the framework document should explicitly mention that OOP agents are an implementation possibility and that the following benefits accrue by including OOP agents (an enumeration can then be made by the OOP advocates). 3) However, should OOP agents be implemented, those OOP agents should be implemented to appear to be MIDCOM Agents resident on end systems (and, by implication, their implementation is accomplished via proprietary/vendor- specific methods rather than something specifically detailed by the Midcom WG). -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, June 20, 2001 10:00 AM To: Keith Moore Cc: midcom@ietf.org Subject: Re: [midcom] Straw poll - results so far > seems like if there's no consensus to include oop agents, they > should be omitted - rather than giving the impression that the > group supports oop agents. I'd prefer to leave it to the judgment of the editor unless he's obviously out in the weeds somewhere. At this point there's not agreement that he is. 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 Jun 20 13:29: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 NAA15119 for ; Wed, 20 Jun 2001 13:29:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29608; Wed, 20 Jun 2001 13:29:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29575 for ; Wed, 20 Jun 2001 13:29:04 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15105 for ; Wed, 20 Jun 2001 13:28:28 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA25662; Wed, 20 Jun 2001 13:28:55 -0400 (EDT) Message-Id: <200106201728.NAA25662@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Fleischman, Eric W" cc: "'Melinda Shore'" , Keith Moore , midcom@ietf.org, "'sob@harvard.edu'" Subject: Re: [midcom] Straw poll - results so far In-reply-to: Your message of "Wed, 20 Jun 2001 10:23:52 PDT." <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DBC@XCH-NW-01.nw.nos.boeing.com> Date: Wed, 20 Jun 2001 13:28:55 -0400 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 > 2) However, the framework document should explicitly mention > that OOP agents are an implementation possibility and that > the following benefits accrue by including OOP agents > (an enumeration can then be made by the OOP advocates). if the framework document mentions OOP agents at all, it should try to summarize both pros and cons. that would come as close as possible to expressing the overall opinion of the group. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 14:10:29 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 OAA16566 for ; Wed, 20 Jun 2001 14:10:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01417; Wed, 20 Jun 2001 14:08:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01388 for ; Wed, 20 Jun 2001 14:08:57 -0400 (EDT) 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 OAA16479 for ; Wed, 20 Jun 2001 14:08:21 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5KI6GH14004; Wed, 20 Jun 2001 11:06:17 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-1.cisco.com [10.21.112.1]) by airborne.cisco.com (Mirapoint) with ESMTP id ADW08353; Wed, 20 Jun 2001 11:07:46 -0700 (PDT) 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: <15152.58991.282000.306540@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 14:07:43 -0400 To: Keith Moore Cc: midcom@ietf.org, "'sob@harvard.edu'" Subject: Re: [midcom] Straw poll - results so far In-Reply-To: <200106201728.NAA25662@astro.cs.utk.edu> References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DBC@XCH-NW-01.nw.nos.boeing.com> <200106201728.NAA25662@astro.cs.utk.edu> 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 20 Jun 2001 at 13:28 -0400, Keith Moore apparently wrote: > > 2) However, the framework document should explicitly mention > > that OOP agents are an implementation possibility and that > > the following benefits accrue by including OOP agents > > (an enumeration can then be made by the OOP advocates). > > if the framework document mentions OOP agents at all, it should > try to summarize both pros and cons. that would come as close > as possible to expressing the overall opinion of the group. To both of you: we're trying to do some engineering with this draft. The pros and cons can go into an Analysis RFC. All we want is a framework. I like Eric's compromise, but just a mention that such things are possible, a brief description of how they would work, and any required protocol extensions -- without any opinions about good and bad -- would be plenty. We have mechanisms for adding the pros and cons, or for removing the text entirely, later on. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 14:25:15 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 OAA17126 for ; Wed, 20 Jun 2001 14:25:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01829; Wed, 20 Jun 2001 14:24:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01799 for ; Wed, 20 Jun 2001 14:24:01 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17055 for ; Wed, 20 Jun 2001 14:23:25 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A9BA401B014C; Wed, 20 Jun 2001 14:21:46 -0400 Message-ID: <00c701c0f9b5$d201bd20$2300000a@acmepacket.com> From: "Bob Penfield" To: "Fleischman, Eric W" , "'Melinda Shore'" , "Keith Moore" Cc: , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DBC@XCH-NW-01.nw.nos.boeing.com> Subject: Re: [midcom] Straw poll - results so far Date: Wed, 20 Jun 2001 14:21:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 I find the proposal acceptable. But just to make sure I understand, the MIDCOM protocol would not include support for any sort of "diversion" (like tunneling), but would be extensible such that a proprietary extension could be implemented to enable diversion to OOP agents. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Fleischman, Eric W" To: "'Melinda Shore'" ; "Keith Moore" Cc: ; Sent: Wednesday, June 20, 2001 1:23 PM Subject: RE: [midcom] Straw poll - results so far > This either-or winners-losers alternative is not going to > satisfy the WG. I perceive that feelings about OOP Agents > are very strong on both sides and this decision is only > going to alienate participants (e.g., I deeply believe that > OOP Agents are unacceptably dangerous and I've seen nothing > to make me think otherwise. I firmly intend to bring out my > objections again once last-call comes and I'm > sure that I will have allies in the security community. > We'll thus be right back to where we are now once > that happens). I reiterate therefore that a compromise is > needed if the group isn't going to divide over this issue. > Let me re-state my proposed compromise. Please try it on for > size, and then come up with another version that would best > satisfy all: > > 1) The framework document primarily deals with In-Path > Agents -- i.e., restricts itself to the scenarios identified > by Christian Huitema's Scenarios draft, which I believe is > the charter of both the FW document and this WG. In-Path > Agents will thus comprise the vast majority of the material > within the frameworks document. > 2) However, the framework document should explicitly mention > that OOP agents are an implementation possibility and that > the following benefits accrue by including OOP agents > (an enumeration can then be made by the OOP advocates). > 3) However, should OOP agents be implemented, those OOP > agents should be implemented to appear to be MIDCOM Agents > resident on end systems (and, by implication, their > implementation is accomplished via proprietary/vendor- > specific methods rather than something specifically detailed > by the Midcom WG). > > > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, June 20, 2001 10:00 AM > To: Keith Moore > Cc: midcom@ietf.org > Subject: Re: [midcom] Straw poll - results so far > > > > seems like if there's no consensus to include oop agents, they > > should be omitted - rather than giving the impression that the > > group supports oop agents. > > I'd prefer to leave it to the judgment of the editor > unless he's obviously out in the weeds somewhere. At > this point there's not agreement that he is. > > 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 > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 14:34:57 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 OAA17486 for ; Wed, 20 Jun 2001 14:34:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02309; Wed, 20 Jun 2001 14:33:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02274 for ; Wed, 20 Jun 2001 14:33:19 -0400 (EDT) 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 OAA17387 for ; Wed, 20 Jun 2001 14:32:42 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id SAA18101; Wed, 20 Jun 2001 18:33:09 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 20 Jun 2001 18:33:09 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 11:33:07 -0700 Message-ID: From: "Maciocco, Christian" To: "'Scott Brim'" , Andrew Molitor Cc: midcom@ietf.org Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 Date: Wed, 20 Jun 2001 11:33:00 -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 OPES non-transparent services which can be local or remote to the device also support in-path agent (depending upon the services to be provided). Christian > -----Original Message----- > From: Scott Brim [mailto:sbrim@cisco.com] > Sent: Wednesday, June 20, 2001 8:15 AM > To: Andrew Molitor > Cc: midcom@ietf.org > Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 > > > On 20 Jun 2001 at 00:27 -0500, Andrew Molitor apparently wrote: > > Rather than the loaded terms 'non-transparent' and > 'transparent' I > > propose we use the terms 'In-Path' and 'Out-of-Path' respectively. > > Nice try, but OPES (for example) is working with out-of-path > non-transparent functions. Also, the way we use > 'transparent' should be > generally applicable throughout the IETF. Again I like Randy's > approach, along with awareness that transparency is a per-layer issue. > > ...Scott > > > _______________________________________________ > 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 Jun 20 14:44:04 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 OAA17738 for ; Wed, 20 Jun 2001 14:44:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02531; Wed, 20 Jun 2001 14:41:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02498 for ; Wed, 20 Jun 2001 14:41:57 -0400 (EDT) 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 OAA17677 for ; Wed, 20 Jun 2001 14:41:20 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5KIfNN23760; Wed, 20 Jun 2001 11:41:23 -0700 (PDT) Received: from spandex (rtp-vpn-168.cisco.com [10.82.192.168]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKD16540; Wed, 20 Jun 2001 11:41:13 -0700 (PDT) Message-ID: <000201c0f9b8$b56ea580$d45904d1@cisco.com> From: "Melinda Shore" To: "Bob Penfield" Cc: References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DBC@XCH-NW-01.nw.nos.boeing.com> <00c701c0f9b5$d201bd20$2300000a@acmepacket.com> Subject: Re: [midcom] Straw poll - results so far Date: Wed, 20 Jun 2001 14:35:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 find the proposal acceptable. But just to make sure I understand, the > MIDCOM protocol would not include support for any sort of "diversion" (like > tunneling), but would be extensible such that a proprietary extension could > be implemented to enable diversion to OOP agents. The MOST we would be doing in terms of protocol support would be including some sort of diversion information element/AVP/whatever - the mechanism to transport diverted packets from the middlebox to wherever is so far out of charter that I'm not sure why the question was raised. I think that the question of whether or not diversion information would be standardized or proprietary remains open - there are people who feel strongly that we must provide that facility and those who feel we must not. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 14:48: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 OAA17839 for ; Wed, 20 Jun 2001 14:48:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02693; Wed, 20 Jun 2001 14:46:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02663 for ; Wed, 20 Jun 2001 14:46:49 -0400 (EDT) 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 OAA17803 for ; Wed, 20 Jun 2001 14:46:12 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5KIjqN26626; Wed, 20 Jun 2001 11:45:52 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-1.cisco.com [10.21.112.1]) by airborne.cisco.com (Mirapoint) with SMTP id ADW09236; Wed, 20 Jun 2001 11:45:41 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 20 Jun 2001 14:45:39 -0400 Date: Wed, 20 Jun 2001 14:45:39 -0400 From: Scott Brim To: Bob Penfield Cc: "Fleischman, Eric W" , "'Melinda Shore'" , Keith Moore , midcom@ietf.org, sob@harvard.edu Subject: Re: [midcom] Straw poll - results so far Message-ID: <20010620144538.A1624@SBRIM-W2K> Mail-Followup-To: Scott Brim , Bob Penfield , "Fleischman, Eric W" , 'Melinda Shore' , Keith Moore , midcom@ietf.org, sob@harvard.edu References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DBC@XCH-NW-01.nw.nos.boeing.com> <00c701c0f9b5$d201bd20$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00c701c0f9b5$d201bd20$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Wed, Jun 20, 2001 at 02:21:26PM -0400 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 Wed, Jun 20, 2001 at 02:21:26PM -0400, Bob Penfield wrote: > I find the proposal acceptable. But just to make sure I understand, the > MIDCOM protocol would not include support for any sort of "diversion" (like > tunneling), but would be extensible The midcom protocol will be decided in Midcom 2.0, but it will certainly be extensible anyway. We're not as omniscient as we think we are, we have to make it repairable. > such that a proprietary or standard > extension could > be implemented to enable diversion to OOP agents. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 15:01: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 PAA18411 for ; Wed, 20 Jun 2001 15:01:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03407; Wed, 20 Jun 2001 15:00:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03338 for ; Wed, 20 Jun 2001 15:00:33 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18198 for ; Wed, 20 Jun 2001 14:59:57 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHLWS633; Wed, 20 Jun 2001 15:00:02 -0400 Message-Id: <3.0.5.32.20010620145453.009829a0@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 20 Jun 2001 14:54:53 -0400 To: "Melinda Shore" , From: Mark Duffy Subject: Re: [midcom] Straw poll - out-of-path midcom agents In-Reply-To: <00f701c0f8eb$b83ecba0$d45904d1@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Melina, please count me in favor of support for OOP agents. The objective of this WG is to facilitate removing application intelligence from NAT and firewall middleboxes, and placing that intelligence instead in a Midcom Agent. Many applications never employ in-path intermediary boxes that could take on the Agent role. (Looking at the charter, I do not see that the scope of the effort is to be limited to SIP amd H.323 -- am I missing something?) Other applications may not have in-path intermediaries present in every case. Placing OOP agents out-of-scope implies restricting the midcom effort to supporting those applications that have in-path boxes suitable to step up and act as midcom agents. This would fall short of what many vendors of middlebox equipment may be expecting from this effort. I further believe that diversion mechanism(s) should be covered by the WG effort. Standardizing only part of the middlebox<-->agent communication will not gain much multi-vendor interoperability. Thanks, Mark Duffy At 02:14 PM 6/19/01 -0400, Melinda Shore wrote: >We've been going around and around on out-of-path agents >since the first draft of the document and it's my sense >that we're failing to make progress on it. I'd like to >take a straw poll to see how much support there is for >including support for diversion to out-of-path agents. >Please indicate to the mailing list whether or not you'd >like us to include consideration of out-of-path agents. >Be prepared to defend your position :-). > >Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 15:03: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 PAA18460 for ; Wed, 20 Jun 2001 15:03:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03497; Wed, 20 Jun 2001 15:01:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03463 for ; Wed, 20 Jun 2001 15:01:51 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18356 for ; Wed, 20 Jun 2001 15:01:14 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA12475 for ; Wed, 20 Jun 2001 12:01:09 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA28569 for ; Wed, 20 Jun 2001 12:01:47 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Wed, 20 Jun 2001 12:01:36 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 12:01:35 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DBD@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Melinda Shore'" Cc: midcom@ietf.org Subject: RE: [midcom] Straw poll - results so far Date: Wed, 20 Jun 2001 12:01:33 -0700 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 Melinda, Perhaps I'm not alone in having trouble understanding this important posting which you've just sent. I'd really appreciate you clarifying your points further, so that I could more adequately understand what you are saying. Please note that the following are real questions/ confusion on my part, not polemics: I had thought that what we were doing with the framework and the scenarios documents are providing the scoping and requirements of the forthcoming Midcom protocol. If so, why are we mentioning diversion functions if it is "so far out of charter that I'm not sure why the question was raised"? How can we provide "protocol support" for "diversion information element/AVP/whatever" without specifying mechanisms? If we are going to open a can of worms, we certainly need to provide constraints so that implementers know what to do with those worms. But more fundamentally, WHAT ARE WE TRYING TO DO with the frameworks draft? Have we not strayed tremendously far from our charter for that draft in the OOP parts of the current version? (The last sentence sounds like a polemic but it isn't intended to be one: I'm truly confused in understanding what you are thinking.) --Eric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, June 20, 2001 11:36 AM To: Bob Penfield Cc: midcom@ietf.org Subject: Re: [midcom] Straw poll - results so far > I find the proposal acceptable. But just to make sure I understand, the > MIDCOM protocol would not include support for any sort of "diversion" (like > tunneling), but would be extensible such that a proprietary extension could > be implemented to enable diversion to OOP agents. The MOST we would be doing in terms of protocol support would be including some sort of diversion information element/AVP/whatever - the mechanism to transport diverted packets from the middlebox to wherever is so far out of charter that I'm not sure why the question was raised. I think that the question of whether or not diversion information would be standardized or proprietary remains open - there are people who feel strongly that we must provide that facility and those who feel we must not. 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 Jun 20 15:09: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 PAA18768 for ; Wed, 20 Jun 2001 15:09:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03770; Wed, 20 Jun 2001 15:08:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03741 for ; Wed, 20 Jun 2001 15:08:36 -0400 (EDT) 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 PAA18754 for ; Wed, 20 Jun 2001 15:08:00 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5KJ85h11244; Wed, 20 Jun 2001 12:08:05 -0700 (PDT) Received: from spandex (rtp-vpn-168.cisco.com [10.82.192.168]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKD17749; Wed, 20 Jun 2001 12:07:44 -0700 (PDT) Message-ID: <006701c0f9bc$6a474f40$d45904d1@cisco.com> From: "Melinda Shore" To: , "Mark Duffy" References: <3.0.5.32.20010620145453.009829a0@10.1.1.249> Subject: Re: [midcom] Straw poll - out-of-path midcom agents Date: Wed, 20 Jun 2001 15:08:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > The objective of this WG is to facilitate removing application intelligence > from NAT and firewall middleboxes, and placing that intelligence instead in > a Midcom Agent. Right, but one thing that concerns me about this discussion is that by using out-of-path agents we're essentially taking application execution out of one type of network box and putting it into another type of network box. That is to say, we're failing to move it closer to the application elements that are already participating in the session. We *know* that requiring application participation by firewalls and NATs causes all kinds of breakage, and I'm not convinced that the implications of doing packet diversion to something else that's not really participating in the application have been fully considered. Anyway, vote noted and recorded. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 15:23:29 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 PAA19228 for ; Wed, 20 Jun 2001 15:23:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04171; Wed, 20 Jun 2001 15:22:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04141 for ; Wed, 20 Jun 2001 15:22:52 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19206 for ; Wed, 20 Jun 2001 15:22:15 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01350 for ; Wed, 20 Jun 2001 15:22:02 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01340 for ; Wed, 20 Jun 2001 15:22:02 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [midcom] Straw poll - out-of-path midcom agents MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9BE.699565F8" Date: Wed, 20 Jun 2001 13:22:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: Thread-Topic: [midcom] Straw poll - out-of-path midcom agents Thread-Index: AcD5vIiaTnOlPPI8T1CDXbhZ4InR3QAAFKCQ From: "Zmolek, Andrew (Andrew)" To: "Melinda Shore" , , "Mark Duffy" 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 multi-part message in MIME format. ------_=_NextPart_001_01C0F9BE.699565F8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The easier we make implementation of an OOP agent, the more likely that the supplier of an application implementation can *also* be the supplier of the application's perimeter traversal agent. This is likely to improve design of both applications and middleboxes and may (paradoxically) accelerate the elimination of NAT and IP boundary traversal problems. In the end, it isn't realistic to expect that a firewall have an ALG for every conceivable application, and firewall traversal isn't getting any easier for new applications. While some would call this approach a band-aid, it does provides a reasonable road map and I don't see any alternatives thriving (mainly because they mandate a forklift at some level and few are willing to buy that kind of value proposition). This is all to say that the decomposition of firewall architecture via midcom is a very good thing in general. So let's not spend so much time in mortal fear of arriving there. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, June 20, 2001 1:09 PM To: midcom@ietf.org; Mark Duffy Subject: Re: [midcom] Straw poll - out-of-path midcom agents > The objective of this WG is to facilitate removing application intelligence > from NAT and firewall middleboxes, and placing that intelligence instead in > a Midcom Agent.=20 Right, but one thing that concerns me about this discussion is that by using out-of-path agents we're essentially taking application execution out of one type of network box and putting it into another type of network box. That is to say, we're failing to=20 move it closer to the application elements that are already participating in the session. =20 We *know* that requiring application participation by firewalls and NATs causes all kinds of breakage, and I'm not convinced that the implications of doing packet diversion to something else that's not really participating in the application have been fully considered.=20 Anyway, vote noted and recorded. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0F9BE.699565F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Straw poll - out-of-path midcom agents

The easier we make implementation of an OOP agent, the = more likely that the supplier of an application implementation can = *also* be the supplier of the application's perimeter traversal agent. = This is likely to improve design of both applications and middleboxes = and may (paradoxically) accelerate the elimination of NAT and IP = boundary traversal problems.

In the end, it isn't realistic to expect that a = firewall have an ALG for every conceivable application, and firewall = traversal isn't getting any easier for new applications. While some = would call this approach a band-aid, it does provides a reasonable road = map and I don't see any alternatives thriving (mainly because they = mandate a forklift at some level and few are willing to buy that kind of = value proposition).

This is all to say that the decomposition of firewall = architecture via midcom is a very good thing in general. So let's not = spend so much time in mortal fear of arriving there.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Wednesday, June 20, 2001 1:09 PM
To: midcom@ietf.org; Mark Duffy
Subject: Re: [midcom] Straw poll - out-of-path midcom = agents


> The objective of this WG is to facilitate = removing application intelligence
> from NAT and firewall middleboxes, and placing = that intelligence instead in
> a Midcom Agent.

Right, but one thing that concerns me about = this
discussion is that by using out-of-path agents = we're
essentially taking application execution out of = one
type of network box and putting it into another = type
of network box.  That is to say, we're failing = to
move it closer to the application elements that = are
already participating in the session. 

We *know* that requiring application = participation
by firewalls and NATs causes all kinds of = breakage,
and I'm not convinced that the implications of = doing
packet diversion to something else that's not = really
participating in the application have been fully = considered.

Anyway, vote noted and recorded.

Melinda




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/= mailman/listinfo/midcom

------_=_NextPart_001_01C0F9BE.699565F8-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 15:23: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 PAA19227 for ; Wed, 20 Jun 2001 15:23:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04088; Wed, 20 Jun 2001 15:21:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04057 for ; Wed, 20 Jun 2001 15:21:11 -0400 (EDT) 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 PAA19148 for ; Wed, 20 Jun 2001 15:20:34 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5KJKkN20933; Wed, 20 Jun 2001 12:20:47 -0700 (PDT) Received: from spandex (rtp-vpn-168.cisco.com [10.82.192.168]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKD18311; Wed, 20 Jun 2001 12:20:33 -0700 (PDT) Message-ID: <008901c0f9be$3430f4e0$d45904d1@cisco.com> From: "Melinda Shore" To: "Fleischman, Eric W" Cc: References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DBD@XCH-NW-01.nw.nos.boeing.com> Subject: Re: [midcom] Straw poll - results so far Date: Wed, 20 Jun 2001 15:21:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 had thought that what we were doing with the framework and the > scenarios documents are providing the scoping and requirements of the > forthcoming Midcom protocol. We have two deliverables: 1) a framework document, which lays out the rationale, use cases, and network framework, and 2) a document describing the protocol requirements. The scenarios document is not a deliverable. (The new draft of the requirements document will appear on the website in the next day or so - it's in the hands of internet-drafts@ietf.org and just needs to clear the queue.) > If so, why are we mentioning diversion > functions if it is "so far out of charter that I'm not sure why the > question was raised"? That's an obvious question. Packet diversion was never mentioned during the chartering process and it's my PERSONAL suspicion that it never would have been accepted by the Greater Powers if it had been. The charter that was approved is quite clear about what we're working on and what we're responsible for delivering (and, not so incidentally, WHEN we're supposed to deliver it). We are absolutely not authorized to go ahead and invent a packet diversion transport protocol, nor are we chartered to develop a framework or requirements for it. Stuff that goes in the midcom protocol: in scope. Stuff that requires inventing a new protocol that was never discussed during the chartering process: out of scope. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 15:25: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 PAA19265 for ; Wed, 20 Jun 2001 15:25:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03707; Wed, 20 Jun 2001 15:08:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03681 for ; Wed, 20 Jun 2001 15:07:58 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18679 for ; Wed, 20 Jun 2001 15:07:21 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5KJ5VK18927 for ; Wed, 20 Jun 2001 15:05:31 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5KJ5Vh18914 for ; Wed, 20 Jun 2001 15:05:31 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9BC.17213416" Date: Wed, 20 Jun 2001 13:06:20 -0600 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: [midcom] Out-of-Path Midcom Agents in framework-02 Thread-Index: AcD5qG+kX2p5BriUQdCz4EDy+Q6+kwAEzsJg From: "Zmolek, Andrew (Andrew)" To: "Keith Moore" Cc: 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 multi-part message in MIME format. ------_=_NextPart_001_01C0F9BC.17213416 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > p.s. Just to be clear, I was attacking *your misrepresenation* of NATs and ALGs, not NATs and ALGs themselves. Fair enough. But it would be far more useful to me and the rest of the group to elaborate your concerns with more reason and less passion. Calling the ideas "barefaced lies" imputes a great deal more about your view of their contributor than the fundamental misrepresentation you claim to be concerned about.=20 I for one would still like to see an improvement of terminology being used and I think this discussion furthers that goal as long as we can refrain from personal attacks on the mailing list. The suggestion I made which you bristled at was just that: a suggestion, begging for refinement.=20 Regarding the inclusion of OOP agents into the draft, I think there is an acceptable middle ground here that all but the zealots can support. A discussion of OOP agents is proper and warranted. Midcom should neither endorse nor preclude its use with OOP agents. Another protocol (likely proprietary at least for now) will still be needed to deal with some of the more fundamental policy provisioning and agent authentication issues, but that's out of scope for midcom anyway.=20 Given the resistance that many of the established firewall vendors have toward midcom implementation, I think it's most important to make midcom friendly to those willing to implement midcom in an alternative firewall framework. Unless that framework is decomposeable (i.e. NAT, ALG, and other middlebox functionality is modular in nature), there won't be a good enough story there to sell anything. And midcom will be a waste if it doesn't find its way into high-volume products at some point.=20 The good news is that most of us want midcom to be widely deployable and sufficiently flexible so as to allow for different usage modes. Let's keep it that way. --Andy Zmolek=20 Technology & Standards Engineer=20 CTO Standards=20 Avaya Inc.=20 zmolek@avaya.com=20 +1 720 444 4001=20 ------_=_NextPart_001_01C0F9BC.17213416 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Out-of-Path Midcom Agents in framework-02

> p.s. Just to be clear, I was attacking *your = misrepresenation* of NATs and ALGs,
not NATs and ALGs themselves.

Fair enough. But it would be far more useful to me and = the rest of the group to elaborate your concerns with more reason and = less passion. Calling the ideas "barefaced lies" imputes a = great deal more about your view of their contributor than the = fundamental misrepresentation you claim to be concerned about. =

I for one would still like to see an improvement of = terminology being used and I think this discussion furthers that goal as = long as we can refrain from personal attacks on the mailing list. The = suggestion I made which you bristled at was just that: a suggestion, = begging for refinement.

Regarding the inclusion of OOP agents into the draft, = I think there is an acceptable middle ground here that all but the = zealots can support. A discussion of OOP agents is proper and warranted. = Midcom should neither endorse nor preclude its use with OOP agents. = Another protocol (likely proprietary at least for now) will still be = needed to deal with some of the more fundamental policy provisioning and = agent authentication issues, but that's out of scope for midcom anyway. =

Given the resistance that many of the established = firewall vendors have toward midcom implementation, I think it's most = important to make midcom friendly to those willing to implement midcom = in an alternative firewall framework. Unless that framework is = decomposeable (i.e. NAT, ALG, and other middlebox functionality is = modular in nature), there won't be a good enough story there to sell = anything. And midcom will be a waste if it doesn't find its way into = high-volume products at some point.

The good news is that most of us want midcom to be = widely deployable and sufficiently flexible so as to allow for different = usage modes. Let's keep it that way.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya Inc. =

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001

------_=_NextPart_001_01C0F9BC.17213416-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 15:31:41 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 PAA19480 for ; Wed, 20 Jun 2001 15:31:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04653; Wed, 20 Jun 2001 15:31:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04629 for ; Wed, 20 Jun 2001 15:31:15 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19466 for ; Wed, 20 Jun 2001 15:30:39 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA26714; Wed, 20 Jun 2001 15:31:12 -0400 (EDT) Message-Id: <200106201931.PAA26714@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Zmolek, Andrew (Andrew)" cc: "Keith Moore" , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Wed, 20 Jun 2001 13:06:20 MDT." Date: Wed, 20 Jun 2001 15:31:12 -0400 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 > > p.s. Just to be clear, I was attacking *your misrepresenation* of NATs and > > ALGs, not NATs and ALGs themselves. > > Fair enough. But it would be far more useful to me and the rest of the group > to elaborate your concerns with more reason and less passion. granted. though I submit it also be useful to this group if you would refrain from name-calling and ad hominem attacks. characterizing those who disagree with you as 'zealots' or 'crusty old purists' doesn't exactly increase the signal-to-noise ratio either. there are still serious operational, security, scalability, deployability and interoperability hazards associated with what midcom is working on. folks ignore these at their peril, and at the peril of the Internet. midcom's purpose, like that of the rest of IETF, is to figure out what makes sense from an engineering perspective, and design protocols that fit within a sensible engineering framework, for the benefit of the entire Internet community. the fact that some companies want to deploy products that do not make engineering sense in this context is not a justification for demanding that midcom help them do so. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 15:48: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 PAA20105 for ; Wed, 20 Jun 2001 15:48:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05084; Wed, 20 Jun 2001 15:44:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05051 for ; Wed, 20 Jun 2001 15:44:00 -0400 (EDT) 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 PAA19984 for ; Wed, 20 Jun 2001 15:43:10 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5KJhLN05043; Wed, 20 Jun 2001 12:43:21 -0700 (PDT) Received: from spandex (rtp-vpn-168.cisco.com [10.82.192.168]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKD19191; Wed, 20 Jun 2001 12:43:08 -0700 (PDT) Message-ID: <00bf01c0f9c1$5c0045e0$d45904d1@cisco.com> From: "Melinda Shore" To: "Zmolek, Andrew (Andrew)" , "Keith Moore" Cc: References: Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 Date: Wed, 20 Jun 2001 15:44:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > Another protocol (likely > proprietary at least for now) will still be needed to deal with some of > the more fundamental policy provisioning and agent authentication > issues, but that's out of scope for midcom anyway. That stuff is in scope, actually. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 16:40:18 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 QAA21871 for ; Wed, 20 Jun 2001 16:40:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07165; Wed, 20 Jun 2001 16:39:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07134 for ; Wed, 20 Jun 2001 16:39:15 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21842 for ; Wed, 20 Jun 2001 16:38:38 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA27475; Wed, 20 Jun 2001 16:39:12 -0400 (EDT) Message-Id: <200106202039.QAA27475@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Zmolek, Andrew (Andrew)" cc: "Keith Moore" , midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-reply-to: Your message of "Wed, 20 Jun 2001 14:34:58 MDT." Date: Wed, 20 Jun 2001 16:39:12 -0400 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 > We all know that in the end the only way to accomplish this nirvana > is to lock it up and turn it off. Is that really the class of solution > we want in midcom? no, but I think you are exaggerating. midcom can do useful work by tackling the basic problems outlined in its charter and avoiding the pitfalls that come from trying to over-generalize the problem. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 16:40: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 QAA21882 for ; Wed, 20 Jun 2001 16:40:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06992; Wed, 20 Jun 2001 16:34:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06963 for ; Wed, 20 Jun 2001 16:34:54 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21711 for ; Wed, 20 Jun 2001 16:34:16 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16373 for ; Wed, 20 Jun 2001 16:34:03 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16362 for ; Wed, 20 Jun 2001 16:34:03 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9C8.79102310" Date: Wed, 20 Jun 2001 14:34:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: Thread-Topic: [midcom] Out-of-Path Midcom Agents in framework-02 Thread-Index: AcD5v5a6JWUW1fVITtywh1pp8usdSgABt0Jg From: "Zmolek, Andrew (Andrew)" To: "Keith Moore" Cc: 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 multi-part message in MIME format. ------_=_NextPart_001_01C0F9C8.79102310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > granted. though I submit it also be useful to this group if you would=20 > refrain from name-calling and ad hominem attacks. characterizing those > who disagree with you as 'zealots' or 'crusty old purists'=20 > doesn't exactly increase the signal-to-noise ratio either. Keith: I think your approach is very endearing, actually. And great entertainment, even if I don't agree with the position you so predictably take. I'm surprised you don't consider those labels a badge of honor, frankly. Nevertheless, I'm committed to improving the signal-to-noise ratio so please permit me to apologize and move on to the issues at hand. > there are still serious operational, security, scalability, deployability=20 > and interoperability hazards associated with what midcom is working on. =20 > folks ignore these at their peril, and at the peril of the Internet. > midcom's purpose, like that of the rest of IETF, is to figure out > what makes sense from an engineering perspective, and design protocols > that fit within a sensible engineering framework, for the benefit > of the entire Internet community. the fact that some companies want to=20 > deploy products that do not make engineering sense in this context > is not a justification for demanding that midcom help them do so. Agreed. But no standard is worth pursuing if it provides no value to potential implementers. There is a balance here, and while all of us would like a technically perfect standard the reality is akin to the notion of creating a perfectly secure device. We all know that in the end the only way to accomplish this nirvana is to lock it up and turn it off. Is that really the class of solution we want in midcom? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 ------_=_NextPart_001_01C0F9C8.79102310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Out-of-Path Midcom Agents in framework-02

> granted. though I submit it also be useful to = this group if you would
> refrain from name-calling and ad hominem = attacks. characterizing those
> who disagree with you as 'zealots' or 'crusty = old purists'
> doesn't exactly increase the signal-to-noise = ratio either.

Keith: I think your approach is very endearing, = actually. And great entertainment, even if I don't agree with the = position you so predictably take. I'm surprised you don't consider those = labels a badge of honor, frankly. Nevertheless, I'm committed to = improving the signal-to-noise ratio so please permit me to apologize and = move on to the issues at hand.

> there are still serious operational, security, = scalability, deployability
> and interoperability hazards associated with = what midcom is working on. 
> folks ignore these at their peril, and at the = peril of the Internet.

> midcom's purpose, like that of the rest of IETF, = is to figure out
> what makes sense from an engineering = perspective, and design protocols
> that fit within a sensible engineering = framework, for the benefit
> of the entire Internet community.  the fact = that some companies want to
> deploy products that do not make engineering = sense in this context
> is not a justification for demanding that midcom = help them do so.

Agreed. But no standard is worth pursuing if it = provides no value to potential implementers. There is a balance here, = and while all of us would like a technically perfect standard the = reality is akin to the notion of creating a perfectly secure device. We = all know that in the end the only way to accomplish this nirvana is to = lock it up and turn it off. Is that really the class of solution we want = in midcom?

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001

------_=_NextPart_001_01C0F9C8.79102310-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 17:16: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 RAA23176 for ; Wed, 20 Jun 2001 17:16:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08195; Wed, 20 Jun 2001 17:10:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08162 for ; Wed, 20 Jun 2001 17:09:58 -0400 (EDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22892 for ; Wed, 20 Jun 2001 17:09:21 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CpEU-000Nwm-00; Wed, 20 Jun 2001 14:09:50 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Zmolek, Andrew (Andrew)" Cc: "Keith Moore" , Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 References: Message-Id: Date: Wed, 20 Jun 2001 14:09:50 -0700 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 > Agreed. But no standard is worth pursuing if it provides no value to > potential implementers. s/implementors/users/ randy _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 17:32: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 RAA23706 for ; Wed, 20 Jun 2001 17:32:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09026; Wed, 20 Jun 2001 17:30:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08997 for ; Wed, 20 Jun 2001 17:30:57 -0400 (EDT) Received: from intotoinc.com (adsl-64-170-220-4.dsl.snfc21.pacbell.net [64.170.220.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23566 for ; Wed, 20 Jun 2001 17:30:19 -0400 (EDT) Received: from tatra (sdsl-208-185-176-16.dsl.sjc.megapath.net [208.185.176.26] (may be forged)) by intotoinc.com (8.11.0/8.11.0) with SMTP id f5KLTqh13723 for ; Wed, 20 Jun 2001 14:29:52 -0700 Message-ID: <014a01c0f9cc$4b5ffb80$2806010a@tatra> From: "T. N. M. Kumar" To: Date: Wed, 20 Jun 2001 14:02:19 -0700 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.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Transfer-Encoding: 7bit Subject: [midcom] Megaco and NAT 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 understand this working group at one point of time was addressing issues related to Megaco working with NAT. Any pointers to information appreciated. - Kumar _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 18:09: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 SAA24661 for ; Wed, 20 Jun 2001 18:09:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10021; Wed, 20 Jun 2001 18:04:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09955 for ; Wed, 20 Jun 2001 18:04:15 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24528 for ; Wed, 20 Jun 2001 18:03:36 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHLWS7A4; Wed, 20 Jun 2001 18:03:42 -0400 Message-Id: <3.0.5.32.20010620175923.009c1100@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 20 Jun 2001 17:59:23 -0400 To: "Melinda Shore" , , "Mark Duffy" From: Mark Duffy Subject: Re: [midcom] Straw poll - out-of-path midcom agents In-Reply-To: <006701c0f9bc$6a474f40$d45904d1@cisco.com> References: <3.0.5.32.20010620145453.009829a0@10.1.1.249> 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 At 03:08 PM 6/20/01 -0400, Melinda Shore wrote: >> The objective of this WG is to facilitate removing application intelligence >> from NAT and firewall middleboxes, and placing that intelligence instead in >> a Midcom Agent. > >Right, but one thing that concerns me about this >discussion is that by using out-of-path agents we're >essentially taking application execution out of one >type of network box and putting it into another type >of network box. That is to say, we're failing to >move it closer to the application elements that are >already participating in the session. That's true. But if there are no intermediary boxes participating in the session, then that just isn't an option anyway. *And* one would hopefully be moving the application intelligence out of a specialized, embedded, proprietary device (whose supplier could never keep up with every new application) into a more generic platform, that could hopefully install middlebox-vendor-independent application intelligence modules provided in a timely fashion by whoever sells/promotes the particular application. > >We *know* that requiring application participation >by firewalls and NATs causes all kinds of breakage, >and I'm not convinced that the implications of doing >packet diversion to something else that's not really >participating in the application have been fully considered. > >Anyway, vote noted and recorded. > >Melinda > > > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 18:21: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 SAA24942 for ; Wed, 20 Jun 2001 18:21:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10414; Wed, 20 Jun 2001 18:20:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10389 for ; Wed, 20 Jun 2001 18:20:19 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24868 for ; Wed, 20 Jun 2001 18:19:42 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08495 for ; Wed, 20 Jun 2001 18:19:29 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08489 for ; Wed, 20 Jun 2001 18:19:29 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9D7.33E05A80" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 20 Jun 2001 16:20:25 -0600 Message-ID: Thread-Topic: [midcom] Out-of-Path Midcom Agents in framework-02 Thread-Index: AcD5zWBM8hq3WKKkR2OSnoKhT72A5gACZHqg From: "Zmolek, Andrew (Andrew)" To: "Randy Bush" Cc: "Keith Moore" , 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 multi-part message in MIME format. ------_=_NextPart_001_01C0F9D7.33E05A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ultimately, you are correct, Randy. But even a sophisticated user has to go through the process of implementation even if a 3rd party isn't involved. And for midcom it's especially hard to argue that the protocol is user-facing. --Andy -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Wednesday, June 20, 2001 3:10 PM To: Zmolek, Andrew (Andrew) Cc: Keith Moore; midcom@ietf.org Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02=20 > Agreed. But no standard is worth pursuing if it provides no value to > potential implementers. s/implementors/users/ randy ------_=_NextPart_001_01C0F9D7.33E05A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Out-of-Path Midcom Agents in framework-02

Ultimately, you are correct, Randy. But even a = sophisticated user has to go through the process of implementation even = if a 3rd party isn't involved. And for midcom it's especially hard to = argue that the protocol is user-facing.

--Andy

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com]
Sent: Wednesday, June 20, 2001 3:10 PM
To: Zmolek, Andrew (Andrew)
Cc: Keith Moore; midcom@ietf.org
Subject: RE: [midcom] Out-of-Path Midcom Agents in = framework-02


> Agreed. But no standard is worth pursuing if it = provides no value to
> potential implementers.

s/implementors/users/

randy

------_=_NextPart_001_01C0F9D7.33E05A80-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 20 19:17: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 TAA26092 for ; Wed, 20 Jun 2001 19:17:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12265; Wed, 20 Jun 2001 19:16:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12232 for ; Wed, 20 Jun 2001 19:16:40 -0400 (EDT) Received: from sapphire.int.ipverse.com ([65.195.29.42]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26042 for ; Wed, 20 Jun 2001 19:16:05 -0400 (EDT) Received: from default.ipverse.com (MATT [10.1.1.160]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L4T527B7; Wed, 20 Jun 2001 16:16:09 -0700 Message-Id: <5.1.0.14.2.20010620161331.021509a0@mail.ipverse.com> X-Sender: matt@mail.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Jun 2001 16:16:03 -0700 To: "T. N. M. Kumar" , From: Matt Holdrege Subject: Re: [midcom] Megaco and NAT In-Reply-To: <014a01c0f9cc$4b5ffb80$2806010a@tatra> 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 Not really. If you wish to develop an ALG for MEGACO, you might want to first decide if you care about binary or text encoding, then write your own ALG for H.245 or SDP respectively. At that time, I would recommend submitting an individual draft and see what WG has the interest or the mandate to produce such an RFC. At 02:02 PM 6/20/2001, T. N. M. Kumar wrote: >I understand this working group at one point of time was addressing >issues related to Megaco working with NAT. > >Any pointers to information appreciated. >- Kumar > > > >_______________________________________________ >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 Jun 21 04:57: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 EAA21946 for ; Thu, 21 Jun 2001 04:57:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05834; Thu, 21 Jun 2001 04:54:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05805 for ; Thu, 21 Jun 2001 04:54:14 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21890 for ; Thu, 21 Jun 2001 04:53:37 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5L8rbw10602 for ; Thu, 21 Jun 2001 09:53:37 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Thu, 21 Jun 2001 09:53:29 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 09:52:15 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30444FCD@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Fleischman, Eric W'" , "'Andrew Molitor'" , "'Maciocco, Christian'" , "'Scott Brim'" , "'richard.swale@bt.com'" , srisuresh@yahoo.com Cc: "'midcom@ietf.org'" Subject: RE: [midcom] middlebox informs agent? Date: Thu, 21 Jun 2001 09:52:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA2F.793187F0" 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_001_01C0FA2F.793187F0 Content-Type: text/plain; charset="iso-8859-1" Eric I thought we agreed to postpone the debates on usage of timers in the state machines of Middle Boxes and agent until starting to work on the protocol spec. I'm always happy to serve our cause but it is best to focus the framework first and the protocol requirements first (tear down and cleaning of unused resources); the protocol spec will provide the means to achieve the previous. Please see comments below ..Cedric -----Original Message----- From: Fleischman, Eric W [mailto:Eric.Fleischman@PSS.Boeing.com] Sent: Monday, June 18, 2001 8:53 PM To: Aoun, Cedric [QPD:0000:EXCH]; 'Andrew Molitor'; 'Maciocco, Christian'; 'Scott Brim'; 'richard.swale@bt.com'; srisuresh@yahoo.com Cc: 'midcom@ietf.org' Subject: RE: [midcom] middlebox informs agent? This excellent posting has touched on several ideas which I would appreciate us discussing more fully. From: Andrew Molitor [mailto:amolitor@visi.com] > In some cases, like SIP, the agent need not have any timer > state since the endpoints will (may?) provide events which can > be used to refresh state. In other cases, the agent may need to > maintain internal timers for its own purposes. It is not safe to > assume that the agent is maintaining timer state. >It is safe to assume that essentially any model of timers you > can think up will be desirable to someone. It is not safe to assume > ANYTHING about the timer model implemented by a specific middlebox > class device. As I indicated in the aforementioned email, I have > no clear idea of what the right way to deal with these fact in the > to-be-defined MIDCOM protocol is. I eagerly await suggestions. This is an excellent point. I think that we can agree that because there are many implementations, there are potentially different approaches to timers in existing products. However, to the degree to which the midcom protocol addresses timer issues, to that extent we theoretically have the option to create standardization of approaches which impact timers. Towards that end, I would like to propose that we explicitly seek to make no assumption as to a midcom agent's use of timers, by explicitly making subsequent use of the midcom teardown function be optional. By so doing, however, we would explicitly be requiring that the middlebox itself keeps timers (as the text already says) so that it could automatically close down any "hole" even if the agent "goes away" for unforeseen reasons. I think that most of us will readily agree with this tenet because it makes the protocol more able to weather unforeseen events. Question to Cedric: could you agree with my above two paragraphs? If not, how would you modify them? -------------------------------- CA: As I ( and Suresh, Scott, Christian M and others in the list) previously mentioned to the list there are several options to achieve the same end results. We need to compare the pros/cons of both. Having different approaches to achieve the end goal, requires a negotiating capabilty to be introduced during the registration phase between the Midcom Agent and the Middle box, to understand who does what. This will complexify the protocol state machines ( I think that we all agree on that). All this will need to be considered when start looking in the details of the protocol. I agree with the fact that there are several current implementations of MBs in the market and if we want MIDCOM to be successful it needs to take into account all the previously mentioned options to do the tear down/cleaning of session descriptors -------------------------------- I agree that form a requirements > I keep seeing these posts which apparently assume some > Platonic Ideal middlebox -- usually subtly different from everyone > else's Platonic Ideal of a middlebox. Let me remind us all, one more > time, MIDCOM needs to deal with existing middlebox class devices. I > am happy to go on all day about one such device, the one I work on. > I have described many of its properties as illustrative examples > already. I am neither so naive, nor so rude, as to assume that MY > device is the canonical middlebox, the only one MIDCOM must deal > with. This is a bit of a problem since unless we are talking about your implementation, then we're talking about someone else's implementation. If they object to us using your implementation as our standard or if you object to our using their implementation as our standard, then we can't really talk about specific implementations after all. That is, the only way we can talk about all implementations is to add in abstraction, thereby perhaps creating a "Platonic Ideal of a middlebox". I believe that this is a almost unavoidable. On the other hand, any implementation can rightly object to assumptions contained within this "Platonic Ideal" which war against their particular implementation. An example is my second paragraph above. However, unless all implementations are harmonious in the points touched by the midcom protocol, the unfortunate reality will be that any attempt for standardization will be more challenging for some implementations than for others. Therefore, I HOPE that we can resolve this problem by having very good reasons for doing whatever we're doing, which is why these types of discussions are so important. ----------------- CA: I also hope that we shall find a way to meet everybody's MBs needs without requiring to add negotiating capabilities and hybrid type of behaviors ... ------_=_NextPart_001_01C0FA2F.793187F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] middlebox informs agent?

Eric
I thought we agreed to postpone the debates on usage = of timers in the state machines of Middle Boxes and agent until = starting to work on the protocol spec.

I'm always happy to serve our cause but it is best to = focus the framework first and the protocol requirements first (tear = down and cleaning of unused resources); the protocol spec will provide = the means to achieve the previous.

Please see comments below

..Cedric

-----Original Message-----
From: Fleischman, Eric W [mailto:Eric.Fleischman@PS= S.Boeing.com]
Sent: Monday, June 18, 2001 8:53 PM
To: Aoun, Cedric [QPD:0000:EXCH]; 'Andrew Molitor'; = 'Maciocco,
Christian'; 'Scott Brim'; 'richard.swale@bt.com'; = srisuresh@yahoo.com
Cc: 'midcom@ietf.org'
Subject: RE: [midcom] middlebox informs = agent?


This excellent posting has touched on several ideas = which I would appreciate us discussing more fully.

From: Andrew Molitor [mailto:amolitor@visi.com]
 > In some cases, like SIP, the agent need = not have any timer
 > state since the endpoints will (may?) = provide events which can
 > be used to refresh state. In other cases, = the agent may need to
 > maintain internal timers for its own = purposes. It is not safe to
 > assume that the agent is maintaining = timer state.

>It is safe to assume that essentially any model = of timers you
 > can think up will be desirable to = someone. It is not safe to assume
 > ANYTHING about the timer model = implemented by a specific middlebox
 >  class device. As I indicated in the = aforementioned email, I have
 > no clear idea of what the right way to = deal with these fact in the
 > to-be-defined MIDCOM protocol is. I = eagerly await suggestions.
 
This is an excellent point. I think that we can = agree that because there
are many implementations, there are potentially = different approaches
to timers in existing products. However, to the = degree to which the
midcom protocol addresses timer issues, to that = extent we theoretically
have the option to create standardization of = approaches which impact
timers.

Towards that end, I would like to propose that we = explicitly seek to
make no assumption as to a midcom agent's use of = timers, by explicitly
making subsequent use of the midcom teardown = function be optional. By
so doing, however, we would explicitly be requiring = that the middlebox
itself keeps timers (as the text already says) so = that it could
automatically close down any "hole" even = if the agent "goes away" for
unforeseen reasons. I think that most of us will = readily agree with
this tenet because it makes the protocol more able = to weather
unforeseen events.

Question to Cedric: could you agree with my above two = paragraphs? If not,
how would you modify them?
--------------------------------
CA: As I ( and Suresh, Scott, Christian M and others = in the list) previously mentioned to the list there
are several options to achieve the same end results. = We need to compare the pros/cons of both.

Having different approaches to achieve the end goal, = requires a
negotiating capabilty to be introduced during the = registration phase between
the Midcom Agent and the Middle box, to understand = who does what.
This will complexify the protocol state machines ( I = think that we all agree on that).

 
All this will need to be considered when start = looking in the details of
the protocol.

I agree with the fact that there are several current = implementations of MBs
in the market and if we want MIDCOM to be successful = it needs to take into
account all the previously mentioned options to do = the tear down/cleaning of session descriptors
--------------------------------

I agree that form a requirements

 > I keep seeing these posts which apparently = assume some
 > Platonic Ideal middlebox -- usually = subtly different from everyone
 > else's Platonic Ideal of a middlebox. Let = me remind us all, one more
 > time, MIDCOM needs to deal with existing = middlebox class devices. I
 > am happy to go on all day about one such = device, the one I work on.
 > I have described many of its properties = as illustrative examples
 > already. I am neither so naive, nor so = rude, as to assume that MY
 > device is the canonical middlebox, the = only one MIDCOM must deal
 > with.

This is a  bit of a problem since unless we are = talking about your
implementation, then we're talking about someone = else's implementation.
If they object to us using your implementation as = our standard or if
you object to our using their implementation as our = standard, then
we can't really talk about specific implementations = after all. That is,
the only way we can talk about all implementations = is to add in
abstraction, thereby perhaps creating a = "Platonic Ideal of a middlebox".
I believe that this is a almost unavoidable.

On the other hand, any implementation can rightly = object to assumptions
contained within this "Platonic Ideal" = which war against their particular
implementation. An example is my second paragraph = above. However, unless
all implementations are harmonious in the points = touched by the midcom
protocol, the unfortunate reality will be that any = attempt for
standardization will be more challenging for some = implementations than
for others. Therefore, I HOPE that we can resolve = this problem by
having very good reasons for doing whatever we're = doing, which is why
these types of discussions are so important.
-----------------
CA: I also hope that we shall find a way to meet = everybody's MBs needs without requiring to
add negotiating capabilities and hybrid type of = behaviors ...

------_=_NextPart_001_01C0FA2F.793187F0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 21 07:11: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 HAA23335 for ; Thu, 21 Jun 2001 07:11:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09788; Thu, 21 Jun 2001 07:00:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09755 for ; Thu, 21 Jun 2001 07:00:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23161; Thu, 21 Jun 2001 06:59:50 -0400 (EDT) Message-Id: <200106211059.GAA23161@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, 21 Jun 2001 06:59:49 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-requirements-01.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 : Middlebox Control (MIDCOM) Protocol Architecture and Requirements Author(s) : R. Swale, P. Mart, P. Sijben Filename : draft-ietf-midcom-requirements-01.txt,.ps Pages : 19 Date : 20-Jun-01 Networks connecting to and forming part of the Internet are increasingly deploying specialised network functions to address security, quality of service and other administrative policy requirements. These devices are a subset of what can be referred to as 'Middleboxes'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-01.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-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010620132305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010620132305.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 Jun 21 11:35: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 LAA02755 for ; Thu, 21 Jun 2001 11:35:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25407; Thu, 21 Jun 2001 11:29:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25377 for ; Thu, 21 Jun 2001 11:29:23 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02517 for ; Thu, 21 Jun 2001 11:28:44 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA13208 for ; Thu, 21 Jun 2001 10:29:32 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA19680 for ; Thu, 21 Jun 2001 10:29:15 -0500 (CDT) Received: from xch-pssbh-01.nw.nos.boeing.com by stl-hub-01.boeing.com with ESMTP; Thu, 21 Jun 2001 10:29:12 -0500 Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 08:29:11 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DC3@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Cedric Aoun'" , "Fleischman, Eric W" , "'Andrew Molitor'" , "'Maciocco, Christian'" , "'Scott Brim'" , "'richard.swale@bt.com'" , srisuresh@yahoo.com Cc: "'midcom@ietf.org'" Subject: RE: [midcom] middlebox informs agent? Date: Thu, 21 Jun 2001 08:29:04 -0700 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 From: Cedric Aoun [mailto:CEDRIC.AOUN@nortelnetworks.com] > Eric > I thought we agreed to postpone the debates on usage of timers in the state machines >of Middle Boxes and agent until starting to work on the protocol spec. I wasn't aware of this agreement -- perhaps it occurred during the weeks the Midcom archives weren't functioning because I did not notice any mention of it in the archived materials. It is my perception that the framework document should provide the specs for the midcom protocol. If one adopts such a viewpoint, state machines and timers are central for the framework document to address. More importantly, I want a protocol that is transactional during setup and transactional during teardown, but which has no state during the initial negotiation stage to protect against DoS attacks. I also want to have no state kept within the protocol between setup and teardown. This requires the middlebox itself to keep the timers so that it could know when a teardown should occur should the Midcom Agent "disappear" -- as well they might for a variety of reasons. I am very surprised that adding these concepts to the framework document is controversial. >Having different approaches to achieve the end goal, requires a >negotiating capability to be introduced during the registration phase between >the Midcom Agent and the Middle box, to understand who does what. >This will complexify the protocol state machines ( I think that we all agree on that). The type of protocol I seek is one that is as simple as possible. I do not think that the current "state of the art" is mature enough -- particularly understanding the security implications -- to design an "all things for all people"-type of protocol which the framework authors are targeting. People with gray hair such as myself who were active participants in the TCP/IP vs. OSI wars re-learned several lessons from history (e.g., the Merrimack versus the Monitor during the US Civil War). Younger people may not yet have learned that the efficient way to build complex systems is to hypothesize an architecture and then build a small system to verify it. Once the small system works as hoped, then incrementally build upon it. Put another way: I've designed some really complex systems over the years. I've come to realize that building a "full-blown" system from the get-go is doomed to cost overruns, re-designs, and massive schedule slips. The proper way to design such systems is to build the core and then incrementally enhance it, learning the needed lessons at each stage. I had hoped that younger people would have been familiar with these types of concepts from Extreme Programming, but I fear that the allure of creating massive systems from scratch is a powerful one. It's also very easy to underestimate the difficulty of a task. As I earlier stated in an email to the group, it is my perception that we are operating on different assumptions as to what the framework document is or should be. I also see the group as currently being very polarized and the timeframes we are marching to increase the pressure. I don't necessarily view polarization as bad. What I object to is the scarcity of technical discussion that occurs on this group. For example, I respect that people can disagree with me about the importance of OOP Agents (who knows, maybe they are right?), but I am frustrated that nobody has addressed my specific technical objections to their position. Why aren't they taking the next step to show me how their approach could be done in a secure manner, for example? Also, I either do not understand or do not approve (I'm not sure at this time which is the case) of the current direction of this group. The net result is that I feel very insecure about the probability of this WG producing useful results. --Eric _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 21 11:41:08 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 LAA03080 for ; Thu, 21 Jun 2001 11:41:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27173; Thu, 21 Jun 2001 11:38:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27142 for ; Thu, 21 Jun 2001 11:38:41 -0400 (EDT) Received: from web14307.mail.yahoo.com (web14307.mail.yahoo.com [216.136.173.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02963 for ; Thu, 21 Jun 2001 11:38:03 -0400 (EDT) Message-ID: <20010621153840.52909.qmail@web14307.mail.yahoo.com> Received: from [134.117.114.50] by web14307.mail.yahoo.com; Thu, 21 Jun 2001 11:38:40 EDT Date: Thu, 21 Jun 2001 11:38:40 -0400 (EDT) From: Abdallah Rayhan Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02 To: midcom@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Andrew makes a good point here. I also dont buy the security threat arguement against OOP mentioned in earlier emails. OOP are no worse than In-Path agents. The latter opens a pinhole and allows worms to traverse the MB. While the former does something to ensure that it is not a worm. Issues of trust are always there whenever a new box is to be deployed. This is a risk that you have to take if you want the benefit of a new service. Some firewall vendors have adapted open proprietary interfaces. They have done it before and the issue of security didnt raise many eyes brows then. If it is done right there wont be any reason to say that it is not secure enough. This does not necessarily require discovery or complex mechanisms. Ensuring that the architecture of the MB is extensible enough to support a number of services makes market adaptation of MIDCOM more likely. Focusing only on In-Path agents for VoIP like applications is restrictive; one firewall for VoIP, another for content inspection, another for .... hay here is an idea for a new firewall interop-WG! regards, Abdallah --- "Zmolek, Andrew (Andrew)" wrote: > Regarding the inclusion of OOP agents into the draft, I think there > is > an acceptable middle ground here that all but the zealots can > support. A > discussion of OOP agents is proper and warranted. Midcom should > neither > endorse nor preclude its use with OOP agents. Another protocol > (likely > proprietary at least for now) will still be needed to deal with some > of > the more fundamental policy provisioning and agent authentication > issues, but that's out of scope for midcom anyway. > > Given the resistance that many of the established firewall vendors > have > toward midcom implementation, I think it's most important to make > midcom > friendly to those willing to implement midcom in an alternative > firewall > framework. Unless that framework is decomposeable (i.e. NAT, ALG, and > other middlebox functionality is modular in nature), there won't be a > good enough story there to sell anything. And midcom will be a waste > if > it doesn't find its way into high-volume products at some point. _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 21 12:46: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 MAA06155 for ; Thu, 21 Jun 2001 12:46:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08433; Thu, 21 Jun 2001 12:41:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08402 for ; Thu, 21 Jun 2001 12:41:45 -0400 (EDT) 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 MAA05939 for ; Thu, 21 Jun 2001 12:41:08 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 358AF819A; Thu, 21 Jun 2001 10:59:20 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id LAA03959; Thu, 21 Jun 2001 11:41:43 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 21 Jun 2001 11:41:43 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] middlebox informs agent? In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DC3@XCH-NW-01.nw.nos.boeing.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, 21 Jun 2001, Fleischman, Eric W wrote: > From: Cedric Aoun [mailto:CEDRIC.AOUN@nortelnetworks.com] > >Having different approaches to achieve the end goal, requires a > >negotiating capability to be introduced during the registration phase > >between the Midcom Agent and the Middle box, to understand who does what. > >This will complexify the protocol state machines ( I think that we all > >agree on that). > > The type of protocol I seek is one that is as simple as possible. I do > not think that the current "state of the art" is mature enough -- > particularly understanding the security implications -- to design an > "all things for all people"-type of protocol which the framework > authors are targeting. I'm not targeting any such thing! I want this thing to be as simple as possible -- but no simpler! My personal feeling (though we're getting ahead of the game into protocol design) is that if MIDCOM does not include a capabilities advertisement/query scheme, then it'll be a useless toy. This does not imply a 7 step iterative exchange that provably converges on the optimal interoperability gloop snork gack. Something along the lines of 'Hey, can you ?' and '407 No' is just fine. > People with gray hair such as myself who were > active participants in the TCP/IP vs. OSI wars re-learned several > lessons from history (e.g., the Merrimack versus the Monitor during > the US Civil War). I am FASCINATED by this! What is the parallel between IP vs. OSI and the battle of the ironclads? Indeed, what is the lesson inherent in the latter, other than 'playing chicken with cannons in cramped floating tanks is insane and dangerous?' > Younger people may not yet have learned that the > efficient way to build complex systems is to hypothesize an > architecture and then build a small system to verify it. Once the > small system works as hoped, then incrementally build upon it. Put > another way: I've designed some really complex systems over the years. > I've come to realize that building a "full-blown" system from the > get-go is doomed to cost overruns, re-designs, and massive schedule > slips. The proper way to design such systems is to build the core and > then incrementally enhance it, learning the needed lessons at each > stage. I had hoped that younger people would have been familiar with > these types of concepts from Extreme Programming 'Kludge and Conquer' >, but I fear that the > allure of creating massive systems from scratch is a powerful one. > It's also very easy to underestimate the difficulty of a task. Perhaps you don't realize how snotty this paragraph sounds? I wan't there for the Monitor vs. Merrimack battle, I haven't got a nanonsecond of patience for EP, but I'm actually not an idiot, I swear. The 'build a small one and expand' model is fine. What you don't want to do is start out by designing a small one from specifications that are demonstrably wrong. Then the little demo you wrote will, surprise, NOT pass that all important 'verify it' stage. Sometimes there is a minimal level of complexity required from the beginning. It is exceedingly difficult to get to the moon by building a turtle shaped mock-up of your vehicle out of concrete (because that's easy, plus which it looks COOL!) and then incrementally improving your implementation. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 21 13:29: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 NAA08815 for ; Thu, 21 Jun 2001 13:29:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18977; Thu, 21 Jun 2001 13:28:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18946 for ; Thu, 21 Jun 2001 13:28:37 -0400 (EDT) Received: from web13805.mail.yahoo.com (web13805.mail.yahoo.com [216.136.175.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08726 for ; Thu, 21 Jun 2001 13:28:00 -0400 (EDT) Message-ID: <20010621172835.94190.qmail@web13805.mail.yahoo.com> Received: from [65.12.33.187] by web13805.mail.yahoo.com; Thu, 21 Jun 2001 10:28:35 PDT Date: Thu, 21 Jun 2001 10:28:35 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] middlebox informs agent? To: "Fleischman, Eric W" Cc: "'midcom@ietf.org'" In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DC3@XCH-NW-01.nw.nos.boeing.com> 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 --- "Fleischman, Eric W" wrote: > From: Cedric Aoun [mailto:CEDRIC.AOUN@nortelnetworks.com] > > Eric > > I thought we agreed to postpone the debates on usage of timers in the state > machines > >of Middle Boxes and agent until starting to work on the protocol spec. > > I wasn't aware of this agreement -- perhaps it occurred during the weeks the > Midcom archives > weren't functioning because I did not notice any mention of it in the > archived materials. > > It is my perception that the framework document should provide the specs for > the > midcom protocol. Eric - The framework draft is not a functional spec for the MIDCOM protocol. The FW document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation without resorting to embedding application intelligence. The objective of the MIDCOM architecture is to create a unified, standard way to exercise this functionality, currently existing in an ad-hoc fashion in some of the middleboxes. > If one adopts such a viewpoint, state machines and timers > are > central for the framework document to address. Sounds like, you are on a different track than the rest of us on what is expected of the framework. The draft shall not include discussions on state machines and timers and how they ought to be implemented for MIDCOM. > More importantly, I want a > protocol that > is transactional during setup and transactional during teardown, but which > has no state > during the initial negotiation stage to protect against DoS attacks. I also > want to have > no state kept within the protocol between setup and teardown. This requires > the middlebox > itself to keep the timers so that it could know when a teardown should occur > should the > Midcom Agent "disappear" -- as well they might for a variety of reasons. I am > very > surprised that adding these concepts to the framework document is > controversial. > Your discussion is perhaps very pertinent at the time of protocol design. We are not there yet. You are jumping the gun. <... stuff deleted> > As I earlier stated in an email to the group, it is my perception that we are > operating on > different assumptions as to what the framework document is or should be. I You are right about that. <... stuff deleted> cheers, suresh ===== __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 21 17:43: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 RAA18581 for ; Thu, 21 Jun 2001 17:43:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15298; Thu, 21 Jun 2001 17:40:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15273 for ; Thu, 21 Jun 2001 17:40:22 -0400 (EDT) Received: from ridgeway.ridgeway-sys.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18489 for ; Thu, 21 Jun 2001 17:39:44 -0400 (EDT) Received: by RIDGEWAY with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 22:39:48 +0100 Message-ID: <00533D13955AD411AF3800A0C9B42639C2A26C@RIDGEWAY> From: Steve Davies To: Matt Holdrege , "T. N. M. Kumar" Cc: midcom@ietf.org Subject: RE: [midcom] Megaco and NAT Date: Thu, 21 Jun 2001 22:39:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA9A.B10200E0" 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_001_01C0FA9A.B10200E0 Content-Type: text/plain; charset="ISO-8859-1" The restriction with Midcom is that it doesn't scale down - a call agent is needed to handle calls, especially inbound calls otherwise there would be a permanent inbound connection to every endpoint though the FW/NAT which is obviously a security concern. Megaco doesn't really fit this model as the call agent and endpoint (gateway or terminal) are usually on opposites sides of the firewall/NAT. You might like to look at the draft below which describes a protocol agnostic method for secure but transparent traversal through firewalls and NATs. No change to the firewall or NAT is needed. No firewall/NAT control protocol is needed. Today we have only included call flows for H.323 and SIP, but it could be extended for MGCP/Megaco if there was interest. http://search.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt. Steve -----Original Message----- From: Matt Holdrege [mailto:matt@ipverse.com] Sent: 21 June 2001 00:16 To: T. N. M. Kumar; midcom@ietf.org Subject: Re: [midcom] Megaco and NAT Not really. If you wish to develop an ALG for MEGACO, you might want to first decide if you care about binary or text encoding, then write your own ALG for H.245 or SDP respectively. At that time, I would recommend submitting an individual draft and see what WG has the interest or the mandate to produce such an RFC. At 02:02 PM 6/20/2001, T. N. M. Kumar wrote: >I understand this working group at one point of time was addressing >issues related to Megaco working with NAT. > >Any pointers to information appreciated. >- Kumar > > > >_______________________________________________ >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 ------_=_NextPart_001_01C0FA9A.B10200E0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Megaco and NAT

The restriction with Midcom is that it doesn't scale = down - a call agent is needed to handle calls, especially inbound calls = otherwise there would be a permanent inbound connection to every = endpoint though the FW/NAT which is obviously a security concern. = Megaco doesn't really fit this model as the call agent and endpoint = (gateway or terminal) are usually on opposites sides of the = firewall/NAT.

You might like to look at the draft below which = describes a protocol agnostic method for secure but transparent = traversal through firewalls and NATs. No change to the firewall or NAT = is needed. No firewall/NAT control protocol is needed. Today we have = only included call flows for H.323 and SIP, but it could be extended = for MGCP/Megaco if there was interest. 

http://search.ietf.org/internet-drafts/draft-davies-fw= -nat-traversal-00.txt.

Steve
-----Original Message-----
From: Matt Holdrege [mailto:matt@ipverse.com]
Sent: 21 June 2001 00:16
To: T. N. M. Kumar; midcom@ietf.org
Subject: Re: [midcom] Megaco and NAT


Not really. If you wish to develop an ALG for MEGACO, = you might want to
first decide if you care about binary or text = encoding, then write your own
ALG for H.245 or SDP respectively. At that time, I = would recommend
submitting an individual draft and see what WG has = the interest or the
mandate to produce such an RFC.


At 02:02 PM 6/20/2001, T. N. M. Kumar wrote:
>I understand this working group at one point of = time was addressing
>issues related to Megaco working with = NAT.
>
>Any pointers to information appreciated.
>- Kumar
>
>
>
>_______________________________________________
>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=

------_=_NextPart_001_01C0FA9A.B10200E0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 21 18:02: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 SAA18899 for ; Thu, 21 Jun 2001 18:02:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15845; Thu, 21 Jun 2001 17:59:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15815 for ; Thu, 21 Jun 2001 17:59:16 -0400 (EDT) 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 RAA18776 for ; Thu, 21 Jun 2001 17:58:38 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5LLwqN09668; Thu, 21 Jun 2001 14:58:52 -0700 (PDT) Received: from spandex (rtp-vpn-190.cisco.com [10.82.192.190]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKG15561; Thu, 21 Jun 2001 14:58:44 -0700 (PDT) Message-ID: <05c701c0fa9d$73779480$d45904d1@cisco.com> From: "Melinda Shore" To: "Steve Davies" Cc: References: <00533D13955AD411AF3800A0C9B42639C2A26C@RIDGEWAY> Subject: Re: [midcom] Megaco and NAT Date: Thu, 21 Jun 2001 17:59:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > The restriction with Midcom is that it doesn't scale down - a call agent is > needed to handle calls, especially inbound calls otherwise there would be a > permanent inbound connection to every endpoint though the FW/NAT which is > obviously a security concern. To your first point - a call agent isn't needed, but a midcom agent is. There's no reason that a midcom agent cannot be resident in an endpoint (indeed, we explicitly assume that it can be). To your second point, policy allows us to restrict what sort of inbound connections would be permitted. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 21 18:06: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 SAA18965 for ; Thu, 21 Jun 2001 18:06:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16310; Thu, 21 Jun 2001 18:06:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16279 for ; Thu, 21 Jun 2001 18:06:06 -0400 (EDT) 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 SAA18955 for ; Thu, 21 Jun 2001 18:05:28 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5LM5gN15144 for ; Thu, 21 Jun 2001 15:05:42 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn1-4.cisco.com [10.82.80.4]) by airborne.cisco.com (Mirapoint) with SMTP id ADY02215; Thu, 21 Jun 2001 15:05:34 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 21 Jun 2001 18:05:33 -0400 Date: Thu, 21 Jun 2001 18:05:33 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Megaco and NAT Message-ID: <20010621180533.A1644@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <00533D13955AD411AF3800A0C9B42639C2A26C@RIDGEWAY> <05c701c0fa9d$73779480$d45904d1@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <05c701c0fa9d$73779480$d45904d1@cisco.com>; from mshore@cisco.com on Thu, Jun 21, 2001 at 05:59:30PM -0400 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 Also, you can incrementally move applications to the agent model. If discovery goes the way it looks like it will, your existing firewall can continue to function just as it is in parallel for outgoing calls. On Thu, Jun 21, 2001 at 05:59:30PM -0400, Melinda Shore wrote: > > The restriction with Midcom is that it doesn't scale down - a call agent is > > needed to handle calls, especially inbound calls otherwise there would be a > > permanent inbound connection to every endpoint though the FW/NAT which is > > obviously a security concern. > > To your first point - a call agent isn't needed, but a > midcom agent is. There's no reason that a midcom agent > cannot be resident in an endpoint (indeed, we explicitly > assume that it can be). To your second point, policy > allows us to restrict what sort of inbound connections > would be permitted. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 21 20:31: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 UAA21756 for ; Thu, 21 Jun 2001 20:31:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22461; Thu, 21 Jun 2001 20:30:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22385 for ; Thu, 21 Jun 2001 20:30:47 -0400 (EDT) Received: from yourwebsite.com (24.100.115.107.on.wave.home.com [24.100.115.107]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21707 for ; Thu, 21 Jun 2001 20:30:07 -0400 (EDT) From: TimeForAChange@real.com Message-Id: <200106220030.UAA21707@ietf.org> Reply-To: kchmystery@yahoo.com To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 21 Jun 2001 20:28:40 -0400 Subject: [midcom] Don't take my word for it 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 Earn up to $500K in 120 Days Sending Email!! > ________________________________________________________________________________ Note Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with "unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. Please Note-This is a one time mailing.Thank you. ________________________________________________________________________________ > >Excuse us for bothering you but we would like to share our >good luck with everybody. > >My wife received this e-mail and forwarded it to me to review. >We've both read completely through it and have been in contact >with some of the individuals listed below. > >We think it's an excellent opportunity that is well worth the small >investment of time and money, and believe that you will, too! > > >===== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ====== >If you would like to make at least $500,000 every 4 to 5 months easily and >comfortably, please read the following... > >THEN READ IT AGAIN and AGAIN!!! > > >FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR FINANCIAL >DREAMS WILL COME TRUE, GUARANTEED! > >INSTRUCTIONS: >Order all 5 reports shown on the list below > >For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT >YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose >name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN >ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail >problems. > >When you place your order, make sure you order each of the 5 reports. > > >You will need all 5 reports so that you can save them on your computer >and resell them. YOUR TOTAL COST $5 X 5=$25.00. > >Within a few days you will receive, vie e-mail, each of the 5 re ports from >these 5 different individuals. Save them on your computer so they will be >accessible for you to send to the 1,000's of people who will order them >from you. Also make a floppy of these reports and keep it on your desk in >case something happens to your computer. > > >IMPORTANT - DO NOT alter the names of the people who are listed next >to each report, or their sequence on the list, in any way other than what is >instructed below in step '' 1 through 6 '' or you will loose out on a >majority of your profits. Once you understand the way this works, >you will also see how it does not work if you change it. Remember, >this method has been tested, and if altered, it will NOT work !!! >People have tried to put their friends/relatives names on all five thinking >they could get all the money. But it does not work this way. Believe us, >and Do Not try to change anything other than what is instructed. If you do, >it will not work for you. >Remember, honesty reaps the reward!!! > > > > > >1.... After you have ordered all 5 reports, take this advertisement and >REMOVE the name & address of the person in REPORT # 5. This person >has made it through the cycle and is no doubt counting their fortune > > >2....Move the name & address in REPORT # 4 down toREPORT # 5. > > >3....Move the name & address in REPORT # 3 down TO REPORT # 4. > > >4....Move the name & address in REPORT # 2 downTO REPORT # 3. > > >5.... Move the name & address in REPORT # 1 down TO REPORT # 2 > > >6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE >SURE you copy every name & address ACCURATELY! >****Take this entire letter, with the modified list of names, and save it on >your computer. DO NOT MAKE ANY OTHER CHANGES. > > >Save this on a disk as well, just in case you loose any data. To assist you >with marketing your business on the internet, the 5 reports you purchase >will provide you with invaluable marketing information which includes how >to send bulk e-mails legally, where to find thousands of free classified ads >and much more. > > >There are 2 Primary methods to get this venture going: > > >METHOD # 1:BY SENDING BULK E-MAIL LEGALLY > >Let's say that you decide to start small, just to see how it goes, and we >Will assume you and those involved send out only 5,000 e-mails each. Let's >also assume that the mailing receive only a 0.2% response (the response >could be much better but lets just say it is only 0.2%. Also many people >will send out hundreds of thousands e-mails instead of only 5,000 each). >Continuing with this example, you send out only 5,000 e-mails. With a 0.2% >response, that is only 10 orders for report # 1. Those 10 people responded >by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 >e-mails only 0.2% responded with orders. That's=100 people responded and >ordered Report # 2. > > >Those 100 people mail out 5,000 e-mails each for a total of 500,000 >e-mails. The 0.2% response to that is 1000 orders for Report # 3. > > >Those 1000 people send out 5,000 e-mails each for a total of 5 million >e-mails sent out. The 0.2% response to that is 10,000 orders for Report # >4. > > >Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 >(50 million) e-mails. > > > >The 0.2% response to that is 100,000 orders for Report # 5 > > THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). >Your total income in this example is: 1..... $50 + 2..... $500 + 3..... >$5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 > > >NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT >THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU >CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! > > > >REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE >ORDERING OUT OF 5,000 YOU MAILED TO. > >Dare to think for a moment what would happen if everyone or half or even >one 4th of those people mailed 100,000 e-mails each or more? There are >over 150 million people on the Internet worldwide and counting. Believe me, >many people will do just that, and more! > > > >METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET >Advertising on the net is very very inexpensive and there are hundreds >of FREE places to advertise. Placing a lot of free ads on the Internet will >easily get a larger response. We strongly suggest you start with Method # 1 >and add METHOD # 2 as you go along. For every $5 you receive, all you >must do is e-mail them the Report they ordered. That's it. Always provide >same day service on all orders. > >This will guarantee that the e-mail they send out, with your name and >address on it, will be prompt because they can not advertise until they >receive the report. > > >========= AVAILABLE REPORTS ============= >ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: > >============================================== >Always send $5 cash (U.S. CURRENCY only) for each Report. > >Checks NOT accepted. >Make sure the cash is concealed by wrapping it in at least 2 sheets >of paper. > > On one of those sheets of paper, Write > > a.The NUMBER & the NAME of the Report > > you are ordering, > > b. YOUR E-MAIL ADDRESS and > > c. your name and postal address. > > (In case of mail difficulties.) > > >PLACE YOUR ORDER FOR THESE REPORTS NOW : > >REPORT # 1: "The Insider's Guide to Advertising for Free on the Net" >Order Report #1 from: >Kerry G. >PO Box 210132 >San Francisco, CA 94121 >USA >_________________________________________________________ >REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the Net" >Order Report # 2 from: >P.Harry >P.O. Box 470015 >Brooklyn, NY 11247 > USA >__________________________________________________________ >REPORT # 3: "Secret to Multi-Level Marketing on the Net" >Order Report # 3 from: >Mary Morgan >12 Condotti Drive >Woodbridge, Ontario, L4H 2C8 >Canada >__________________________________________________________ >REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" >Order Report # 4 from: >D. Harris >6717 Main Street >Stouffville, ON L4A 6B3 >Canada >__________________________________________________________ >REPORT #5: "How to Send Out One Million e-mails for Free" >Order Report # 5 from: >Christa H >6021 Yonge Street, Ste. 1021 >Toronto, ON M2M 3W2 >Canada > >_________________________________________________________ >You can KEEP TRACK of your PROGRESS by watching which report >people are ordering from you. IF YOU WANT TO GENERATE MORE >INCOME SEND ANOTHER BATCH OF E-MAILS AND START >THE WHOLE PROCESS AGAIN. >_________________________________________________________ >$$$$$$$$$YOUR SUCCESS GUIDELINES $$$$$$$$$$$ > > >Follow these guidelines to guarantee your success: > > >=== If you do not receive at least 10 orders for Report #1 within 2 >weeks, continue sending e-mails until you do. > > >=== After you have received 10 orders, 2 to 3 weeks after that you >should receive 100 orders or more for REPORT # 2. If you did not, >continue advertising or sending e-mails until you do. > > >=== Once you have received 100 or more orders for Report # 2, YOU >CAN RELAX, because the system is already working for you, and the >cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: >Every time your name is moved down on the list, you are placed in front >of a Different report. > > >There is NO LIMIT to the income you can generate from this business !!! > > >=============================================== > > >FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS >PROGRAM: > >You have just received information that can give you >financial freedom for the rest of your life, with NO RISK and JUST >A LITTLE BIT OF EFFORT. You can make more money in the next >few weeks and months than you have ever imagined. Follow the program >EXACTLY AS INSTRUCTED. Do Not change it in any way. It works >exceedingly well as it is now. > > >Remember to e-mail a copy of this exciting report after you have put >your name and address in Report #1 and moved others to #2 ..........# 5 >as instructed above. One of the people you send this to may send out >100,000 or more e-mails and your name will be on every one of them. >Remember though, the more you send out the more potential customers >you will reach. > > >So my friend, I have given you the ideas, information, materials and >opportunity to become financially independent. IT IS UP TO YOU NOW ! > > >============ TESTIMONIALS ================ > >This is what one had to say: ''Thanks to this profitable opportunity. I >was approached many times before but each time I passed on it. I am >so glad I finally joined just to see what one could expect in return for the >minimal effort and money required. > >To my astonishment, I received total $610,470.00 in 21 weeks, >with money still coming in." >Pam Hedland, Fort Lee, New Jersey > > >Here is another testimonial: > >"This program has been around for a long time but I never believed >in it. But one day when I received this again in the mail I decided to >gamble my $25 on it. I followed the simple instructions and walaa >..... 3 weeks later the money started to come in. > >First month I only made $240.00 but the next 2 months after that I made >a total of $290,000.00. So far, in the past 8 months by re-entering the >program, I have made over $710,000.00 and I am playing it again. The >key to success in this program is to follow the simple steps and NOT change >anything.'' > > >"My name is Mitchell. My wife, Jody and I live in Chicago. I am an >accountant with a major U.S. Corporation and I make pretty good money. >When I received this program I grumbled to Jody about receiving ''junk >mail''. I made fun of the whole thing, spouting my knowledge of the >population and percentages involved. I ''knew'' it wouldn't work. >Jody totally ignored my supposed intelligence and a few days later >she jumped in with both feet. > >I made merciless fun of her, and was ready to lay the old ''I told you so'' on >her when the thing didn't work. Well, the laugh was on me! Within 3 weeks >she had received 50 responses. Within the next 45 days she had received >total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody >in her ''hobby''. > >Mitchell Wolf M.D., Chicago, Illinois > >================================================ > > >''Not being the gambling type, it took me several weeks to make up my >mind to participate in this plan. But conservative that I am, I decided that >the initial investment was so little that there was just no way that I >wouldn't get enough orders to at least get my money back''. '' I was >surprised when I found my medium size post office box crammed with >orders. I made $319,210.00 in the first 12 weeks. The nice thing about >this deal is that it does not matter where people live. There simply isn't a >better investment with a faster return and so big." >Dan Sondstrom, Alberta, Canada > > >================================================ >''I had received this program before. I deleted it, but later I wondered >if I should have given it a try. Of course, I had no idea who to contact to >get another copy, so I had to wait until I was e-mailed agai n by someone >else.........11 months passed then it luckily came again...... I did not >delete this one! I made more than $490,000 on my first try and all the >money came within 22 weeks." >Susan De Suza, New York, N.Y. > > >================================================= > > >''It really is a great opportunity to make relatively easy money with >little cost to you. I followed the simple instructions carefully and >within 10 days the money started to come in. My first month I made >$20,560.00 and by the end of third month my total cash count was >$362,840.00. Life is beautiful, Thanks to internet.". >Fred Dellaca, Westport, New Zealand > > >================================================= >ORDER YOUR REPORTS TODAY AND GET STARTED ON >'YOUR' ROAD TO FINANCIAL FREEDOM ! >================================================= > > >About 50,000 new people get online every month! >_______________________________________________________ > > > > >FOR YOUR INFORMATION.... >If you need help with starting a business, registering a business name, >learning how income tax is handled, etc., contact your local office of the >Small Business Administration (a Federal agency) 1-(800)827-5722 for free >help and answers to questions. Also, the Internal Revenue Service offers >free help via telephone and free seminars about business tax requirements. > >Under Bill S1618 Title III passed by the 105th US Congress this letter >cannot be considered spam as long as the sender includes contact >information >and a method of removal. This is a one-time e-mail transmission. No request >for removal is necessary. > >If you have any questions of the legality of this program, contact the >Office of Associate Director for Marketing Practices, Federal Trade >Commission, Bureau of Consumer Protection, Washington, D.C. > > Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with "unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. Please Note-This is a one time mailing.Thank you. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 08:15:04 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 IAA18068 for ; Fri, 22 Jun 2001 08:15:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20317; Fri, 22 Jun 2001 08:13:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20288 for ; Fri, 22 Jun 2001 08:13:06 -0400 (EDT) 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 IAA17966 for ; Fri, 22 Jun 2001 08:12:32 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5MCCjN14423; Fri, 22 Jun 2001 05:12:45 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-19.cisco.com [10.21.96.19]) by airborne.cisco.com (Mirapoint) with ESMTP id AEA02528; Fri, 22 Jun 2001 05:12:33 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" Message-ID: <15155.13874.35000.376576@gargle.gargle.HOWL> Date: Fri, 22 Jun 2001 08:12:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Fleischman, Eric W" Cc: "'Cedric Aoun'" , "'Andrew Molitor'" , "'Maciocco, Christian'" , "'richard.swale@bt.com'" , srisuresh@yahoo.com, "'midcom@ietf.org'" Subject: RE: [midcom] middlebox informs agent? In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DC3@XCH-NW-01.nw.nos.boeing.com> References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DC3@XCH-NW-01.nw.nos.boeing.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 21 Jun 2001 at 08:29 -0700, Fleischman, Eric W apparently wrote: > From: Cedric Aoun [mailto:CEDRIC.AOUN@nortelnetworks.com] > Eric > I > thought we agreed to postpone the debates on usage of timers in the > state machines >of Middle Boxes and agent until starting to work on > the protocol spec. > > I wasn't aware of this agreement -- perhaps it occurred during the > weeks the Midcom archives weren't functioning because I did not notice > any mention of it in the archived materials. Cedric made the suggestion and people subsided, so there was a tacit consensus. The issue is still open because it hasn't been documented. > It is my perception that the framework document should provide the > specs for the midcom protocol. We want to provide *requirements* for the midcom protocol, and we do that in the requirements draft. Your text below should be addressed at requirements, with justification. The latest draft came out Thursday. OK, having said that, let's assume the rest of this thread is about the requirements draft ... > More importantly, I want a protocol that is transactional > during setup and transactional during teardown, but which has no state > during the initial negotiation stage to protect against DoS attacks. I > also want to have no state kept within the protocol between setup and > teardown. So far so good -- except I'm confused about state "within the protocol", since protocols are communication, the endpoints keep the state. Do you mean the protocol shouldn't require either end to keep state? And yet, you're requiring timers. But anyway ... > This requires the middlebox itself to keep the timers so > that it could know when a teardown should occur should the Midcom > Agent "disappear" -- as well they might for a variety of reasons. The original issue was that Suresh wanted the middlebox to keep a timer and be responsible for pinging the agent periodically to see if the installed state was still wanted. That was highly debated. There was general agreement that if the agent disappeared the middlebox should clean up, except ... > I am > very surprised that adding these concepts to the framework document is > controversial. It wouldn't be controversial except that someone said he really didn't want middleboxes to be required to delete state if an agent disappeared, that pinholes should be left open for some time. At that point we started talking about general rules which could be installed -- for example allowing the agent to specify exactly what to do with left-over state. Then we kind of petered out, because you get into soft issues like how much complexity is worth it when you don't know how important a particular need is. We can't make this decision right now. I'd like to see this revisited. Could the person who claimed he wanted pinholes left open after the agent disappeared please stand up? > The type of protocol I seek is one that is as simple as possible. I do > not think that the current "state of the art" is mature enough -- > particularly understanding the security implications -- to design an > "all things for all people"-type of protocol which the framework > authors are targeting. I'd like to distinguish here between the protocol being simple and what the protocol carries being simple. Clearly we want a lean and mean transaction-like idempotent protocol. The question we stopped on is how much complexity do we allow in the instructions an agent can pass. In most protocols we handle that by suffering a slight overhead to make it extensible, but not using the extensibility in version 1.0. We need to agree on the midcom protocol requirements. Once we do, I'm looking forward to a succinct summary of requirements, in a nice little table with very little text, so I can have an opinion about how much extensibility to bother with. (Passing over the concerns about youth in the group. At my first IETF there were 14 people.) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 08:33: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 IAA18704 for ; Fri, 22 Jun 2001 08:33:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20987; Fri, 22 Jun 2001 08:32:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20960 for ; Fri, 22 Jun 2001 08:32:21 -0400 (EDT) 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 IAA18621 for ; Fri, 22 Jun 2001 08:31:47 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5MCW0N22345; Fri, 22 Jun 2001 05:32:01 -0700 (PDT) Received: from spandex (rtp-vpn-214.cisco.com [10.82.192.214]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKJ03333; Fri, 22 Jun 2001 05:31:50 -0700 (PDT) Message-ID: <021a01c0fb17$71552940$d45904d1@cisco.com> From: "Melinda Shore" To: "Scott Brim" , "Fleischman, Eric W" Cc: "'Cedric Aoun'" , "'Andrew Molitor'" , "'Maciocco,Christian'" , , , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DC3@XCH-NW-01.nw.nos.boeing.com> <15155.13874.35000.376576@gargle.gargle.HOWL> Subject: Re: [midcom] middlebox informs agent? Date: Fri, 22 Jun 2001 08:32:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > It wouldn't be controversial except that someone said he really didn't > want middleboxes to be required to delete state if an agent disappeared, > that pinholes should be left open for some time. That "he" would be me. That's a sort of a rough paraphrase, Scott. I'm concerned that tearing down state as soon as an agent fails works against fault tolerance. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 08:48: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 IAA19286 for ; Fri, 22 Jun 2001 08:48:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21267; Fri, 22 Jun 2001 08:46:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21238 for ; Fri, 22 Jun 2001 08:46:19 -0400 (EDT) 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 IAA19209 for ; Fri, 22 Jun 2001 08:45:45 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5MCjuh25839 for ; Fri, 22 Jun 2001 05:45:56 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-19.cisco.com [10.21.96.19]) by airborne.cisco.com (Mirapoint) with ESMTP id AEA02659; Fri, 22 Jun 2001 05:45:50 -0700 (PDT) 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: <15155.15860.341000.279056@gargle.gargle.HOWL> Date: Fri, 22 Jun 2001 08:45:40 -0400 To: Subject: Re: [midcom] middlebox informs agent? In-Reply-To: <021a01c0fb17$71552940$d45904d1@cisco.com> References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DC3@XCH-NW-01.nw.nos.boeing.com> <15155.13874.35000.376576@gargle.gargle.HOWL> <021a01c0fb17$71552940$d45904d1@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 22 Jun 2001 at 08:32 -0400, Melinda Shore apparently wrote: > > It wouldn't be controversial except that someone said he really didn't > > want middleboxes to be required to delete state if an agent disappeared, > > that pinholes should be left open for some time. > > That "he" would be me. > > That's a sort of a rough paraphrase, Scott. I'm concerned > that tearing down state as soon as an agent fails works > against fault tolerance. Sorry about "rough". OK, can we work toward consensus on requirements? What specifically is the minimum that is required? Do you want to require, say, the agent to state (in the midcom protocol) the minimum time that installed state should be retained if agent<->middlebox communication is lost (default to 0)? Note that this would be after communication was declared "lost", an interval that hasn't been set yet. I think maybe we should talk about fault tolerance requirements in general first? ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 10:56: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 KAA24047 for ; Fri, 22 Jun 2001 10:56:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25033; Fri, 22 Jun 2001 10:46:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25006 for ; Fri, 22 Jun 2001 10:46:13 -0400 (EDT) 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 KAA23714 for ; Fri, 22 Jun 2001 10:45:37 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5MEjlh00134 for ; Fri, 22 Jun 2001 07:45:48 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-19.cisco.com [10.21.96.19]) by airborne.cisco.com (Mirapoint) with ESMTP id AEA03473; Fri, 22 Jun 2001 07:45:42 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" Message-ID: <15155.23062.417000.170169@gargle.gargle.HOWL> Date: Fri, 22 Jun 2001 10:45:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: In-Reply-To: <200106211059.GAA23161@ietf.org> References: <200106211059.GAA23161@ietf.org> Content-Transfer-Encoding: 7bit Subject: [midcom] draft-ietf-midcom-requirements-01.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 All in all a very good start. There will be lots more requirements, and I believe some of the ones you list will need clarification once we get a more complete list. I have a few issues ... > requested by a MIDCOM Agent. However the Middlebox must not alter > packet information unless it appears in the packet header. This is to > ensure that there is an appropriate separation of concerns between the > MIDCOM Agent and the Middlebox. If I understand what you mean I disagree. Consider the case of FTP through NAT. Are you saying the middlebox must never modify IP addresses in packet payloads? > 4.3. Policy Server functions I see no requirements in this section. > The MIDCOM Protocol should allow the aggregation of commands, requests > and responses. Could you be more specific? What is the requirement which leads to this conclusion? > In conjunction with an appropriate MIDCOM Agent, an application shall > be able to request a pin-hole through a Middlebox. To achieve this, I believe the model is that the application and the agent are separate, and that if the application is making such a request, it is because the agent function is at least apparently co-resident with the application. That is, we are not defining any kind of protocol between application and agent to allow them to work "in conjunction". All of that is beyond our scope. > A given Middlebox may support multiple concurrent trust relationships > with a number of MIDCOM Agents. Resources, such as a Pinhole- > Descriptor, may be shared across MIDCOM Agents and a Middlebox. I don't understand what it means for something to be shared "across agents and a middlebox". What is the base requirement which leads you to suggest this? > As part of the de-registration process, any pin-holes or other > Middlebox resources requested by the MIDCOM Agent must be immediately > released by the Middlebox. This is currently under debate :=) > 7. Application Control Flow Services > > Application Control flows constitute the control aspect of an > application. To enable a Middlebox to correctly handle such flows, > they will need to be routed to a specific MIDCOM Agent that is able > to handle the given application. These flows may be routed between a > physical port on a Middlebox and a specific a MIDCOM Agent. The > establishment of this association will requested via the MIDCOM > protocol or may be determined by policy otherwise applied to the > Middlebox. This is the diversion issue, also under debate. We have the "in-path" model where somehow, in a way we don't know anything about, agents see application control traffic. The model you have here, where agents ask middleboxes to divert packets to them, is going to be put on the shelf for now. I would take this out and simply say (here and in 7.1.1) that the method by which agents get to see application control packets is out of scope for now. > A MIDCOM Agent may be notified when a pin-hole previously granted has > become invalid, such as through a system restart. In this series of statements, when you say "may be", do you mean (1) "might", i.e. this event might happen and the agent must be prepared to deal with it, or (2) "is allowed to", i.e. the agent is allowed to ask to be notified and the middlebox must be able to grant that request if it is made? Or something else? Also, I hope the use is consistent between statements, but it looks like it might vary. For example I believe you mean a midcom agent might hear that a pinhole has become invalid and needs to be prepared to deal with it, but that an agent is allowed to refresh a pinhole grant and a middlebox must be prepared to deal with it. > The MIDCOM communication protocol needs to allow for selective > communication between a specific MIDCOM agent and one or more > Middlebox functions on the interface to which it is connected. Are you saying the protocol must not require multicast? Are you saying protocol messages should contain middlebox identifiers? Or do I not understand at all? > An operation is needed to permit a flow, with a given flow > specification and address translation, across the Middlebox. It shall > be possible to indicate whether packets should be carried or discarded > when a given flow specification is exceeded. Traffic policer/marker/conditioner is a different class of middlefunction than those we've been discussing up to now, and I'm glad to see you want to keep the midcom protocol general enough to support it. > Other than the communication of control information between Middlebox > and an associated MIDCOM Agent, no packets will be allowed to flow > across the Middlebox unless requests by a MIDCOM Agent. i.e. the > default operation is that "no packets should be allowed to cross the > Middlebox". In fact, communication between an agent and a particular mdidlebox won't flow through that middlebox either, so you can leave out "other than ...". Also s/requests/requested/. > The MIDCOM Protocol must allow communications between Middleboxes and > MIDCOM Agents to be authenticated. s/allow/require/ > Since Middleboxes and MIDCOM Agent(s) are likely to operate > asynchronously, the protocol needs to permit the synchronisation of > state machines between peer entities by adding state information to > messages in normal operations or by the use of explicit query > messages. What do you have in mind by synchronization of state machines in this particular case? That is, what specific functions do you think are required for it? > 11.2. Application protocol transport > > To enable the MIDCOM Agent to implement the desired application level > functionality, it may be necessary for the Middlebox to forward IP > packets received on specific IP addresses and/or ports directly to the > MIDCOM Agent. The "diversion" issue again (see above) > h. Define mechanisms to mitigate replay attacks on the control > messages. This is the only security requirement that gives me pause. So far we haven't had a requirement to keep a connection open between agent and middlebox -- just security state at each end. Replay protection would require a lot more lower-level, protocol-related state. Essentially, what do you mean by "mitigate", in concrete terms? Thanks ... Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 11:02:34 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 LAA24426 for ; Fri, 22 Jun 2001 11:02:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25484; Fri, 22 Jun 2001 11:00:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25451 for ; Fri, 22 Jun 2001 11:00:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24178 for ; Fri, 22 Jun 2001 10:59:38 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5MExpx06107; Fri, 22 Jun 2001 07:59:51 -0700 (PDT) Received: from spandex (rtp-vpn-214.cisco.com [10.82.192.214]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKJ05477; Fri, 22 Jun 2001 07:59:45 -0700 (PDT) Message-ID: <02e901c0fb2c$1a817b40$d45904d1@cisco.com> From: "Melinda Shore" To: "Scott Brim" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DC3@XCH-NW-01.nw.nos.boeing.com><15155.13874.35000.376576@gargle.gargle.HOWL><021a01c0fb17$71552940$d45904d1@cisco.com> <15155.15860.341000.279056@gargle.gargle.HOWL> Subject: Re: [midcom] middlebox informs agent? Date: Fri, 22 Jun 2001 11:00:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > Sorry about "rough". OK, can we work toward consensus on requirements? > What specifically is the minimum that is required? Do you want to > require, say, the agent to state (in the midcom protocol) the minimum > time that installed state should be retained if agent<->middlebox > communication is lost (default to 0)? Note that this would be after > communication was declared "lost", an interval that hasn't been set > yet. I dunno - something like a teardown/don't teardown flag. I'd kind of like to see an timer element in general, and it seems to me that that can remain independent of a what-to-do-when-the-agent-disappears hint. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 11:11:31 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 LAA25014 for ; Fri, 22 Jun 2001 11:11:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25829; Fri, 22 Jun 2001 11:09:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25802 for ; Fri, 22 Jun 2001 11:09:42 -0400 (EDT) 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 LAA24887 for ; Fri, 22 Jun 2001 11:09:07 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5MF9LN12152; Fri, 22 Jun 2001 08:09:21 -0700 (PDT) Received: from spandex (rtp-vpn-214.cisco.com [10.82.192.214]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKJ05682; Fri, 22 Jun 2001 08:09:12 -0700 (PDT) Message-ID: <02f001c0fb2d$6cdb8600$d45904d1@cisco.com> From: "Melinda Shore" To: "Scott Brim" , References: <200106211059.GAA23161@ietf.org> <15155.23062.417000.170169@gargle.gargle.HOWL> Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Fri, 22 Jun 2001 11:10:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > > As part of the de-registration process, any pin-holes or other > > Middlebox resources requested by the MIDCOM Agent must be immediately > > released by the Middlebox. > This is currently under debate :=) Something like it, but not this. We were talking (I think) about what to do when the agent disappears without deregistering, which is different from an intentional deregistration. I think. > > The MIDCOM Protocol must allow communications between Middleboxes and > > MIDCOM Agents to be authenticated. > s/allow/require/ Well, we don't really know what "authenticated" means here. For example, in a so-called "trusted network" we might consider any endpoint that's on it implicitly authenticated. I think we need to allow for the possibility of operating in an environment without explicit authentication. > > h. Define mechanisms to mitigate replay attacks on the control > > messages. > This is the only security requirement that gives me pause. We should probably discuss the non-repudiation requirement, too. > So far we > haven't had a requirement to keep a connection open between agent and > middlebox -- just security state at each end. Replay protection would > require a lot more lower-level, protocol-related state. Essentially, > what do you mean by "mitigate", in concrete terms? It may not be necessary, actually, depending on how we define the format of the information being passed. A "give me a pinhole for 10 minutes" request is a lot more vulnerable to replay than a "give me a pinhole from Fri Jun 22 11:07:10 to Fri Jun 22 11:17:10". In the former case you need to retain longitudinal state; in the latter case you might need to compare current state. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 11:19:52 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 LAA25577 for ; Fri, 22 Jun 2001 11:19:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26051; Fri, 22 Jun 2001 11:18:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26018 for ; Fri, 22 Jun 2001 11:18:32 -0400 (EDT) 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 LAA25427 for ; Fri, 22 Jun 2001 11:17:56 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id D5A1E811F; Fri, 22 Jun 2001 09:35:40 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA28635; Fri, 22 Jun 2001 10:18:32 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 22 Jun 2001 10:18:32 -0500 (CDT) From: Andrew Molitor To: Scott Brim Cc: midcom@ietf.org Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt In-Reply-To: <15155.23062.417000.170169@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, 22 Jun 2001, Scott Brim wrote: > All in all a very good start. There will be lots more requirements, and > I believe some of the ones you list will need clarification once we get > a more complete list. I have a few issues ... > > > requested by a MIDCOM Agent. However the Middlebox must not alter > > packet information unless it appears in the packet header. This is to > > ensure that there is an appropriate separation of concerns between the > > MIDCOM Agent and the Middlebox. > > If I understand what you mean I disagree. Consider the case of FTP > through NAT. Are you saying the middlebox must never modify IP > addresses in packet payloads? I think the point is that the middlebox wouldn't mess with the control stream -- that's the 'FTP-aware MIDCOM Agent's job. If a middlebox DOES alter the PORT commands, we should consider that to be an agent contained inside the middlebox. The point, I suspect, is that the middlebox proper CANNOT alter the payloads -- in this case the PORT commands -- because the middlebox proper BY DEFINITION does not know enough (anything) about the FTP control protocol to do that work. A thing which knows enough to do that work is an Agent. > > A given Middlebox may support multiple concurrent trust relationships > > with a number of MIDCOM Agents. Resources, such as a Pinhole- > > Descriptor, may be shared across MIDCOM Agents and a Middlebox. > > I don't understand what it means for something to be shared "across > agents and a middlebox". What is the base requirement which leads you > to suggest this? I read this as allowing one Agent to, for example, remove a pinhole created by another. This is obviously necessary for fault tolerant configurations. > > h. Define mechanisms to mitigate replay attacks on the control > > messages. > > This is the only security requirement that gives me pause. So far we > haven't had a requirement to keep a connection open between agent and > middlebox -- just security state at each end. Replay protection would > require a lot more lower-level, protocol-related state. Essentially, > what do you mean by "mitigate", in concrete terms? Replay attacks are the single most dangerous type of attack in this context. If I can re-open a specific pinhole at will, you are COMPLETELY sunk. If MIDCOM doesn't support enough crypto juice to make replay attacks crypto-hard to mount, it's a useless toy. Having worked on the design, implementation, and deployment of one of these things I see no way around maintaining some type of connection state between Agent and Middlebox. It doesn't have to be heavy state, but it needs to do enough stuff with connect/authenticate and then sequence numbering and crypto stuff to make it work securely. If someone can show me how to do it statelessly, securely, and efficiently, it'll make the happiest boy in town! Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 11:21: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 LAA25654 for ; Fri, 22 Jun 2001 11:21:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26090; Fri, 22 Jun 2001 11:19:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26063 for ; Fri, 22 Jun 2001 11:19:15 -0400 (EDT) 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 LAA25503 for ; Fri, 22 Jun 2001 11:18:39 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5MFInh20687; Fri, 22 Jun 2001 08:18:49 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-19.cisco.com [10.21.96.19]) by airborne.cisco.com (Mirapoint) with ESMTP id AEA03816; Fri, 22 Jun 2001 08:18:43 -0700 (PDT) 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: <15155.25045.18000.553080@gargle.gargle.HOWL> Date: Fri, 22 Jun 2001 11:18:45 -0400 To: "Melinda Shore" Cc: Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt In-Reply-To: <02f001c0fb2d$6cdb8600$d45904d1@cisco.com> References: <200106211059.GAA23161@ietf.org> <15155.23062.417000.170169@gargle.gargle.HOWL> <02f001c0fb2d$6cdb8600$d45904d1@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 22 Jun 2001 at 11:10 -0400, Melinda Shore apparently wrote: > > > As part of the de-registration process, any pin-holes or other > > > Middlebox resources requested by the MIDCOM Agent must be immediately > > > released by the Middlebox. > > This is currently under debate :=) > > Something like it, but not this. We were talking > (I think) about what to do when the agent disappears > without deregistering, which is different from an > intentional deregistration. I think. Good point. > > > > The MIDCOM Protocol must allow communications between Middleboxes and > > > MIDCOM Agents to be authenticated. > > s/allow/require/ > > Well, we don't really know what "authenticated" means here. > For example, in a so-called "trusted network" we might consider > any endpoint that's on it implicitly authenticated. I think > we need to allow for the possibility of operating in an > environment without explicit authentication. Hmm, yup, and the draft says so later. > > > h. Define mechanisms to mitigate replay attacks on the control > > > messages. > > This is the only security requirement that gives me pause. > > We should probably discuss the non-repudiation requirement, > too. They have limited the non-repudiation requirement to where the agent-middlebox relationship also crosses administration (money) boundaries. Also the requirement is that the protocol "support" it, which at this point could simply mean leave room for it. I thought the non-repudiation requirement was pretty well phrased. > > So far we > > haven't had a requirement to keep a connection open between agent and > > middlebox -- just security state at each end. Replay protection would > > require a lot more lower-level, protocol-related state. Essentially, > > what do you mean by "mitigate", in concrete terms? > > It may not be necessary, actually, depending on how we define > the format of the information being passed. A "give me a pinhole > for 10 minutes" request is a lot more vulnerable to replay than > a "give me a pinhole from Fri Jun 22 11:07:10 to Fri Jun 22 11:17:10". > In the former case you need to retain longitudinal state; in > the latter case you might need to compare current state. That would be excellent. Thanks ... Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 11:31: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 LAA26252 for ; Fri, 22 Jun 2001 11:31:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26549; Fri, 22 Jun 2001 11:30:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26515 for ; Fri, 22 Jun 2001 11:30:22 -0400 (EDT) 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 LAA26063 for ; Fri, 22 Jun 2001 11:29:44 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5MFTth27902; Fri, 22 Jun 2001 08:29:55 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-19.cisco.com [10.21.96.19]) by airborne.cisco.com (Mirapoint) with ESMTP id AEA03926; Fri, 22 Jun 2001 08:29:48 -0700 (PDT) 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: <15155.25710.65000.999183@gargle.gargle.HOWL> Date: Fri, 22 Jun 2001 11:29:50 -0400 To: Andrew Molitor Cc: midcom@ietf.org Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt In-Reply-To: References: <15155.23062.417000.170169@gargle.gargle.HOWL> 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 22 Jun 2001 at 10:18 -0500, Andrew Molitor apparently wrote: > On Fri, 22 Jun 2001, Scott Brim wrote: > > > requested by a MIDCOM Agent. However the Middlebox must not alter > > > packet information unless it appears in the packet header. This is to > > > ensure that there is an appropriate separation of concerns between the > > > MIDCOM Agent and the Middlebox. > > > > If I understand what you mean I disagree. Consider the case of FTP > > through NAT. Are you saying the middlebox must never modify IP > > addresses in packet payloads? > > I think the point is that the middlebox wouldn't mess with the > control stream -- that's the 'FTP-aware MIDCOM Agent's job. If a middlebox > DOES alter the PORT commands, we should consider that to be an agent > contained inside the middlebox. I agree with that, and that may be what the authors intended but if so then could it be reworded? This is the first paragraph of 4.1 on Middlebox Functions. It looks like a fundamental statement that middleboxes manipulate headers but not payload. > > > A given Middlebox may support multiple concurrent trust relationships > > > with a number of MIDCOM Agents. Resources, such as a Pinhole- > > > Descriptor, may be shared across MIDCOM Agents and a Middlebox. > > > > I don't understand what it means for something to be shared "across > > agents and a middlebox". What is the base requirement which leads you > > to suggest this? > > I read this as allowing one Agent to, for example, remove > a pinhole created by another. This is obviously necessary for fault > tolerant configurations. OK > > > h. Define mechanisms to mitigate replay attacks on the control > > > messages. > > > > This is the only security requirement that gives me pause. So far we > > haven't had a requirement to keep a connection open between agent and > > middlebox -- just security state at each end. Replay protection would > > require a lot more lower-level, protocol-related state. Essentially, > > what do you mean by "mitigate", in concrete terms? > > Replay attacks are the single most dangerous type of attack > in this context. If I can re-open a specific pinhole at will, you are > COMPLETELY sunk. If MIDCOM doesn't support enough crypto juice to > make replay attacks crypto-hard to mount, it's a useless toy. > > Having worked on the design, implementation, and deployment of > one of these things I see no way around maintaining some type of > connection state between Agent and Middlebox. It doesn't have to be > heavy state, but it needs to do enough stuff with connect/authenticate > and then sequence numbering and crypto stuff to make it work securely. > > If someone can show me how to do it statelessly, securely, and > efficiently, it'll make the happiest boy in town! (swb looks to the security wizards for a great answer) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 17:36: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 RAA12213 for ; Fri, 22 Jun 2001 17:36:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08561; Fri, 22 Jun 2001 17:33:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08533 for ; Fri, 22 Jun 2001 17:33:56 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12062 for ; Fri, 22 Jun 2001 17:33:20 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A94D19C01C0; Fri, 22 Jun 2001 17:31:57 -0400 Message-ID: <010901c0fb63$16edef40$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" Subject: [midcom] draft-ietf-midcom-requirements-01.txt Date: Fri, 22 Jun 2001 17:34:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 I am very encouraged by the progress made in this draft. I have a number of questions/issues that follow. Some are related to those discussed by Scott, Melinda, and Andrew, but I will add my two cents. In section 4.1, it says: The Middlebox must support the explicit forwarding of application control session information received on one, or more, destination address/port combinations to an appropriate MIDCOM Agent(e.g. an application gateway) as described in section 7. This sounds a lot like the Out-of-path agents and diversion functions that have been debated over the last week or so. In-path agents will not require this because they are explicit targets of the flow. Also, to me, section 7.1.1 states that diversion is the only way to get packets to the MIDCOM agent. With in-path agents, we only need to NAT or admit the control flow so that it can reach the in-path agent. This is the same function we need to get data flows thru the middlebox. I do not see a need to make an explicit distinction in the protocol between control flows and content flows. The pin-hole request to allow the control flow thru to an in-path agent is basically the same as a pin-hole request to allow the content flow thru for a given session. Why does the middlebox need to know that one pin-hole is for control flow and the other is for content flow? Section 5.2.2 mentions an identification of pin-holes, but I think we also need to consider a session identification to associate multiple pin-holes/flows with a session. This will be quite helpful when the MIDCOM agent wants to update pin-holes specs (e.g. extend timers) or terminate all the pin-holes for a given session. Section 5.3.2 states that all pin-holes associated with a MIDCOM agent need to be closed when the communication between the MIDCOM agent and the middlebox is broken. This breaks redundancy and high availability where a MIDCOM agent needs to failover without losing stable sessions. I think the pin-hole specification needs to include an indication of whether or not the pin-hole should be closed if the MIDCOM session with the MIDCOM agents terminates. We need to consider the case when the MIDCOM agent fails and when the MIDCOM Agent closes the connection normally. We should be able to maintain the pin-holes in both cases (e.g. operator initiated switchover from one MIDCOM agent to another). The normal close might include an indication of whether pin-holes should be maintained. This is related to the requirements that the middlebox resources can be shared by multiple MIDCOM Agents. If one MIDCOM Agent can open a pin-hole and a different MIDCOM Agent can close it, we might want to leave the pin-hole open when one of the agents goes away and the let another MIDCOM agent close the pin-hole when the session is truly over. In section 5.5, what does "Application Stream Session" mean? Section 6.2 talks about Deregistration. Is this suppose to be an explicit function or is this normal closing of the MIDCOM Session? If it is normal closing, I disagree with the requirement to close all the pin holes (see above). I think the last paragraph of section 9 places a requirement on the middlebox that is outside the scope of the protocol requirements. Whether or not a middlebox allows packets across itself is up to the middlebox's own policy configuration. This statement basically says that only pin-hole specs installed by MIDCOM agents are allowed. Section 10.5 says that MIDCOM agents talk to MIDCOM policy servers, but figure 1 shows the middlebox talking to the policy server. I believe figure 1 matches the picture and text in the framework draft. Section 10.8 seems to be more about inter-version interoperability rather than extensibility. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 18:32: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 SAA13742 for ; Fri, 22 Jun 2001 18:32:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09714; Fri, 22 Jun 2001 18:29:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09685 for ; Fri, 22 Jun 2001 18:29:19 -0400 (EDT) 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 SAA13639 for ; Fri, 22 Jun 2001 18:28:42 -0400 (EDT) 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 PAA29096 for ; Fri, 22 Jun 2001 15:28:48 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA19714 for ; Fri, 22 Jun 2001 15:28:49 -0700 Message-ID: <3B33C33B.985C24B7@hursley.ibm.com> Date: Fri, 22 Jun 2001 17:14:19 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr 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] Re: draft-ietf-midcom-requirements-01.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 In section 5.2.1 (pinhole specification) > For IPv4: source and destination IP address or group of > them determined by a netmask, protocol number, > TOS field This should be "differentiated services code point" since RFC 2474 updates RFC 791, and you have to be very careful to exclude the ECN bits. > > For IPv6: source and destination IP address or group of > them determined by a netmask, next header fields > (Note: multiple fields may need to be traversed > until a match is found)and traffic class field I think the IPv6 Flow Label needs to be included too. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 20:39:04 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 UAA16912 for ; Fri, 22 Jun 2001 20:38:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12680; Fri, 22 Jun 2001 20:36:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12649 for ; Fri, 22 Jun 2001 20:36:25 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16857 for ; Fri, 22 Jun 2001 20:35:49 -0400 (EDT) Received: from 157.54.1.52 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Jun 2001 17:33:23 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 22 Jun 2001 17:35:00 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 22 Jun 2001 17:34:58 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 22 Jun 2001 17:34:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Fri, 22 Jun 2001 17:34:31 -0700 Message-ID: Thread-Topic: [midcom] draft-ietf-midcom-requirements-01.txt Thread-Index: AcD7LrWq/9SmGKMfRiu8mJgKETsKhAAQHiNw From: "Christian Huitema" To: X-OriginalArrivalTime: 23 Jun 2001 00:34:32.0004 (UTC) FILETIME=[45173840:01C0FB7C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA12650 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: 8bit First, the obvious. The draft appears to not be written in ASCII -- there are quite a few strange characters in it. Could someone fix that? Also, could someone fix the title? This should be strictly a protocol requirement document, not a "protocol architecture" document. Next comment concerns the figure on page 6. The "Application Control Flow" line should be removed. It it a throw back of the "OOP" debate; we debated that OOP should maybe be mentioned in the framework with due precautions; it certainly does not belong in the requirements. Similarly, the paragraph that states that "The Middlebox must support the explicit forwarding of application control session information" should be removed, as well as the whole of section 7. Section 5.1 has a paragraph about direction, essentially stating that flows should be directional. I don't think that we have any consensus on this. Indeed, if you look at the scenario documents, there is not a single example in which directional flows could be useful. Do we really want to enable communication one way without enabling it the other way? I think that this paragraph should be removed from the requirements. Similarly, flow direction should be removed from the pin-hole requirements in section 5.2. On pin-hole requirements, page 8, the reference to "netmask" should be replaced by a reference to subnet prefix; for IPv6, the reference should be to "payload type" rather than "next header type." The paragraph on direction shall be removed. The reference to TOS bits is questionable -- if this is a requirement to the protocol, we have better make sure that using or heeding such specification is optional. The role of section 8 is debatable. There is no requirement for any of the "Application Content Flow Services" in any of the scenarios. At a more general level, I find that the document is poorly organized, and is by no means a complete requirement document. Both section 5, General Protocol Requirements, and section 6, Agent and Middlebox association, fall in the classic mistake of explaining "how" rather than explaining "what", i.e. proposing an architecture rather than proposing an actual list of requirements. This is quite bad, since we loose a lot of the rationales developed in the working group. The requirements should be derived from the framework and the scenarios; in fact, the scenario and requirement drafts should be merged. The requirement themselves should be split in three sections, functional requirement, i.e. how to pass enough data to make the scenario work, security requirements, and operational requirements, i.e. how to meet various performance and stability constraints. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 21: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 VAA17715 for ; Fri, 22 Jun 2001 21:31:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13808; Fri, 22 Jun 2001 21:29:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13779 for ; Fri, 22 Jun 2001 21:29:26 -0400 (EDT) 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 VAA17664 for ; Fri, 22 Jun 2001 21:28:50 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id D49F881F4 for ; Fri, 22 Jun 2001 20:29:26 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id UAA02892 for ; Fri, 22 Jun 2001 20:29:26 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 22 Jun 2001 20:29:26 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt 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, 22 Jun 2001, Christian Huitema wrote: > Similarly, the paragraph that states that "The Middlebox must support > the explicit forwarding of application control session information" > should be removed, as well as the whole of section 7. I seem to recall that: - OOP as a concept was voted down, or at any rate demoted to a passing mention in the framework - a couple of people (my included) suggested that it should be resurrected as a requirement for a packet diversion function on par with Pinholes and NAT. If there was any substantial discussion on the latter, I missed it. > Section 5.1 has a paragraph about direction, essentially stating that > flows should be directional. I don't think that we have any consensus on > this. Indeed, if you look at the scenario documents, there is not a > single example in which directional flows could be useful. Do we really > want to enable communication one way without enabling it the other way? > I think that this paragraph should be removed from the requirements. > Similarly, flow direction should be removed from the pin-hole > requirements in section 5.2. RTP media flows are in practice often unidirectional. Yes, it is useful and desirable to allow one-way flows. The scenario documents should be updated to reflect this, if they do not. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 22:21:07 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 WAA19200 for ; Fri, 22 Jun 2001 22:21:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15082; Fri, 22 Jun 2001 22:16:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15047 for ; Fri, 22 Jun 2001 22:16:02 -0400 (EDT) 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 WAA19167 for ; Fri, 22 Jun 2001 22:15:26 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id D3C1E8122 for ; Fri, 22 Jun 2001 20:32:56 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id VAA03878 for ; Fri, 22 Jun 2001 21:16:02 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 22 Jun 2001 21:16:02 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt 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, 22 Jun 2001, Christian Huitema wrote: > Uh, which RTP media flow are unidirectional? AFAIK, SIP does not have > any provision for unidirectional flows. It turns out that, in practice, your average SIP phone simply sends UDP packets to the Other Phone at whatever port that phone said to use. Of course the same thing happens the other way around at the same time, but this is (in general) two unidirectional flows, not one bidirectional one. It happens that this example is the only example I have of useful indirectional traffic, but it's near and dear to my heart. Rosenberg et al are currently working on support for truly bidirectional RTP media (that is, where the audio I send your phone, and the audio you send my phone, make up between them a bidirectional flow), but it's not here yet. Also, it turns out that 'many devices' tend to send from the same port they receive on, so if you get two such devices (in the absence of middlebox-NATs) it comes out looking like a single bidirectional flow. This behavior is not (yet) guaranteed, and I think the 'two unidirectional flows' will always be permitted in SIP voice usage. Andrew P.S. There is a hypothesis around my workplace that ALL SIP deployment problems manifest as a 'one-way-media problem' in which one end can hear the other, but not vice-versa. This is an expression of the fact that it's startlingly easy to get your network set up, especially with a NAT middlebox, so that one of the two unidirectional audio streams flows and the other one does not. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 22:41: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 WAA20416 for ; Fri, 22 Jun 2001 22:41:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15685; Fri, 22 Jun 2001 22:39:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15616 for ; Fri, 22 Jun 2001 22:39:24 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20297 for ; Fri, 22 Jun 2001 22:38:47 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Jun 2001 19:02:07 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Jun 2001 18:56:07 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 22 Jun 2001 18:56:06 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Jun 2001 18:55:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Fri, 22 Jun 2001 18:55:37 -0700 Message-ID: Thread-Topic: [midcom] draft-ietf-midcom-requirements-01.txt Thread-Index: AcD7hlo+B51FYSNGQoWYL+KWtClWSwAATOnw From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 23 Jun 2001 01:55:38.0461 (UTC) FILETIME=[99B9A0D0:01C0FB87] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA15617 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: 8bit Uh, which RTP media flow are unidirectional? AFAIK, SIP does not have any provision for unidirectional flows. > -----Original Message----- > From: Andrew Molitor [mailto:amolitor@visi.com] > Sent: Friday, June 22, 2001 6:29 PM > To: midcom@ietf.org > Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt > > > On Fri, 22 Jun 2001, Christian Huitema wrote: > > > Similarly, the paragraph that states that "The Middlebox must support > > the explicit forwarding of application control session information" > > should be removed, as well as the whole of section 7. > > I seem to recall that: > > - OOP as a concept was voted down, or at any rate demoted to > a passing mention in the framework > - a couple of people (my included) suggested that it should > be resurrected as a requirement for a packet diversion > function on par with Pinholes and NAT. > > If there was any substantial discussion on the latter, I missed > it. > > > Section 5.1 has a paragraph about direction, essentially stating that > > flows should be directional. I don't think that we have any consensus on > > this. Indeed, if you look at the scenario documents, there is not a > > single example in which directional flows could be useful. Do we really > > want to enable communication one way without enabling it the other way? > > I think that this paragraph should be removed from the requirements. > > Similarly, flow direction should be removed from the pin-hole > > requirements in section 5.2. > > RTP media flows are in practice often unidirectional. > Yes, it is useful and desirable to allow one-way flows. The scenario > documents should be updated to reflect this, if they do not. > > > Andrew > > > _______________________________________________ > 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 Jun 22 22:41: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 WAA20429 for ; Fri, 22 Jun 2001 22:41:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15648; Fri, 22 Jun 2001 22:39:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15611 for ; Fri, 22 Jun 2001 22:39:24 -0400 (EDT) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20296 for ; Fri, 22 Jun 2001 22:38:47 -0400 (EDT) Received: from BobP (h-64-105-48-14.cmbrmaor.covad.net [64.105.48.14]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with ESMTP id f5N2dNV49876; Fri, 22 Jun 2001 22:39:24 -0400 Message-ID: <005501c0fb8d$c8005780$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" , "Christian Huitema" References: Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Fri, 22 Jun 2001 22:39:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 ----- Original Message ----- From: "Christian Huitema" To: Sent: Friday, June 22, 2001 8:34 PM Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt > First, the obvious. The draft appears to not be written in ASCII -- > there are quite a few strange characters in it. Could someone fix that? > Also, could someone fix the title? This should be strictly a protocol > requirement document, not a "protocol architecture" document. > > Next comment concerns the figure on page 6. The "Application Control > Flow" line should be removed. It it a throw back of the "OOP" debate; we > debated that OOP should maybe be mentioned in the framework with due > precautions; it certainly does not belong in the requirements. > Similarly, the paragraph that states that "The Middlebox must support > the explicit forwarding of application control session information" > should be removed, as well as the whole of section 7. I agree that section 7 is not needed, except the requirements in 7.1 (but not 7.1.1) should apply for any kind of flow. > > Section 5.1 has a paragraph about direction, essentially stating that > flows should be directional. I don't think that we have any consensus on > this. Indeed, if you look at the scenario documents, there is not a > single example in which directional flows could be useful. Do we really > want to enable communication one way without enabling it the other way? Yes actually. The RTP flows set up by SIP are uni-directional. There will be a separate pin-hole for each direction. Also, the pin-hole spec for RTP will have to allow any source address to the destination address and port in the SDP since SDP does not contain the source address for the RTP. In this case I think knowing the direction of the flow can at least limit the "any source address" to the side that we know the RTP packets for that flow should be coming from. > I think that this paragraph should be removed from the requirements. > Similarly, flow direction should be removed from the pin-hole > requirements in section 5.2. > > On pin-hole requirements, page 8, the reference to "netmask" should be > replaced by a reference to subnet prefix; for IPv6, the reference should > be to "payload type" rather than "next header type." The paragraph on > direction shall be removed. The reference to TOS bits is questionable -- > if this is a requirement to the protocol, we have better make sure that > using or heeding such specification is optional. > > The role of section 8 is debatable. There is no requirement for any of > the "Application Content Flow Services" in any of the scenarios. > > At a more general level, I find that the document is poorly organized, > and is by no means a complete requirement document. Both section 5, > General Protocol Requirements, and section 6, Agent and Middlebox > association, fall in the classic mistake of explaining "how" rather than > explaining "what", i.e. proposing an architecture rather than proposing > an actual list of requirements. This is quite bad, since we loose a lot > of the rationales developed in the working group. The requirements > should be derived from the framework and the scenarios; in fact, the > scenario and requirement drafts should be merged. The requirement > themselves should be split in three sections, functional requirement, > i.e. how to pass enough data to make the scenario work, security > requirements, and operational requirements, i.e. how to meet various > performance and stability constraints. > > -- Christian Huitema > > > _______________________________________________ > 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 Jun 22 22:56:17 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 WAA20512 for ; Fri, 22 Jun 2001 22:56:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15918; Fri, 22 Jun 2001 22:54:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15885 for ; Fri, 22 Jun 2001 22:54:54 -0400 (EDT) Received: from smtp.eyematic.com (root@[38.186.83.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20492 for ; Fri, 22 Jun 2001 22:54:18 -0400 (EDT) Received: from la-exch-001.la.int.eyematic.com (la-exch-001.la.int.eyematic.com [38.186.83.55]) by smtp.eyematic.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id f5N2tHe32646; Fri, 22 Jun 2001 19:55:17 -0700 content-class: urn:content-classes:message Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 22 Jun 2001 19:54:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <11C75CC6CCB5AB44898CBCA2865C235103472A@la-exch-001.la.int.eyematic.com> Thread-Topic: [midcom] draft-ietf-midcom-requirements-01.txt Thread-Index: AcD7i1ZVUshAfZhFS+Gh2+Pm2jRl8gAA0MFA From: "Tim Dorcey" To: "Andrew Molitor" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA15886 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: 8bit On Friday, June 22, 2001, Andrew Molitor wrote: > > It turns out that, in practice, your average SIP phone > simply sends UDP packets to the Other Phone at whatever port that > phone said to use. Of course the same thing happens the other way And, if the Other Phone is not reachable, or does not want your data, the average SIP phone keeps sending away until the operator stops it? I always thought it was a good principle to not send significant amounts of data anywhere without direct confirmation that it is arriving and is useable. Good thing your average SIP phone is not yet sending video. Tim _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 22 23:35: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 XAA21347 for ; Fri, 22 Jun 2001 23:35:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16954; Fri, 22 Jun 2001 23:33:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16928 for ; Fri, 22 Jun 2001 23:33:56 -0400 (EDT) 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 XAA21324 for ; Fri, 22 Jun 2001 23:33:20 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 2F7B78231 for ; Fri, 22 Jun 2001 20:16:14 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id UAA02672 for ; Fri, 22 Jun 2001 20:16:14 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 22 Jun 2001 20:16:13 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt In-Reply-To: <010901c0fb63$16edef40$2300000a@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, 22 Jun 2001, Bob Penfield wrote: > I do not see a need to make an explicit distinction in the protocol between > control flows and content flows. The pin-hole request to allow the control > flow thru to an in-path agent is basically the same as a pin-hole request to > allow the content flow thru for a given session. Why does the middlebox need > to know that one pin-hole is for control flow and the other is for content > flow? This is an excellent point. A reasonable way to deploy these things (in the fullness of time when this is all mature) would be to set up the middlebox as a completely opaque box which passes NO traffic. As Agents for various protocols come up, or notice that the middlebox is up, they would open static pinholes for themselves. For example, the Enterprise' SIP proxy would open pinholes for UDP and TCP port 5060 to itself, and so on. As another example, there is a pretty neat workable model for IP Centrex (where the SIP registrar function is 'outside' the middlebox) which involves the external device opening pinholes and doing NAT bindings to send signaling to individual phones on the inside, on a call-by-call basis. The middlebox definitely should NOT know or care which pinholes are used for what. More or less by definition, it cannot know. > Section 5.2.2 mentions an identification of pin-holes, but I think we also > need to consider a session identification to associate multiple > pin-holes/flows with a session. This will be quite helpful when the MIDCOM > agent wants to update pin-holes specs (e.g. extend timers) or terminate all > the pin-holes for a given session. This appeared in my defunct and unlamented bullet list of requirements. It's an absolute requirement for high capacity IP telephony environments, but I don't know how useful it is anywhere else. My opinion is that the protocol must support it, but Agents don't need to use it, and middleboxes don't need to implement it. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jun 23 08:12: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 IAA09929 for ; Sat, 23 Jun 2001 08:12:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06899; Sat, 23 Jun 2001 08:11:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06869 for ; Sat, 23 Jun 2001 08:11:11 -0400 (EDT) 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 IAA09910 for ; Sat, 23 Jun 2001 08:10:31 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5NC91H10152; Sat, 23 Jun 2001 05:09:01 -0700 (PDT) Received: from spandex (rtp-vpn-53.cisco.com [10.82.192.53]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKR02876; Sat, 23 Jun 2001 05:10:36 -0700 (PDT) Message-ID: <007a01c0fbdd$a4e09620$d45904d1@cisco.com> From: "Melinda Shore" To: "Andrew Molitor" , References: Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Sat, 23 Jun 2001 08:11:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > RTP media flows are in practice often unidirectional. > Yes, it is useful and desirable to allow one-way flows. The scenario > documents should be updated to reflect this, if they do not. It's not clear to me why directionality can't be expressed in terms of source/destination. I have a little trouble with the concept of inside/outside. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jun 23 11:49: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 LAA12463 for ; Sat, 23 Jun 2001 11:49:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13218; Sat, 23 Jun 2001 11:47:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13190 for ; Sat, 23 Jun 2001 11:47:24 -0400 (EDT) Received: from pimout3-int.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12453 for ; Sat, 23 Jun 2001 11:46:45 -0400 (EDT) Received: from BobP (h-64-105-48-14.cmbrmaor.covad.net [64.105.48.14]) by pimout3-int.prodigy.net (8.11.0/8.11.0) with ESMTP id f5NFlKe44708; Sat, 23 Jun 2001 11:47:20 -0400 Message-ID: <003401c0fbfb$daa3b9e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Melinda Shore" , "Andrew Molitor" , References: <007a01c0fbdd$a4e09620$d45904d1@cisco.com> Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Sat, 23 Jun 2001 11:47:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Melinda Shore" To: "Andrew Molitor" ; Sent: Saturday, June 23, 2001 8:11 AM Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt > > RTP media flows are in practice often unidirectional. > > Yes, it is useful and desirable to allow one-way flows. The scenario > > documents should be updated to reflect this, if they do not. > > It's not clear to me why directionality can't be expressed > in terms of source/destination. I have a little trouble > with the concept of inside/outside. I think direction is very important especially for middleboxes at the borders between networks. If a middlebox is just a "bump on the wire" with two network interfaces, packets arrriving at one interface that match a pin-hole spec are sent out the other interface. In order to ensure the desired packet forwarding/admission, the pin-hole would need to be associated with the interface that the packets would be arriving on. Packets arriving on the other interface that happen to match the source address prefix/mask for that pin-hole spec would be blocked. (-:bob > > 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 Sun Jun 24 08:13:08 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 IAA10635 for ; Sun, 24 Jun 2001 08:13:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19845; Sun, 24 Jun 2001 08:02:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19817 for ; Sun, 24 Jun 2001 08:02:04 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10355 for ; Sun, 24 Jun 2001 08:01:20 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5OC1Zx21005; Sun, 24 Jun 2001 05:01:35 -0700 (PDT) Received: from spandex (rtp-vpn-113.cisco.com [10.82.192.113]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKR07472; Sun, 24 Jun 2001 05:01:10 -0700 (PDT) Message-ID: <010401c0fca5$7e047a80$d45904d1@cisco.com> From: "Melinda Shore" To: "Bob Penfield" , "Andrew Molitor" , References: <007a01c0fbdd$a4e09620$d45904d1@cisco.com> <003401c0fbfb$daa3b9e0$2300000a@acmepacket.com> Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Sun, 24 Jun 2001 08:02:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > In order to ensure the > desired packet forwarding/admission, the pin-hole would need to be > associated with the interface that the packets would be arriving on. Packets > arriving on the other interface that happen to match the source address > prefix/mask for that pin-hole spec would be blocked. I think we're saying the same thing. Given that we've got source addresses and destination addresses in the IP headers, isn't putting additional directionality information redundant (and potentially confusing if there are conflicts)? Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Jun 24 08:39: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 IAA10996 for ; Sun, 24 Jun 2001 08:39:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20108; Sun, 24 Jun 2001 08:29:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20078 for ; Sun, 24 Jun 2001 08:29:20 -0400 (EDT) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10829 for ; Sun, 24 Jun 2001 08:28:40 -0400 (EDT) Received: from BobP (h-64-105-48-14.cmbrmaor.covad.net [64.105.48.14]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with ESMTP id f5OCTFV100396; Sun, 24 Jun 2001 08:29:15 -0400 Message-ID: <001701c0fca9$57fdd760$2300000a@acmepacket.com> From: "Bob Penfield" To: "Melinda Shore" , "Andrew Molitor" , References: <007a01c0fbdd$a4e09620$d45904d1@cisco.com> <003401c0fbfb$daa3b9e0$2300000a@acmepacket.com> <010401c0fca5$7e047a80$d45904d1@cisco.com> Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Sun, 24 Jun 2001 08:29:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Melinda Shore" To: "Bob Penfield" ; "Andrew Molitor" ; Sent: Sunday, June 24, 2001 8:02 AM Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt > > In order to ensure the > > desired packet forwarding/admission, the pin-hole would need to be > > associated with the interface that the packets would be arriving on. Packets > > arriving on the other interface that happen to match the source address > > prefix/mask for that pin-hole spec would be blocked. > > I think we're saying the same thing. Given that > we've got source addresses and destination addresses > in the IP headers, isn't putting additional directionality > information redundant (and potentially confusing if there > are conflicts)? I think you missed my point. What about a spoofed source address? Granted that stops only one kind of attack on only one side of the middlebox. Also, with all the multi-homing, redundant links and other kinds of complex routing isn't it possible, if the middlebox represents the destination address of a packet, that packets with the same source and destination could arrive at either side. Maybe that's a stretch, but I'm not a routing expert. If I am implementing a middlebox, being able to have a separate pin-hole tables for each interface is more efficient. Theses boxes usually need to operate at or near wire-speed. (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Jun 24 08:45: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 IAA11075 for ; Sun, 24 Jun 2001 08:45:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20433; Sun, 24 Jun 2001 08:35:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20400 for ; Sun, 24 Jun 2001 08:35:31 -0400 (EDT) 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 IAA10943 for ; Sun, 24 Jun 2001 08:34:51 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5OCXKH08035; Sun, 24 Jun 2001 05:33:21 -0700 (PDT) Received: from spandex (rtp-vpn-113.cisco.com [10.82.192.113]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKR07536; Sun, 24 Jun 2001 05:34:45 -0700 (PDT) Message-ID: <013601c0fcaa$2f1ddce0$d45904d1@cisco.com> From: "Melinda Shore" To: "Bob Penfield" , References: <007a01c0fbdd$a4e09620$d45904d1@cisco.com> <003401c0fbfb$daa3b9e0$2300000a@acmepacket.com> <010401c0fca5$7e047a80$d45904d1@cisco.com> <001701c0fca9$57fdd760$2300000a@acmepacket.com> Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Sun, 24 Jun 2001 08:35:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 think you missed my point. What about a spoofed source address? Spoofed source addresses can be (and are today) handled by ingress and egress filtering at the interface. See sections 4.3 and 4.4 of RFC 3013. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Jun 24 13:47: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 NAA13662 for ; Sun, 24 Jun 2001 13:47:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25974; Sun, 24 Jun 2001 13:38:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25948 for ; Sun, 24 Jun 2001 13:38:57 -0400 (EDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13590 for ; Sun, 24 Jun 2001 13:38:18 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA29712 for ; Sun, 24 Jun 2001 12:39:40 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Sun, 24 Jun 2001 12:32:18 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Jun 2001 12:38:04 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BBFE1@crchy271.us.nortel.com> From: "Sanjoy Sen" To: "'midcom@ietf.org'" Cc: "Mary Barnes" Subject: FW: [midcom] Framework draft review Date: Sun, 24 Jun 2001 12:38:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FCD4.6ACB5270" X-Orig: 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_001_01C0FCD4.6ACB5270 Content-Type: text/plain; charset="iso-8859-1" Had posted this to the mailing list about a week back. Not sure whether it reached the authors as I didn't get any response from them. Rgds, Sanjoy Subject: RE: [midcom] Framework draft review Here're some feedback from myself & Mary Barnes on the Framework draft. Please find our comments within the delimiters, such as [SS] and [/SS]. Regards, Sanjoy ======================= 1. Introduction ---------------- 3rd sentence: Network Address Translator service, on the other hand, provides routing transparency across address realms (within IPv4 routing network or across V4 and V6 routing realms). Application Level gateways (ALGs) are used in conjunction with NAT to provide end-to-end transparency for many of the applications. [MB] I think this has already been discussed before, but transparency is not a term here for either of these sentences. I would suggest rewording these 2 sentences as: The address mapping of Network Address Translation (within IPv4 routing network or across V4 and V6 routing realms), however, is independent from the end application. An Application Level Gateway (ALG) used in conjunction with NAT can remove the knowledge of NATs for applications for which NATs are problematic. [/MB] 2.5. Proxy A proxy is an intermediate relay agent between clients and servers of an application, relaying application messages between the two. Proxies use special protocol mechanisms to communicate with proxy clients and relay client data to servers and vice versa. [SS] The proxies described here are application layer proxies. There're other types of proxies which relays the transport stream (Transport layer proxies), such as an RTP proxy, without higher layer application awareness. These two types should perhaps be distinguished. The reason is that while application layer proxies can be a type of Midcom agent, the transport layer proxies can be a type of Middle-Box (and I think that Midcom is a general framework with the eventual goal of addressing all kinds of Middleboxes). Proxies which are application-unaware but need application-specific intelligence are also Middle-boxes. [/SS] 2.8. MIDCOM Agents MIDCOM agents are entities performing ALG function, ... [SS] Why only ALG's? Application layer proxies (since you've distinguished between ALG's & proxies) can also be Midcom agents, as you've provided some examples in the next paragraph. [/SS] The protocol will allow MIDCOM agents to signal the middleboxes to let complex applications using dynamic port based sessions through them (i.e., middleboxes) seamlessly. [SS] There are additional protocol requirements which may need to be addressed here (or perhaps in the Requirements draft), such as the following. The protocol should allow exchange of state synchronization information (such as resource availability, state of the binding in case NAT's, health-checks etc) between the Midcom Agent & the Middle-box. The protocol should also allow modification of state in the Middle-box during runtime. The protocol should be able to specify direction of the connection through the Middle-box. [/SS] Connection setup must be preceded by registration of the MIDCOM agent with either the middlebox or the Policy Server. [SS] There might be situations where this registration process is initiated by the Middle-box itself. So, isn't it better to phrase the above sentence as "Connection set-up must be preceded by a registration phase between the Midcom agent and either the Middle-box or the Policy server". This also concurrs more with the text in the Protocol Requirements DRAFT. [/SS] Alternately, a MIDCOM session termination may be triggered by one of (a) agent going out of service and not being available for further MIDCOM operations, .... [SS] It would also be triggered by the Middle-box going out of service. [/SS] During connection establishment, an agent would identify itself as either In-Path or Out-Of-Path(OOP) to the middlebox. [SS] This should be during Registration phase, right? Is support of OOP Midcom agent (& the associated "diversion" function in the Middle-box), mandatory under the framework or is it optional? This should be mentioned too. [/SS] Profile of a MIDCOM agent includes agent authorization policy (i.e, session tuples for which the agent is authorized to act as ALG), ... [SS] Please define Session Tuple. If its the Session id , then in many cases, the MA doesn't know about it until the session is being initiated (e.g., SIP session). It may not be possible for the MA to have this information during the time of registration. [/SS] 4. MIDCOM Protocol [MB] Initially, I was in agreement with Eric Fleishman's comments that the last 2 paragraphs of Section 4 are misplaced as they describe functionality of the Middlebox (stateful vs. stateless) rather than the protocol itself. However, in re-reading, I think that the concept is also protocol related (i.e. which messages effect a change in the Protocol state machine). Perhaps, there needs to be a paragraph in Section 3 such as: Some middlebox services are stateless. However, there are many that are stateful and maintain per-connection state in the system. Firewall service may be implemented as a stateless list of ACLs. Many firewall implementations, however, are stateful. NAT service, on the other hand, is inherently stateful. As such, support of the MIDCOM protocol will require a middlebox to be stateful. Refer to Section 4.0 for further detail. And a paragraph in Section 4 (replacing the current last 2 paragraphs) that reads something like: The MIDCOM protocol may require a middlebox to be stateful. For the case of a middlebox implementing firewall service, with the advent of MIDCOM protocol, the middlebox is required to allocate dynamic resources, such as pin-holes, upon request from agents. Explicit release of dynamically allocated resources happens when the application session is ended or when a Midcom agent requests the middlebox to release the resource. However, the middlebox must be able to recover the dynamically allocated resources at some point in time even if the agent that was responsible for the dynamic allocation is not alive. Typically, this is done by tracking the state of each dynamically allocated pin-hole with some type of a timer. This exemplifies that even the firewall function will need to maintain per-connection state, as a requirement to support the MIDCOM protocol. [/MB] The technique described above is necessary for the pre-registration of MIDCOM agents with the Middlebox. However, it is possible to retain the provisioning on middlebox unchanged, by requiring MIDCOM agents to initiate the connection to middlebox. In such a case, the agent should initiate the connection prior to the start of the application. ... [SS] I assume that you're talking about Registration connection here. How does the Midcom agent know when to initiate this connection? Again, going back to the SIP example, the agent can only initiate the connection on receipt of a SIP INVITE message. It makes sense to me for apriori registration between the MB & MA, & MA be ready for connection set-up whenever required. The registration is refreshed periodically. [/SS] [SS] Typo in the third line of last para of page 20 - "... media stream, When used" [/SS] Section 7.3 - Middlebox implementing NAPT & Firewall call flows: | | | | | |++Permit RTP1 & RTCP1 | | | | sessions External to| | | | middlebox, namely | | | | Ma to Ea:Eport1, | | | | Ma to Ea:Eport1+1 | | | | sessions ++++++++++>| | | |<+Ma to Ea:Eport1, | | | | Ma to Ea:Eport1+1 | | | | sessions OKed ++++++| [SS] Should this be Ma or is it Pa? For certain types of NAPT, you won't be able to complete the binding & update the NAPT table until you know the port address of the callee, which is not part of the SDP in INVITE. In many cases, the SDP of the callee (containing the port) is carried in the provisional response 180/183, and Early Media follows the provisional response. The MA should be able to complete the NAPT binding based on the SDP of the callee in the response message, to allow early media. [/SS] 9.3. Asynchronous notification to MIDCOM agents Asynchronous notification by the middlebox to a MIDCOM agent can be useful for events such as Session creation, Session termination, MIDCOM protocol failure, Middlebox function failure or any other significant event. Independently, ICMP error codes can also be useful to notify transport layer failures to the agents. ... [SS] We should perhaps also include the following: - Exchange state synchronization information (described earlier) - Periodic health check message exchange - MB send logs of unauthorized access & unsolicitated alarms to the MA [/SS] Regards, Sanjoy Sen ------_=_NextPart_001_01C0FCD4.6ACB5270 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] Framework draft review
Had posted this to the mailing list about a week back. Not sure whether it reached the authors as I didn't get any response from them.
 
Rgds,
Sanjoy
Subject: RE: [midcom] Framework draft review



Here're some feedback from myself & Mary Barnes on the Framework draft. Please find our comments within the delimiters, such as [SS] and [/SS].

Regards,
Sanjoy

=======================
1. Introduction
----------------

3rd sentence: Network Address Translator service, on the other hand, provides routing transparency across address realms (within IPv4 routing network or across V4 and V6 routing realms). Application Level gateways (ALGs) are used in conjunction with NAT to provide end-to-end transparency for many of the applications.

[MB] I think this has already been discussed before, but transparency is not a term here for either of these sentences.  I would suggest rewording these 2 sentences as:

The address mapping of Network Address Translation (within IPv4 routing network or across V4 and V6 routing realms), however, is independent from the end application. An Application Level Gateway (ALG) used in conjunction with NAT can remove the knowledge of NATs for applications for which NATs are problematic. [/MB]

2.5. Proxy

   A proxy is an intermediate relay agent between clients and servers
   of an application, relaying application messages between the two.
   Proxies use special protocol mechanisms to communicate with proxy
   clients and relay client data to servers and vice versa.

[SS] The proxies described here are application layer proxies. There're other types of proxies which relays the transport stream (Transport layer proxies), such as an RTP proxy, without higher layer application awareness. These two types should perhaps be distinguished. The reason is that while application layer proxies can be a type of Midcom agent, the transport layer proxies can be a type of Middle-Box (and I think that Midcom is a general framework with the eventual goal of addressing all kinds of Middleboxes). Proxies which are application-unaware but need application-specific intelligence are also Middle-boxes. [/SS]


2.8. MIDCOM Agents

   MIDCOM agents are entities performing ALG function, ...

[SS] Why only ALG's? Application layer proxies (since you've distinguished between ALG's & proxies) can also be Midcom agents, as you've provided some examples in the next paragraph. [/SS]

   The protocol will allow MIDCOM agents to signal
   the middleboxes to let complex applications using dynamic port
   based sessions through them (i.e., middleboxes) seamlessly.

[SS] There are additional protocol requirements which may need to be addressed here (or perhaps in the Requirements draft), such as the following. The protocol should allow exchange of state synchronization information (such as resource availability, state of the binding in case NAT's, health-checks etc) between the Midcom Agent & the Middle-box. The protocol should also allow modification of state in the Middle-box during runtime. The protocol should be able to specify direction of the connection through the Middle-box. [/SS]

   Connection setup must be preceded by registration of the
   MIDCOM agent with either the middlebox or the Policy Server.

[SS] There might be situations where this registration process is initiated by the Middle-box itself. So, isn't it better to phrase the above sentence as "Connection set-up must be preceded by a registration phase between the Midcom agent and either the Middle-box or the Policy server". This also concurrs more with the text in the Protocol Requirements DRAFT. [/SS]

   Alternately, a MIDCOM session termination may be triggered by
   one of (a) agent going out of service and not being available
   for further MIDCOM operations, ....

[SS] It would also be triggered by the Middle-box going out of service. [/SS]

   During connection establishment, an agent would identify
   itself as either In-Path or Out-Of-Path(OOP) to the middlebox.

[SS] This should be during Registration phase, right?
Is support of OOP Midcom agent (& the associated "diversion" function in the Middle-box), mandatory under the framework or is it optional? This should be mentioned too. [/SS]

   Profile of a MIDCOM agent includes agent authorization policy (i.e,
   session tuples for which the agent is authorized to act as ALG), ...

[SS] Please define Session Tuple. If its the Session id <Src./Dest. IP address/port, protocol>, then in many cases, the MA doesn't know about it until the session is being initiated (e.g., SIP session). It may not be possible for the MA to have this information during the time of registration. [/SS]

4. MIDCOM Protocol

[MB] Initially, I was in agreement with Eric Fleishman's comments that the last 2 paragraphs of Section 4 are misplaced as they describe functionality of the Middlebox (stateful vs. stateless) rather than the protocol itself. However, in re-reading, I think that the concept is also protocol related (i.e. which messages effect a change in the Protocol state machine). Perhaps, there needs to be a paragraph in Section 3 such as:

   Some middlebox services are stateless. However, there are many that
   are stateful and maintain per-connection state in the system.
   Firewall service may be implemented as a stateless list of ACLs.
   Many firewall implementations, however, are stateful. NAT
   service, on the other hand, is inherently stateful. As such,
   support of the MIDCOM protocol will require a middlebox to be
   stateful. Refer to Section 4.0 for further detail.    

And a paragraph in Section 4 (replacing the current last 2 paragraphs) that reads something like:

   The MIDCOM protocol may require a middlebox to be
   stateful. For the case of a middlebox implementing firewall
   service, with the advent of MIDCOM protocol, the middlebox is
   required to allocate dynamic resources, such as pin-holes,
   upon request from agents. Explicit release of dynamically
   allocated resources happens when the application session is
   ended or when a Midcom agent requests the middlebox to release
   the resource. However, the middlebox must be able to recover the
   dynamically allocated resources at some point in time even if
   the agent that was responsible for the dynamic allocation is not
   alive. Typically, this is done by tracking the state of each
   dynamically allocated pin-hole with some type of a timer.
   This exemplifies that even the firewall function will need to
   maintain per-connection state, as a requirement to support the
   MIDCOM protocol.

[/MB]


   The technique described above is necessary for the pre-registration of MIDCOM agents with the
   Middlebox. However, it is possible to retain the provisioning on middlebox unchanged, by
   requiring MIDCOM agents to initiate the connection to middlebox. In such a case, the
   agent should initiate the connection prior to the start of the
   application. ...


[SS] I assume that you're talking about Registration connection here. How does the Midcom agent know when to initiate this connection? Again, going back to the SIP example, the agent can only initiate the connection on receipt of a SIP INVITE message. It makes sense to me for apriori registration between the MB & MA, & MA be ready for connection set-up whenever required. The registration is refreshed periodically. [/SS]

[SS] Typo in the third line of last para of page 20 - "... media stream, When used"  [/SS]

Section 7.3 - Middlebox implementing NAPT & Firewall call flows:

   |                 |                      |              |
   |                 |++Permit RTP1 & RTCP1 |              |
   |                 |  sessions External to|              |
   |                 |  middlebox, namely   |              |
   |                 |  Ma to Ea:Eport1,    |              |
   |                 |  Ma to Ea:Eport1+1   |              |
   |                 |  sessions ++++++++++>|              |
   |                 |<+Ma to Ea:Eport1,    |              |
   |                 |  Ma to Ea:Eport1+1     |              |
   |                 |  sessions OKed ++++++|             


[SS] Should this be Ma or is it Pa? 

For certain types of NAPT, you won't be able to complete the binding & update the NAPT table until you know the port address of the callee, which is not part of the SDP in INVITE. In many cases, the SDP of the callee (containing the port) is carried in the provisional response 180/183, and Early Media follows the provisional response. The MA should be able to complete the NAPT binding based on the SDP of the callee in the response message, to allow early media. [/SS]

9.3. Asynchronous notification to MIDCOM agents

   Asynchronous notification by the middlebox to a MIDCOM agent
   can be useful for events such as Session creation, Session
   termination, MIDCOM protocol failure, Middlebox function
   failure or any other significant event. Independently, ICMP
   error codes can also be useful to notify transport layer
   failures to the agents. ...

[SS] We should perhaps also include the following:
        - Exchange state synchronization information (described earlier)
        - Periodic health check message exchange
        - MB send logs of unauthorized access & unsolicitated alarms to the MA
[/SS]

Regards,
Sanjoy Sen

------_=_NextPart_001_01C0FCD4.6ACB5270-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 03:47: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 DAA08343 for ; Mon, 25 Jun 2001 03:47:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23658; Mon, 25 Jun 2001 03:41:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23630 for ; Mon, 25 Jun 2001 03:41:23 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08265 for ; Mon, 25 Jun 2001 03:40:43 -0400 (EDT) Received: from localhost (elear@localhost) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id AAA04521; Mon, 25 Jun 2001 00:40:51 -0700 (PDT) Date: Mon, 25 Jun 2001 00:40:51 -0700 (PDT) From: Eliot Lear To: Christian Huitema cc: midcom@ietf.org Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt 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 Christian, WRT uni/bi-directional flows, do we need to insert a "Multicast Considerations" section? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 04:52: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 EAA09040 for ; Mon, 25 Jun 2001 04:52:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26185; Mon, 25 Jun 2001 04:45:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26158 for ; Mon, 25 Jun 2001 04:45:02 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08966 for ; Mon, 25 Jun 2001 04:44:22 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Mon, 25 Jun 2001 09:43:45 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Mon, 25 Jun 2001 09:43:53 +0100 Message-ID: To: bpenfield@acmepacket.com, midcom@ietf.org Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 09:36:01 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 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 Bob, > Section 6.2 talks about Deregistration. Is this suppose to be an explicit > function or is this normal closing of the MIDCOM Session? If it is normal > closing, I disagree with the requirement to close all the pin holes (see > above). I think there was some earlier discussion of this point. The point about Agent de-registration is that the session between the Middlebox and a specific Agent has come to an end. (This is not the same as an individual application session across the Middlebox has come to an end as the relationship between an Agent and Middlebox may survive multiple individual "application sessions".) Rather it may be something along the lines of the Agent wishes to break the relationship with the Middlebox to do a system restart. In this case the Agent is sending an explicit notification to the Middlebox that it wishes to come "off the air". In such circumstances the Middlebox can have no future knowledge of when to close poin-holes that are already open. It therefore seems logical to free up all the resources on the Middlebox that the Agent had requested. i.e. close all the associated pin-holes. Otherwise when the Agent disappears in such circumstances the Middlebox will not know what to do. regards Richard _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 08:05: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 IAA12054 for ; Mon, 25 Jun 2001 08:05:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02607; Mon, 25 Jun 2001 07:59:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19486 for ; Mon, 25 Jun 2001 02:52:18 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05920; Mon, 25 Jun 2001 02:51:39 -0400 (EDT) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f5P6pkl20625; Mon, 25 Jun 2001 08:51:46 +0200 (MET DST) Received: from alcatel.be ([138.203.66.234]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A76.0025AC56; Mon, 25 Jun 2001 08:51:29 +0200 Message-ID: <3B36DF71.D16F1D67@alcatel.be> Date: Mon, 25 Jun 2001 08:51:29 +0200 From: Dominique Chantrain X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org, discuss@apps.ietf.org, ops-area@ops.ietf.org, midcom@ietf.org, rap@ops.ietf.org, tport@ks.sel.alcatel.de CC: "SALES, Bernard" , Emmanuel DESMET , Services Project , Omar ELLOUMI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Communication between applications and network 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 Recently a new Internet draft has been submitted (draft-pham-triggers-and-handles-00.txt, downloadable from http://www.ietf.org/internet-drafts/draft-pham-triggers-and-handles-00.txt), which introduces a new concept for communication between applications and network elements. The document defines triggers and handles exchanged between applications and network elements, and introduces associated communication mechanisms such as subscription to triggers from a network element, and discovery of network element interfaces. This communication interface and framework will allow applications to be deployed on heterogeneous networks in a vendor-independent way but still being aware of network events by the mechanism of triggers and being able to control network resources by the mechanism of handles, i.e. network awareness of applications will be improved. The work will aim at reusing as much as possible existing protocols and will define extensions or new protocols only when necessary. The targeted network environment is primarily the broadband access network (user terminal - DSL modem - DSLAM - BRAS), although also other networks can be envisaged. The purpose of this Internet Draft is to stimulate discussion on this concept. Therefore an associated mailinglist has been created where you can send your comments and reactions: Address: triggershandles@public.alcatel.com To subscribe, send an email to majordomo@public.alcatel.com with in the body "subcribe triggershandles" If discussions raise enough interests, a BOF will be requested to further work on the subject in IETF. Indeed, the topic is today not really covered in a charter of any working group. Nevertheless, it has clear links with following areas and working groups: - the applications area: since the I-D deals with mechanisms to make applications more network aware. - the operations and management area: since the mechanism are based on or similar to concepts used in AAA, in policy framework, etc. - the resource allocation protocol WG (rap): since the COPS protocol is currently envisaged to be one of the major cornerstones of the triggers & handles framework. - the middlebox communication WG (midcom): as this WG deals with mechanisms for applications to be able to communicate their needs to the devices in the network that provide transport policy enforcement. in other words, very similar to the idea of handles in the I-D. Looking forward to receiving your comments, Dominique Chantrain & Hien-Thong Pham _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 08:14: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 IAA12424 for ; Mon, 25 Jun 2001 08:14:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03135; Mon, 25 Jun 2001 08:09:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03102 for ; Mon, 25 Jun 2001 08:09:36 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12190 for ; Mon, 25 Jun 2001 08:08:57 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A97E3C701C6; Mon, 25 Jun 2001 08:07:26 -0400 Message-ID: <004901c0fd6f$bdb92ac0$2300000a@acmepacket.com> From: "Bob Penfield" To: , References: Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 08:09:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 Richard Swale wrote: > > > Section 6.2 talks about Deregistration. Is this suppose to be an explicit > > function or is this normal closing of the MIDCOM Session? If it is normal > > closing, I disagree with the requirement to close all the pin holes (see > > above). > > I think there was some earlier discussion of this point. The point about > Agent de-registration is that the session between the Middlebox and a > specific Agent has come to an end. (This is not the same as an individual > application session across the Middlebox has come to an end as the > relationship between an Agent and Middlebox may survive multiple individual > "application sessions".) Rather it may be something along the lines of the > Agent wishes to break the relationship with the Middlebox to do a system > restart. In this case the Agent is sending an explicit notification to the > Middlebox that it wishes to come "off the air". In such circumstances the > Middlebox can have no future knowledge of when to close poin-holes that are > already open. It therefore seems logical to free up all the resources on the > Middlebox that the Agent had requested. i.e. close all the associated > pin-holes. Otherwise when the Agent disappears in such circumstances the > Middlebox will not know what to do. That's what I was afraid of. If I have redundant MIDCOM Agents, and one of them needs to be restarted for whatever reason, I want to keep the pin-holes open because there is still another MIDCOM agent present to close the pin-holes when their sessions end. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 10:52: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 KAA17036 for ; Mon, 25 Jun 2001 10:52:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08744; Mon, 25 Jun 2001 10:34:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08709 for ; Mon, 25 Jun 2001 10:34:31 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16579 for ; Mon, 25 Jun 2001 10:33:52 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5PEY0w29496 for ; Mon, 25 Jun 2001 15:34:00 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Mon, 25 Jun 2001 15:33:20 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 15:33:18 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30444FFC@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Scott Brim'" , midcom Subject: RE: [midcom] middlebox informs agent? Date: Mon, 25 Jun 2001 15:33:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FD83.C5DFB750" 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_001_01C0FD83.C5DFB750 Content-Type: text/plain; charset="iso-8859-1" I agree with the need to keep the session states requested by the agent after communications are lost for x sec (defined in the agent profile). The driver for that is that we need to have a fail over mechanism from a midcom agent to another. Until now we have never discussed fault tolerance and reliability mechanisms (as you mentioned below). In case we do not have a standardized approach of fail over (Melinda, is this in scope ?) at least have an understanding of what is the agreed behavior when an agent that didn't reply to a keep-alive resends later on another keep alive. In case the middle box accepts to maintain the "connection" (as Suresh calls it), this allows to use proprietary Virtual Midcom agents mechanisms (i.e. the Middle box sees only one virtual agent all the time). I'm happy to write a section on the subject (either in the FW or in the requirements draft) Cedric -----Original Message----- From: Scott Brim [mailto:sbrim@cisco.com] Sent: Friday, June 22, 2001 2:46 PM To: midcom Subject: Re: [midcom] middlebox informs agent? On 22 Jun 2001 at 08:32 -0400, Melinda Shore apparently wrote: > > It wouldn't be controversial except that someone said he really didn't > > want middleboxes to be required to delete state if an agent disappeared, > > that pinholes should be left open for some time. > > That "he" would be me. > > That's a sort of a rough paraphrase, Scott. I'm concerned > that tearing down state as soon as an agent fails works > against fault tolerance. Sorry about "rough". OK, can we work toward consensus on requirements? What specifically is the minimum that is required? Do you want to require, say, the agent to state (in the midcom protocol) the minimum time that installed state should be retained if agent<->middlebox communication is lost (default to 0)? Note that this would be after communication was declared "lost", an interval that hasn't been set yet. I think maybe we should talk about fault tolerance requirements in general first? ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0FD83.C5DFB750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] middlebox informs agent?

I agree with the need to keep the session states = requested by the agent after communications are lost for x sec (defined = in the agent profile).

The driver for that is that we need to have a fail = over mechanism from a midcom agent to another.

Until now we have never discussed fault tolerance and = reliability mechanisms (as you mentioned below).
In case we do not have a standardized approach of = fail over (Melinda, is this in scope ?) at least have an understanding = of what

is the agreed behavior when an agent that didn't = reply to a keep-alive resends later on another keep alive.
In case the middle box accepts to maintain the = "connection" (as Suresh calls it), this allows to use = proprietary
Virtual Midcom agents mechanisms (i.e. the Middle = box sees only one virtual agent all the time).

I'm happy to write a section on the subject (either = in the FW or in the requirements draft)
Cedric




-----Original Message-----
From: Scott Brim [mailto:sbrim@cisco.com]
Sent: Friday, June 22, 2001 2:46 PM
To: midcom
Subject: Re: [midcom] middlebox informs = agent?


On 22 Jun 2001 at 08:32 -0400, Melinda Shore = apparently wrote:
> > It wouldn't be controversial except that = someone said he really didn't
> > want middleboxes to be required to delete = state if an agent disappeared,
> > that pinholes should be left open for some = time.
>
> That "he" would be me.
>
> That's a sort of a rough paraphrase, = Scott.  I'm concerned
> that tearing down state as soon as an agent = fails works
> against fault tolerance.

Sorry about "rough".  OK, can we work = toward consensus on requirements?
What specifically is the minimum that is = required?  Do you want to
require, say, the agent to state (in the midcom = protocol) the minimum
time that installed state should be retained if = agent<->middlebox
communication is lost (default to 0)?  Note = that this would be after
communication was declared "lost", an = interval that hasn't been set
yet. 

I think maybe we should talk about fault tolerance = requirements in
general first?

...Scott


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C0FD83.C5DFB750-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 11:19: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 LAA17967 for ; Mon, 25 Jun 2001 11:19:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10082; Mon, 25 Jun 2001 11:02:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10055 for ; Mon, 25 Jun 2001 11:02:46 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17318 for ; Mon, 25 Jun 2001 11:02:06 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5PF2Ew08072 for ; Mon, 25 Jun 2001 16:02:14 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Mon, 25 Jun 2001 16:02:05 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 16:02:05 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30444FFD@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Andrew Molitor'" Cc: Scott Brim , midcom@ietf.org Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 16:02:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FD87.CA1E75A0" 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_001_01C0FD87.CA1E75A0 Content-Type: text/plain; charset="iso-8859-1" "I read this as allowing one Agent to, for example, remove a pinhole created by another. This is obviously necessary for fault tolerant configurations." This has to be limked with agents policy attributes such as who is the backup agent to whom. This needs to be considered in our overall requirements for fail over. This implies that the backup agent needs to have the status of already established sessions between the middle box and the active agent. Cedric -----Original Message----- From: Andrew Molitor [mailto:amolitor@visi.com] Sent: Friday, June 22, 2001 5:19 PM To: Scott Brim Cc: midcom@ietf.org Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt On Fri, 22 Jun 2001, Scott Brim wrote: > All in all a very good start. There will be lots more requirements, and > I believe some of the ones you list will need clarification once we get > a more complete list. I have a few issues ... > > > requested by a MIDCOM Agent. However the Middlebox must not alter > > packet information unless it appears in the packet header. This is to > > ensure that there is an appropriate separation of concerns between the > > MIDCOM Agent and the Middlebox. > > If I understand what you mean I disagree. Consider the case of FTP > through NAT. Are you saying the middlebox must never modify IP > addresses in packet payloads? I think the point is that the middlebox wouldn't mess with the control stream -- that's the 'FTP-aware MIDCOM Agent's job. If a middlebox DOES alter the PORT commands, we should consider that to be an agent contained inside the middlebox. The point, I suspect, is that the middlebox proper CANNOT alter the payloads -- in this case the PORT commands -- because the middlebox proper BY DEFINITION does not know enough (anything) about the FTP control protocol to do that work. A thing which knows enough to do that work is an Agent. > > A given Middlebox may support multiple concurrent trust relationships > > with a number of MIDCOM Agents. Resources, such as a Pinhole- > > Descriptor, may be shared across MIDCOM Agents and a Middlebox. > > I don't understand what it means for something to be shared "across > agents and a middlebox". What is the base requirement which leads you > to suggest this? I read this as allowing one Agent to, for example, remove a pinhole created by another. This is obviously necessary for fault tolerant configurations. > > h. Define mechanisms to mitigate replay attacks on the control > > messages. > > This is the only security requirement that gives me pause. So far we > haven't had a requirement to keep a connection open between agent and > middlebox -- just security state at each end. Replay protection would > require a lot more lower-level, protocol-related state. Essentially, > what do you mean by "mitigate", in concrete terms? Replay attacks are the single most dangerous type of attack in this context. If I can re-open a specific pinhole at will, you are COMPLETELY sunk. If MIDCOM doesn't support enough crypto juice to make replay attacks crypto-hard to mount, it's a useless toy. Having worked on the design, implementation, and deployment of one of these things I see no way around maintaining some type of connection state between Agent and Middlebox. It doesn't have to be heavy state, but it needs to do enough stuff with connect/authenticate and then sequence numbering and crypto stuff to make it work securely. If someone can show me how to do it statelessly, securely, and efficiently, it'll make the happiest boy in town! Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0FD87.CA1E75A0 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] draft-ietf-midcom-requirements-01.txt

"I read this as allowing one Agent to, for example, remove
a pinhole created by another. This is obviously necessary for fault
tolerant configurations."

This has to be limked with agents policy attributes such as who is the
backup agent to whom. This needs to be considered in our overall requirements for fail over.

This implies that the backup agent needs to have the status of already established
sessions between the middle box and the active agent.

Cedric

-----Original Message-----
From: Andrew Molitor [mailto:amolitor@visi.com]
Sent: Friday, June 22, 2001 5:19 PM
To: Scott Brim
Cc: midcom@ietf.org
Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt




On Fri, 22 Jun 2001, Scott Brim wrote:

> All in all a very good start.  There will be lots more requirements, and
> I believe some of the ones you list will need clarification once we get
> a more complete list.  I have a few issues ...
>
> > requested by a MIDCOM Agent. However the Middlebox must not alter
> > packet information unless it appears in the packet header. This is to
> > ensure that there is an appropriate separation of concerns between the
> > MIDCOM Agent and the Middlebox.
>
> If I understand what you mean I disagree.  Consider the case of FTP
> through NAT.  Are you saying the middlebox must never modify IP
> addresses in packet payloads?

        I think the point is that the middlebox wouldn't mess with the
control stream -- that's the 'FTP-aware MIDCOM Agent's job. If a middlebox
DOES alter the PORT commands, we should consider that to be an agent
contained inside the middlebox.

        The point, I suspect, is that the middlebox proper CANNOT
alter the payloads -- in this case the PORT commands -- because
the middlebox proper BY DEFINITION does not know enough (anything)
about the FTP control protocol to do that work. A thing which knows
enough to do that work is an Agent.


> > A given Middlebox may support multiple concurrent trust relationships
> > with a number of MIDCOM Agents. Resources, such as a Pinhole-
> > Descriptor, may be shared across MIDCOM Agents and a Middlebox.
>
> I don't understand what it means for something to be shared "across
> agents and a middlebox".  What is the base requirement which leads you
> to suggest this?

        I read this as allowing one Agent to, for example, remove
a pinhole created by another. This is obviously necessary for fault
tolerant configurations.

> > h. Define mechanisms to mitigate replay attacks on the control
> > messages.
>
> This is the only security requirement that gives me pause.  So far we
> haven't had a requirement to keep a connection open between agent and
> middlebox -- just security state at each end.  Replay protection would
> require a lot more lower-level, protocol-related state.  Essentially,
> what do you mean by "mitigate", in concrete terms?

        Replay attacks are the single most dangerous type of attack
in this context. If I can re-open a specific pinhole at will, you are
COMPLETELY sunk. If MIDCOM doesn't support enough crypto juice to
make replay attacks crypto-hard to mount, it's a useless toy.

        Having worked on the design, implementation, and deployment of
one of these things I see no way around maintaining some type of
connection state between Agent and Middlebox. It doesn't have to be
heavy state, but it needs to do enough stuff with connect/authenticate
and then sequence numbering and crypto stuff to make it work securely.

        If someone can show me how to do it statelessly, securely, and
efficiently, it'll make the happiest boy in town!


                Andrew


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C0FD87.CA1E75A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 11:25: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 LAA18144 for ; Mon, 25 Jun 2001 11:25:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10427; Mon, 25 Jun 2001 11:10:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10397 for ; Mon, 25 Jun 2001 11:10:45 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17577 for ; Mon, 25 Jun 2001 11:10:06 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GFH0039NRGZ92@firewall.mcit.com> for midcom@ietf.org; Mon, 25 Jun 2001 15:10:11 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GFH00501RGGY9@dgismtp04.wcomnet.com>; Mon, 25 Jun 2001 15:10:11 +0000 (GMT) Received: from rccc6131 ([166.35.224.41]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GFH001HTRGDO0@dgismtp04.wcomnet.com>; Mon, 25 Jun 2001 15:09:49 +0000 (GMT) Date: Mon, 25 Jun 2001 10:09:45 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt In-reply-to: <001701c0fca9$57fdd760$2300000a@acmepacket.com> To: "'Bob Penfield'" , "'Melinda Shore'" , "'Andrew Molitor'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <002501c0fd88$df037820$01010101@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 agree with Bob. Rules are typically implemented per interface with source and destination defined per interface. For the rule being configured the source and destination is defined relative to the interface as this is related to the direction of the flow. We could use the many terms such egress (inside) and ingress (outside) [these specific associations being my view of reality], and as Bob states with the example of IP spoofing, the tables are relevant to the interface, and these tables are in use today by many vendors. In the case of IP spoofing one of the best practices in the industry is in the definition of ingress and egress filter rules to prevent IP spoofing from being possible. These filters are applied to the specific interfaces in order to obtain the desired results. Even your own product defaults to the terms inside and outside when describing interfaces. I wish I had more time to elaborate here.... Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Bob Penfield Sent: Sunday, June 24, 2001 7:30 AM To: Melinda Shore; Andrew Molitor; midcom@ietf.org Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt ----- Original Message ----- From: "Melinda Shore" To: "Bob Penfield" ; "Andrew Molitor" ; Sent: Sunday, June 24, 2001 8:02 AM Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt > > In order to ensure the > > desired packet forwarding/admission, the pin-hole would need to be > > associated with the interface that the packets would be arriving on. Packets > > arriving on the other interface that happen to match the source address > > prefix/mask for that pin-hole spec would be blocked. > > I think we're saying the same thing. Given that > we've got source addresses and destination addresses > in the IP headers, isn't putting additional directionality > information redundant (and potentially confusing if there > are conflicts)? I think you missed my point. What about a spoofed source address? Granted that stops only one kind of attack on only one side of the middlebox. Also, with all the multi-homing, redundant links and other kinds of complex routing isn't it possible, if the middlebox represents the destination address of a packet, that packets with the same source and destination could arrive at either side. Maybe that's a stretch, but I'm not a routing expert. If I am implementing a middlebox, being able to have a separate pin-hole tables for each interface is more efficient. Theses boxes usually need to operate at or near wire-speed. (-:bob _______________________________________________ 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 Jun 25 11:31:17 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 LAA18348 for ; Mon, 25 Jun 2001 11:31:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10706; Mon, 25 Jun 2001 11:17:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10675 for ; Mon, 25 Jun 2001 11:17:40 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17847 for ; Mon, 25 Jun 2001 11:17:00 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5PFHHx09183; Mon, 25 Jun 2001 08:17:17 -0700 (PDT) Received: from spandex (rtp-vpn-170.cisco.com [10.82.192.170]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKT00707; Mon, 25 Jun 2001 08:17:05 -0700 (PDT) Message-ID: <026601c0fd8a$0853d5c0$d45904d1@cisco.com> From: "Melinda Shore" To: , References: <002501c0fd88$df037820$01010101@mcit.com> Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 11:18:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > In the case of IP > spoofing one of the best practices in the industry is in the definition of > ingress and egress filter rules to prevent IP spoofing from being possible. > These filters are applied to the specific interfaces in order to obtain the > desired results. I'm trying to get a handle on why people feel that using transport header source and destination addresses along with per-interface policy isn't sufficient - why do we need, for example, a "direction" field in a midcom information element? I'd like to avoid redundancy and potential conflicts that result from that redundancy. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 11:42: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 LAA18729 for ; Mon, 25 Jun 2001 11:42:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11662; Mon, 25 Jun 2001 11:34:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11637 for ; Mon, 25 Jun 2001 11:34:24 -0400 (EDT) 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 LAA18414 for ; Mon, 25 Jun 2001 11:33:41 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5PFXph00361; Mon, 25 Jun 2001 08:33:51 -0700 (PDT) Received: from spandex (rtp-vpn-170.cisco.com [10.82.192.170]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKT01090; Mon, 25 Jun 2001 08:33:39 -0700 (PDT) Message-ID: <027c01c0fd8c$58120a80$d45904d1@cisco.com> From: "Melinda Shore" To: "Cedric Aoun" , "midcom" References: <9154CB41F208D5118DD200508BE39C30444FFC@zjguc006.europe.nortel.com> Subject: Re: [midcom] middlebox informs agent? Date: Mon, 25 Jun 2001 11:34:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > From: Cedric Aoun > To: 'Scott Brim' ; midcom > Sent: Monday, June 25, 2001 10:33 AM > Subject: RE: [midcom] middlebox informs agent? > Until now we have never discussed fault tolerance and reliability mechanisms > (as you mentioned below). > In case we do not have a standardized approach of fail over (Melinda, is > this in scope ?) at least have an understanding of what > is the agreed behavior when an agent that didn't reply to a keep-alive > resends later on another keep alive. Failover is not currently part of the problem space as we understand it and I'm concerned about scope creep. At the same time I think we need to take care that the framework we develop doesn't make failover (either agents or boxes) unnecessarily difficult. It seems to me that a discussion of failover considerations and state management/transfer could be useful, but please - let's avoid introducing new terminology and architecture ("virtual midcom agents") unless necessary. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 12:09:52 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 MAA19611 for ; Mon, 25 Jun 2001 12:09:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12643; Mon, 25 Jun 2001 12:00:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12562 for ; Mon, 25 Jun 2001 12:00:11 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19391 for ; Mon, 25 Jun 2001 11:59:29 -0400 (EDT) Received: from 157.54.7.67 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Jun 2001 08:50:46 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 25 Jun 2001 08:53:10 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 25 Jun 2001 08:52:41 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 25 Jun 2001 08:52:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 08:52:11 -0700 Message-ID: Thread-Topic: [midcom] draft-ietf-midcom-requirements-01.txt Thread-Index: AcD9U+FRm5ZVkzZOSG2SBy20KMUsSwAOkV5Q From: "Christian Huitema" To: , , X-OriginalArrivalTime: 25 Jun 2001 15:52:11.0630 (UTC) FILETIME=[CC02E8E0:01C0FD8E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA12609 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: 8bit > > Section 6.2 talks about Deregistration. Is this suppose to be an > explicit > > function or is this normal closing of the MIDCOM Session? If it is > normal > > closing, I disagree with the requirement to close all the pin holes (see > > above). > > I think there was some earlier discussion of this point. The point about > Agent de-registration is that the session between the Middlebox and a > specific Agent has come to an end. (This is not the same as an individual > application session across the Middlebox has come to an end as the > relationship between an Agent and Middlebox may survive multiple > individual > "application sessions".) Rather it may be something along the lines of the > Agent wishes to break the relationship with the Middlebox to do a system > restart. In this case the Agent is sending an explicit notification to the > Middlebox that it wishes to come "off the air". In such circumstances the > Middlebox can have no future knowledge of when to close poin-holes that > are > already open. It therefore seems logical to free up all the resources on > the > Middlebox that the Agent had requested. i.e. close all the associated > pin-holes. Otherwise when the Agent disappears in such circumstances the > Middlebox will not know what to do. This problem is an artifact of the editors' decision to write a "protocol architecture" rather than a "protocol requirement." The requirements that they are trying to address should be listed under an "operational requirement" session. The issue you are handling regards the amount of fate sharing that should be accepted between the "midcom agent" and the "application flow". Should the application be automatically disconnected if the midcom agent becomes unavailable? Can a pinhole opened by one midcom agent be closed by another one? Do we require a mechanism to produce an inventory of pinholes, in order to enable "garbage collection"? Do we require that all pinholes have a limited time-to-live? -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 12:14: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 MAA19728 for ; Mon, 25 Jun 2001 12:14:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13226; Mon, 25 Jun 2001 12:07:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13191 for ; Mon, 25 Jun 2001 12:07:51 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19547 for ; Mon, 25 Jun 2001 12:07:10 -0400 (EDT) Received: from 157.54.9.100 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Jun 2001 09:00:44 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Jun 2001 09:00:39 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 25 Jun 2001 09:00:37 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Jun 2001 09:00:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 09:00:08 -0700 Message-ID: Thread-Topic: [midcom] draft-ietf-midcom-requirements-01.txt Thread-Index: AcD9ikEVcLp3UX7AR5GvHbWN9ihZVAABLSTw From: "Christian Huitema" To: "Melinda Shore" , , X-OriginalArrivalTime: 25 Jun 2001 16:00:08.0125 (UTC) FILETIME=[E80646D0:01C0FD8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA13192 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: 8bit > I'm trying to get a handle on why people feel that > using transport header source and destination addresses > along with per-interface policy isn't sufficient - > why do we need, for example, a "direction" field in > a midcom information element? I'd like to avoid > redundancy and potential conflicts that result from > that redundancy. I believe that the "direction" field is artificial. It assumes that boxes have always exactly one inside and one outside, which is not true -- a branch office firewall will typically have three interfaces, the local network, the Internet, and a VPN connection to the main corporate site. The examples about RTP have outlined the fact that RTP pin-hole typically are of the form "allow data from unknown sources and ports to reach a specific address and port." It is true that the average RTP session will require 2 pinholes. But in this case, the direction is expressed trivially; there is no need for a multi-value field. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 12:56:08 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 MAA21166 for ; Mon, 25 Jun 2001 12:56:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15373; Mon, 25 Jun 2001 12:49:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15347 for ; Mon, 25 Jun 2001 12:49:15 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20933 for ; Mon, 25 Jun 2001 12:48:36 -0400 (EDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Jun 2001 08:45:09 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Jun 2001 08:47:27 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 25 Jun 2001 08:47:27 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 25 Jun 2001 08:46:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 08:46:57 -0700 Message-ID: Thread-Topic: [midcom] draft-ietf-midcom-requirements-01.txt Thread-Index: AcD9ShcQKXMIPITdQm++vOuMA6TMPwAQ/R0w From: "Christian Huitema" To: "Eliot Lear" Cc: X-OriginalArrivalTime: 25 Jun 2001 15:46:57.0837 (UTC) FILETIME=[10F9E5D0:01C0FD8E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA15348 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: 8bit Well, if you care about multicast, I guess this would be a good idea. > -----Original Message----- > From: Eliot Lear [mailto:elear@cisco.com] > Sent: Monday, June 25, 2001 12:41 AM > To: Christian Huitema > Cc: midcom@ietf.org > Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt > > > Christian, WRT uni/bi-directional flows, do we need to insert a "Multicast > Considerations" section? > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 13:28:08 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 NAA21819 for ; Mon, 25 Jun 2001 13:28:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16771; Mon, 25 Jun 2001 13:22:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16742 for ; Mon, 25 Jun 2001 13:22:29 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21716 for ; Mon, 25 Jun 2001 13:21:50 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Mon, 25 Jun 2001 18:20:52 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Mon, 25 Jun 2001 18:20:59 +0100 Message-ID: To: huitema@windows.microsoft.com, mshore@cisco.com, christopher.a.martin@wcom.com, midcom@ietf.org Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 18:13:07 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 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 Christian, > The examples about RTP have outlined the fact that RTP pin-hole > typically are of the form "allow data from unknown sources > and ports to > reach a specific address and port." It is true that the average RTP > session will require 2 pinholes. But in this case, the direction is > expressed trivially; there is no need for a multi-value field. > While possible as an option I don't think openning ports to allow allow data from unknown sources and ports is necessarily wise as a security policy for a complete solution. We should allow for more precise cases where a more strict policy is applied( open an RTP stream from THIS source and port to THAT source and port.), shouldn't we? regards Richard _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 14:03:47 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 OAA22835 for ; Mon, 25 Jun 2001 14:03:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18289; Mon, 25 Jun 2001 13:56:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18261 for ; Mon, 25 Jun 2001 13:56:14 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22595 for ; Mon, 25 Jun 2001 13:55:34 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Mon, 25 Jun 2001 18:48:39 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Mon, 25 Jun 2001 18:48:51 +0100 Message-ID: To: huitema@windows.microsoft.com, midcom@ietf.org Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 18:41:00 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 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 Christian, Thanks for the email. I'll get to the other points later on but I wanted to make some comments on your observations below first:- > At a more general level, I find that the document is poorly organized, > and is by no means a complete requirement document. Both section 5, > General Protocol Requirements, and section 6, Agent and Middlebox > association, fall in the classic mistake of explaining "how" > rather than > explaining "what", i.e. proposing an architecture rather than > proposing > an actual list of requirements. This is quite bad, since we > loose a lot > of the rationales developed in the working group. The requirements > should be derived from the framework and the scenarios; in fact, the > scenario and requirement drafts should be merged. I have given this proposal a bit of thought. I think the scenarios document is a useful document and explains a number of the issues involved. However some representative scenarios are already included in the Framework draft (02) for good reasons. For example, that document already has some similar text of this nature (see Section 7.1, 7.2, 7.3, Section 8). If it should be merged anywhere, it should go into the Architecture and Framework document since that covers more of the description of why the MIDCOM approach is desired. Confusing requirements with tutorial information by putting the scenarios text into the requirements document would therefore clearly not be the right thing to do. > The requirement > themselves should be split in three sections, functional requirement, > i.e. how to pass enough data to make the scenario work, security > requirements, and operational requirements, i.e. how to meet various > performance and stability constraints. > Isn't this the "classic mistake" of "how to" rather than "what"? regards Richard _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 14:54: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 OAA24039 for ; Mon, 25 Jun 2001 14:53:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20662; Mon, 25 Jun 2001 14:47:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20630 for ; Mon, 25 Jun 2001 14:47:06 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23837 for ; Mon, 25 Jun 2001 14:46:22 -0400 (EDT) Received: from 157.54.9.100 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Jun 2001 10:48:16 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Jun 2001 10:48:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 25 Jun 2001 10:48:12 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Jun 2001 10:47:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 10:47:43 -0700 Message-ID: Thread-Topic: [midcom] draft-ietf-midcom-requirements-01.txt Thread-Index: AcD9m6A5w1Z6drz5RrKoSmUrq5MVdwAAkHMg From: "Christian Huitema" To: , , , X-OriginalArrivalTime: 25 Jun 2001 17:47:43.0225 (UTC) FILETIME=[EF905E90:01C0FD9E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA20633 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: 8bit I wrote the scenario draft precisely so we could check that what we are designing enables the use that we are planning. In section 2.3.1, "Explicit call from an internal host", I wrote: We should note that, at step 2, the internal server must learn the external mappings of the internal address and ports; at this stage, it does no know the IP address and ports of the third party. This is very much a fact of life. If you are unwilling to open the hole before you know the complete five-tuple, then there is a race condition between opening the hole and receiving the first audio packets; announcements and first words will sometimes be clipped. A few lines letter, the scenario text explains that: The description assumes that the hosts use the same UDP ports in both direction of the media communication. This is not necessarily the case. The source IP address may be unpredictable in the case of multi-homed hosts; the source port may be systematically different from the receive port in some implementation, e.g. parallel processing of the send and receive channels by different software or hardware components. SIP and SDP, as they are defined today, only provide the address at which a host is ready to receive data. They do not document the sending address. The requirement document already mention that the protocol should allow use of wildcards for specifying pinholes. We may expect this to be used frequently. -- Christian Huitema > -----Original Message----- > From: richard.swale@bt.com [mailto:richard.swale@bt.com] > Sent: Monday, June 25, 2001 10:13 AM > To: Christian Huitema; mshore@cisco.com; > christopher.a.martin@wcom.com; midcom@ietf.org > Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt > > > Christian, > > > The examples about RTP have outlined the fact that RTP pin-hole > > typically are of the form "allow data from unknown sources > and ports > > to reach a specific address and port." It is true that the > average RTP > > session will require 2 pinholes. But in this case, the direction is > > expressed trivially; there is no need for a multi-value field. > > > > While possible as an option I don't think openning ports to > allow allow data > from unknown sources and ports is necessarily wise as a > security policy for > a complete solution. We should allow for more precise cases > where a more > strict policy is applied( open an RTP stream from THIS source > and port to > THAT source and port.), shouldn't we? > > regards > > Richard > > _______________________________________________ > 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 Jun 25 15:07: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 PAA24399 for ; Mon, 25 Jun 2001 15:07:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21280; Mon, 25 Jun 2001 15:01:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21250 for ; Mon, 25 Jun 2001 15:01:54 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24262 for ; Mon, 25 Jun 2001 15:01:14 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AA2335F01C0; Mon, 25 Jun 2001 14:59:47 -0400 Message-ID: <008d01c0fda9$4933b640$2300000a@acmepacket.com> From: "Bob Penfield" To: "Melinda Shore" , , References: <002501c0fd88$df037820$01010101@mcit.com> <026601c0fd8a$0853d5c0$d45904d1@cisco.com> Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 15:01:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Melinda Shore" To: ; Sent: Monday, June 25, 2001 11:18 AM Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt > > In the case of IP > > spoofing one of the best practices in the industry is in the definition of > > ingress and egress filter rules to prevent IP spoofing from being possible. > > These filters are applied to the specific interfaces in order to obtain the > > desired results. > > I'm trying to get a handle on why people feel that > using transport header source and destination addresses > along with per-interface policy isn't sufficient - > why do we need, for example, a "direction" field in > a midcom information element? I'd like to avoid > redundancy and potential conflicts that result from > that redundancy. > All I am saying is that we need to be able to associate a pin-hole spec with the specific network interface (or set of interfaces if there are redundant links) it should apply to. I don't think we need "direction" and "interface", just some sort of "interface" field. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 15:19: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 PAA24618 for ; Mon, 25 Jun 2001 15:19:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21580; Mon, 25 Jun 2001 15:12:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21546 for ; Mon, 25 Jun 2001 15:12:57 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24484 for ; Mon, 25 Jun 2001 15:12:17 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AC9F262017C; Mon, 25 Jun 2001 15:10:23 -0400 Message-ID: <00b901c0fdaa$c3864c40$2300000a@acmepacket.com> From: "Bob Penfield" To: , , , , References: Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 15:12:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: To: ; ; ; Sent: Monday, June 25, 2001 1:13 PM Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt > Christian, > > > The examples about RTP have outlined the fact that RTP pin-hole > > typically are of the form "allow data from unknown sources > > and ports to > > reach a specific address and port." It is true that the average RTP > > session will require 2 pinholes. But in this case, the direction is > > expressed trivially; there is no need for a multi-value field. > > > > While possible as an option I don't think openning ports to allow allow data > from unknown sources and ports is necessarily wise as a security policy for > a complete solution. We should allow for more precise cases where a more > strict policy is applied( open an RTP stream from THIS source and port to > THAT source and port.), shouldn't we? > Unfortunately, in SIPland, we don't know the source address and port. The SDP in SIP messages contains only the receiving address and port for each flow. There is no requirement with RTP for the sending address and port to match the receiving address and port. Probably the best we could do is use a prefix or netmask to narrow down the range of acceptable source addresses. > regards > > Richard > > _______________________________________________ > 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 Jun 25 15:38: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 PAA25128 for ; Mon, 25 Jun 2001 15:38:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22286; Mon, 25 Jun 2001 15:30:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22246 for ; Mon, 25 Jun 2001 15:30:22 -0400 (EDT) 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 PAA24880 for ; Mon, 25 Jun 2001 15:29:42 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5PJTvN22875; Mon, 25 Jun 2001 12:29:57 -0700 (PDT) Received: from spandex (rtp-vpn-170.cisco.com [10.82.192.170]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKV06297; Mon, 25 Jun 2001 12:29:48 -0700 (PDT) Message-ID: <03f101c0fdad$557e8b60$d45904d1@cisco.com> From: "Melinda Shore" To: "Bob Penfield" , , References: <002501c0fd88$df037820$01010101@mcit.com> <026601c0fd8a$0853d5c0$d45904d1@cisco.com> <008d01c0fda9$4933b640$2300000a@acmepacket.com> Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 15:30:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > All I am saying is that we need to be able to associate a pin-hole spec with > the specific network interface (or set of interfaces if there are redundant > links) it should apply to. I don't think we need "direction" and > "interface", just some sort of "interface" field. That makes more sense, but I think we need to work through how the agent knows what the interfaces are on the box, and how it makes use of that knowledge. That's starting to get into routing. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 17:18: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 RAA27390 for ; Mon, 25 Jun 2001 17:18:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26127; Mon, 25 Jun 2001 17:09:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26094 for ; Mon, 25 Jun 2001 17:09:22 -0400 (EDT) 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 RAA27143 for ; Mon, 25 Jun 2001 17:08:43 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 5615F81C3 for ; Mon, 25 Jun 2001 16:09:23 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA13389 for ; Mon, 25 Jun 2001 16:09:23 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 25 Jun 2001 16:09:22 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt In-Reply-To: <00b901c0fdaa$c3864c40$2300000a@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 Mon, 25 Jun 2001, Bob Penfield wrote: > ----- Original Message ----- > From: > > While possible as an option I don't think openning ports to allow allow > data > > from unknown sources and ports is necessarily wise as a security policy > for > > a complete solution. We should allow for more precise cases where a more > > strict policy is applied( open an RTP stream from THIS source and port to > > THAT source and port.), shouldn't we? > > > Unfortunately, in SIPland, we don't know the source address and port. The > SDP in SIP messages contains only the receiving address and port for each > flow. There is no requirement with RTP for the sending address and port to > match the receiving address and port. Probably the best we could do is use a > prefix or netmask to narrow down the range of acceptable source addresses. The same is true of H.323. While we don't know where the RTP is coming from, we can (as Bob suggests) sometimes guess the general vicinity of the source as a network or something. This is the SIP Agent's problem, and presumably would be subject to customer configuration. More often, we know what interface the RTP will be coming from. For example, we might know that that RTP will be coming from the "outside" someplace, simply because we know it's not one of my internal phones. In general, the following information completely defines a 'pinhole': source address source port dest address dest port protocol (TCP, UDP, etc) expected ingress interface expected egress interface bidirectional-flag All of these fields, except the protocol can usefully be made "vector" as opposed to "scalar" quantities. That is, it makes sense to, in the fully general notion, specify a SET of source addresses, ports, dests, interfaces, and so on. In practice, a bitmask seems to suffice. It also seems to be widely implemented. It may be acceptable to standardize bitmasks (or even prefix lengths, that is, bitmasks which look like 111...111000...000) as the way MIDCOM does things? Pinhole specifications which work well for, say, RTP streams in SIP or H.323 look like: SA: 0.0.0.0 / 0.0.0.0 SP: 0 / 0 DA: 1.2.3.4 / 255.255.255.255 DP: 50000 / 0xfffe <-- allow ports 50,000 and 50,001 Proto: UDP Ingress: "Open" Egress: "Secure" Bidirectional: No A pinhole specification which would work well for active FTP might look like this: SA: 1.2.3.4 / 255.255.255.255 SP: 21 / 0xffff <-- assume "standard" server DA: 5.6.7.8 / 255.255.255.255 DP: 12980 / 0xffff Proto: TCP Ingress: "Open" Egress: "Secure" Bidirectional: Yes Or: SA: 1.2.3.4 / 255.255.255.255 SP: 0 / 0 <-- assume non-priv. server DA: 5.6.7.8 / 255.255.255.255 DP: 12980 / 0xffff Proto: TCP Ingress: "Open" Egress: "Secure" Bidirectional: Yes These two, being directional, could just as well be written the other way around, from the outside to the inside. Should there be additional stuff in there to specify which direction the data stream(s) corresponding to the pinhole can be created? That is, which way is a TCP SYN packet w/o ACK allowed to go? (This is the equivalent of cisco's 'established' keyword, or the Aravox 'tcp_connect_request' pattern, and everyone else in the world's own thing). Sometimes implementations allow (such as the one I work with daily) allow 'to', 'from' and 'bi-directional', where 'from' does nothing more than reverse the sense of source and dest. This is obviously redundant since the same effect can be obtained by reversing source and dest. I think it exists merely to satisfy someone's warped sense of symmetry. Note that the ingress/egress interface specification is more useful than merely testing spoofed addresses. In the RTP case, you don't even know the source port. The ingress interface specification can serve as a very coarse "source" check, though. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 17:22: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 RAA27474 for ; Mon, 25 Jun 2001 17:22:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26375; Mon, 25 Jun 2001 17:14:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26342 for ; Mon, 25 Jun 2001 17:14:34 -0400 (EDT) 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 RAA27273 for ; Mon, 25 Jun 2001 17:13:55 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id F3757813D for ; Mon, 25 Jun 2001 15:30:04 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA13720 for ; Mon, 25 Jun 2001 16:14:35 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 25 Jun 2001 16:14:35 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt In-Reply-To: <03f101c0fdad$557e8b60$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 Mon, 25 Jun 2001, Melinda Shore wrote: > > All I am saying is that we need to be able to associate a pin-hole spec with > > the specific network interface (or set of interfaces if there are redundant > > links) it should apply to. I don't think we need "direction" and > > "interface", just some sort of "interface" field. > > That makes more sense, but I think we need to work > through how the agent knows what the interfaces > are on the box, and how it makes use of that knowledge. > That's starting to get into routing. It's actually kind of awful how much the Agent needs to know about the middlebox. The issue of 'discover' versus 'configure' has been raised a few times. Is it extremely desirable to have the middlebox able to spill its guts vis-a-vis: - capabilities (NAT, pinholes, etc) - interfaces - plumbing (NAT after pinholes, NAT before pinholes, etc) - other? via MIDCOM, or is it acceptable or desirable to force this information to be configured into the Agent? Note that the 'discover' model is easy for middlebox vendors, since it's pretty much just serving up some static answers to one or more query methods. Figuring out what to DO with the information is a tricky one for the Agent, but it probably the same problem whether configured manually, or discovered. It's probably a little harder if discovered because there's no good way to punt. If the user is configuring it by hand, the Agent's GUI can just pop up a 'That won't WORK!' window by way of punting. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 18:02: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 SAA28184 for ; Mon, 25 Jun 2001 18:02:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27784; Mon, 25 Jun 2001 17:57:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27751 for ; Mon, 25 Jun 2001 17:57:22 -0400 (EDT) Received: from web13801.mail.yahoo.com (web13801.mail.yahoo.com [216.136.175.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28042 for ; Mon, 25 Jun 2001 17:56:42 -0400 (EDT) Message-ID: <20010625215719.47236.qmail@web13801.mail.yahoo.com> Received: from [65.12.33.187] by web13801.mail.yahoo.com; Mon, 25 Jun 2001 14:57:19 PDT Date: Mon, 25 Jun 2001 14:57:19 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 To: Scott Brim Cc: midcom@ietf.org In-Reply-To: <15152.49874.182000.181304@gargle.gargle.HOWL> 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: > On 19 Jun 2001 at 13:11 -0700, Pyda Srisuresh apparently wrote: > > 1. Paragraph 1 of section 1 - Introduction > > > > "Application Level gateways (ALGs) are used in conjunction with NAT > > to provide end-to-end transparency for many of the applications." > > > > I think, it should be OK to leave this unchanged. > > OK, we're talking about application-layer transparency. As long as you > mean that the application data and the application behavior are > unchanged, since that would fit the strict definition. I think I agree. > ALG does not guarantee that application data is not changed, even though its intention is to keep the application behaviour unchanged. It may in fact change the data in control payloads. So, the term "application level transparency" above doesnt meet the dictionary definition. Would the following rewording work for you? Application Level gateways (ALGs) are used in conjunction with NAT to examine and optionally modify application payload so the end-to-end application behaviour remains unchanged for many of the applications traversing NAT middleboxes. > > > > 3. Sectin 2.4. - NAT > > > > "Network Address Translation is a method by which IP addresses are > > mapped from one address realm to another, providing transparent > > routing to end-hosts." > > > > This definition is settled after a long series of discussion > > prior to advancing RFC 2663. The definition is carried as is > > from RFC 2663. I donot recommend changing this. > > The best you can claim for NAT is application-layer transparency. I Yes, but only per the dictionary definition. > assume that by routing you mean forwarding of packets from one interface > to another. That is an IP layer function, and it is certainly is not > transparent, in that NAT modifies at least the headers of those packets. > > Perhaps you could change "transparent routing" to "application-layer > transparency", but even that's debatable. > > I suggest you just claim something like application data transparency. > "Application layer transparency" may be OK per the semantics you ascribe to the term. But, that will most certainly confuse a different set of audience. I would rather avoid that can entirely. However, I do agree that precise meaning of the terms used must be understood by all readers alike. So, I could include text describing the term "transparent routing" as follows. Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end-hosts. Definition for the term "Transparent routing" may be found in [NAT-TERM]. Transparent routing refers to routing a datagram between disparate address realms, by translating addresses in IP headers so that when the packet leaves one realm and enters another, it can be routed properly. The reason the IESG agreed to the term "transparent routing" as opposed to "transparent forwarding" is the following. If the goal was simply to forward a datagram from private realm to public realm, there was no need to change the source IP address (from private address to an external assigned address). By changing the source address (i.e., the act of transparent routing), the NAT device is able to ensure that the external host would send the reply back to itself and NAT in turn could forward the reply datagram to the right end-host in private realm. Without the act of transparent routing, it would not have been possible for the reply datagram to be routed to the right end-host. This is a rehash of the discussion that transpired way back. Hope you understand. Thanks. > > 5. Paragraph 3 of section 5.2. - OOP MIDCOM agents > > > > "In essence, a middlebox provides to an Out-of-Path MIDCOM agent > > the ability to transparently "snoop" and modify the control > > traffic." > > > > I can reword the above as follows. > > > > "In essence, a middlebox provides to an Out-of-Path MIDCOM agent > > the same priveleges as that of an In-Path agent, to application > > control traffic, to "snoop" and modify as deemed appropriate." > > Hm, this now says that OOPAs have privileges (note spelling) for > application CONTROL traffic. I thought you wanted OOPAs to be able to > see all application traffic, not just signaling. If you eliminate "to > application control traffic" it makes sense to me. > OK. cheers, suresh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 20:29: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 UAA00700 for ; Mon, 25 Jun 2001 20:29:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02765; Mon, 25 Jun 2001 20:20:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02702 for ; Mon, 25 Jun 2001 20:20:05 -0400 (EDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00579 for ; Mon, 25 Jun 2001 20:19:26 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id TAA11431 for ; Mon, 25 Jun 2001 19:21:12 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 25 Jun 2001 19:13:37 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 19:19:25 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BBFEB@crchy271.us.nortel.com> From: "Sanjoy Sen" To: midcom@ietf.org Cc: "Sanjoy Sen" , "'richard.swale@bt.com'" , "'sijben@lucent.com'" , "'philip.mart@marconi.com'" , "'Melinda Shore'" Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 19:19:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FDD5.A405AA70" X-Orig: 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_001_01C0FDD5.A405AA70 Content-Type: text/plain; charset="iso-8859-1" Here're my comments/feedback on the Midcom requirements draft: ================ 1.1. Background Session *orientated* applications - Typo >This is because there are implicit relationships between individual packets that must be maintained between hosts across the network For completion, we should probably add to this sentence the following: "and this end-to-end relationship may be broken by the Middle-box." Section 3: Definition of flow - incomplete, need to add "over a specific transport protocol". 4.1. Middlebox functions > The Middlebox must support the explicit forwarding of application control session information received on one, or more, destination address/port combinations to an appropriate MIDCOM Agent(e.g. an application gateway) as described in section 7. This alludes to the diversion function, which should not be mandatory as per the current thoughts of the working group. Typo in line 4 of 4th para - MICOM should be MIDCOM 4.4. Distribution of MIDCOM elements >The Middlebox therefore needs to support multiple simultaneous MIDCOM Agents ... Suggest that we add "and vice-versa". 5. General Protocol Requirements >The MIDCOM protocol needs to address three distinct aspects:- - The association of MIDCOM Agents and Middleboxes - The establishment of an Application Control flow in conjunction with the Middlebox and an appropriate MIDCOM Agent - The establishment of an Application Content Flow through a Middlebox according to rules determined by an associated MIDCOM Agent The protocol need to address "establishment" as well as "termination" of Application control and content flows. Suggest that we also add a fourth bullet: "- Should allow messages to modify existing states during the run-time phase of the connection according to the rules determined by an associated MIDCOM Agent" Section 5.1. Typo in last but one line - "specify" instead of "specific" Suggest that the following sentence be added at the end of the section: "The protocol should allow the Midcom Agent manipulate individual connection leg/direction (through the Middle-box)." Section 5.2.1. Pin-hole Specification >The "Packet modifier" must be able to change the following protocol header fields IPv4: IP addresses, TOS field ... Packet modifiers will have different functions depending on the specific Middle-box. Hence, the "must" in the sentence above should be changed to "may". A minimal set pin-hole specification (which will be extensible) need to be defined. The specification shown in Section 5.2.1 can be there for the purpose of an example. These cannot be made mandatory at this stage. Suggest that we add the phrase "For example, " to the sentence "The requests communicated between a MIDCOM Agent and a Middlebox need to permit pin-holes ..." >This directionality shall be expressed as "in", "out" or "Loopback" (meaning both "in" and "out" of the same side of the same Middlebox realm). This directionality can be specified by other means too. Suggest that we add the sentence "The specification of the directionality should be kept implementation dependent." 5.3. Pin-hole operations >The MIDCOM protocol needs to support two basic operations; the opening an closing of pin-holes across a Middlebox. What about refreshing pin-hole states? Suggest that we change this sentence to the following: "The MIDCOM protocol needs to support three basic operations; the opening, closing and refreshing of pin-holes across a Middlebox." 5.3.2. Close Pin-Hole Suggest that we also add the case where the pin-hole will be closed when the media path communication is broken. In this scenario, the Middle-box should be able to report to the Midcom Agent about this status change. 5.4. Pin-Hole reporting "The Middle-box and the Midcom Agent should asynchronously be able to exchange resource availability information related to pin-holes." Suggest that we add a sentence like this in this section. 6. Agent and Middlebox association 6.1. Midcom Agent Registration Suggest that a brief description of the profile be added. Midcom Agent profile: The profile shall contain, at the very least, the identity of the Agent and the type of services that it may request. 6.3. Error handling Suggest that we add - "The Agent and the Middlebox need to exchange periodic keep-alive messages after the establishment of a communication session between the two. This shall enable removal of any pinhole state which had been established by an Agent which is no longer active. However, provision should be there to allow for fail-over protection (if any) to take place before the state is finally removed." Section 7 talks about diversion function, which as per the current thoughts of the WG, should at best be treated as optional. The text should be changed to reflect this. 9. Resource control requirements Suggest that we add, somewhat in similar vein to Section 5.4 above, - "The Middle-box and the Midcom Agent should asynchronously be able to exchange resource availability information. This will allow some flow admission control decisions to be off-loaded from the Middlebox to the Agent. Also, the Agent shall be able to independently control/manipulate the resources associated with the flow in each direction (e.g., each call leg)." 10.1. Status reporting Tracing exceptional situations & reporting to the Agent should be a requirement. "The Middlebox shall be able to capture logs of exceptional conditions (e.g., arrival of unauthorized packets) and report them to the Agent." 10.9. Protocol Performance >The protocol needs to support time-constrained operation to enable scalability of the complete solution ... Suggest that we add the following phrase after "solution": "and to minimize the impact on call set-up delay for certain types of multimedia applications." Regards, Sanjoy ------_=_NextPart_001_01C0FDD5.A405AA70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] draft-ietf-midcom-requirements-01.txt

Here're my comments/feedback on the Midcom = requirements draft:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1.1.   Background

Session *orientated* applications - Typo

>This is because there are implicit
         = relationships between individual packets that must be maintained =
         = between hosts across the network
       =20
For completion, we should probably add to this = sentence the following: "and this end-to-end relationship may be = broken by the Middle-box."

Section 3: Definition of flow - incomplete, need to = add "over a specific transport protocol".

4.1.   Middlebox functions

> The Middlebox must support the explicit = forwarding of application
         = control session information received on one, or more, destination =
         = address/port combinations to an appropriate MIDCOM Agent(e.g. an =
         = application gateway) as described in section 7.

This alludes to the diversion function, which should = not be mandatory as per the current thoughts of the working = group.

Typo in line 4 of 4th para - MICOM should be = MIDCOM

4.4.   Distribution of MIDCOM elements =

>The Middlebox therefore needs to support multiple = simultaneous MIDCOM
         = Agents ...

Suggest that we add "and = vice-versa".

5.     General Protocol = Requirements

>The MIDCOM protocol needs to address three = distinct aspects:-
         
           - = The association of MIDCOM Agents and Middleboxes
           - = The establishment of an Application Control flow in conjunction
          &nb= sp;  with the Middlebox and an appropriate MIDCOM Agent
           - = The establishment of an Application Content Flow through a
          &nb= sp;  Middlebox according to rules determined by an associated = MIDCOM
          &nb= sp;  Agent

The protocol need to address = "establishment" as well as "termination" of = Application control and content flows. Suggest that we also add a = fourth bullet:

        =         "- = Should allow messages to modify existing states during the run-time = phase of the
        =           = connection according to the rules determined by an associated MIDCOM = Agent"

Section 5.1. Typo in last but one line - = "specify" instead of "specific"

Suggest that the following sentence be added at the = end of the section: "The protocol should allow the Midcom Agent = manipulate individual connection leg/direction (through the = Middle-box)."

Section 5.2.1. Pin-hole Specification

>The "Packet modifier" must be able to = change the
         = following protocol header fields
          &nb= sp;  
          &nb= sp;  IPv4: IP addresses, TOS field  ...

Packet modifiers will have different functions = depending on the specific Middle-box. Hence, the "must" in = the sentence above should be changed to "may".

A minimal set pin-hole specification (which will be = extensible) need to be defined. The specification shown in Section = 5.2.1 can be there for the purpose of an example. These cannot be made = mandatory at this stage. Suggest that we add the phrase "For = example, " to the sentence "The requests communicated between = a MIDCOM Agent and a Middlebox need to permit pin-holes = ..."

>This directionality
         = shall be expressed as "in", "out" or = "Loopback" (meaning both "in"
         and = "out" of the same side of the same Middlebox realm).

This directionality can be specified by other means = too. Suggest that we add the sentence "The specification of the = directionality should be kept implementation = dependent."

5.3.   Pin-hole operations
         
>The MIDCOM protocol needs to support two basic = operations; the
         = opening an closing of pin-holes across a Middlebox.

What about refreshing pin-hole states? Suggest that = we change this sentence to the following: "The MIDCOM protocol = needs to support three basic operations; the opening, closing and = refreshing of pin-holes across a Middlebox."

5.3.2. Close Pin-Hole

Suggest that we also add the case where the pin-hole = will be closed when the media path communication is broken. In this = scenario, the Middle-box should be able to report to the Midcom Agent = about this status change.

5.4.   Pin-Hole reporting

"The Middle-box and the Midcom Agent should = asynchronously be able to exchange resource availability information = related to pin-holes." Suggest that we add a sentence like this in = this section.

6.     Agent and Middlebox = association

6.1.   Midcom Agent Registration

Suggest that a brief description of the profile be = added. Midcom Agent profile: The profile shall contain, at the very = least, the identity of the Agent and the type of services that it may = request.

 
6.3.   Error handling

Suggest that we add - "The Agent and the = Middlebox need to exchange periodic keep-alive messages after the = establishment of a communication session between the two. This shall = enable removal of any pinhole state which had been established by an = Agent which is no longer active. However, provision should be there to = allow for fail-over protection (if any) to take place before the state = is finally removed."

Section 7 talks about diversion function, which as = per the current thoughts of the WG, should at best be treated as = optional. The text should be changed to reflect this.

9.     Resource control = requirements

Suggest that we add, somewhat in similar vein to = Section 5.4 above, - "The Middle-box and the Midcom Agent should = asynchronously be able to exchange resource availability information. = This will allow some flow admission control decisions to be off-loaded = from the Middlebox to the Agent.

Also, the Agent shall be able to independently = control/manipulate the resources associated with the flow in each = direction (e.g., each call leg)."

10.1.  Status reporting

Tracing exceptional situations & reporting to the = Agent should be a requirement. "The Middlebox shall be able to = capture logs of exceptional conditions (e.g., arrival of unauthorized = packets) and report them to the Agent."

10.9.     Protocol = Performance

>The protocol needs to support time-constrained = operation to enable
         = scalability of the complete solution ...

Suggest that we add the following phrase after = "solution": "and to minimize the impact on call set-up = delay for certain types of multimedia applications."




Regards,
Sanjoy



















------_=_NextPart_001_01C0FDD5.A405AA70-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jun 25 21:01: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 VAA01187 for ; Mon, 25 Jun 2001 21:01:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04147; Mon, 25 Jun 2001 20:51:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04118 for ; Mon, 25 Jun 2001 20:51:47 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01031 for ; Mon, 25 Jun 2001 20:51:07 -0400 (EDT) Received: from 157.54.9.101 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Jun 2001 11:10:16 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Jun 2001 11:10:02 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 25 Jun 2001 11:10:01 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 25 Jun 2001 11:09:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Mon, 25 Jun 2001 11:09:32 -0700 Message-ID: Thread-Topic: [midcom] draft-ietf-midcom-requirements-01.txt Thread-Index: AcD9nw2K+2o3pluBRLCSTFkc81RE6QAArF8Q From: "Christian Huitema" To: , X-OriginalArrivalTime: 25 Jun 2001 18:09:32.0246 (UTC) FILETIME=[FBCD1F60:01C0FDA1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA04119 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: 8bit > > The requirement > > themselves should be split in three sections, functional > requirement, > > i.e. how to pass enough data to make the scenario work, security > > requirements, and operational requirements, i.e. how to > meet various > > performance and stability constraints. > > > > Isn't this the "classic mistake" of "how to" rather than "what"? Yup, I will grant you that one. "What is the required expressiveness of the protocol in order to make the scenarios work, what are the security requirements, what are the operational contraints such as performance and stability that must be satisfied. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 26 08:21: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 IAA29894 for ; Tue, 26 Jun 2001 08:21:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05143; Tue, 26 Jun 2001 08:10:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05112 for ; Tue, 26 Jun 2001 08:10:30 -0400 (EDT) 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 IAA29432 for ; Tue, 26 Jun 2001 08:09:49 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5QCA5N25823; Tue, 26 Jun 2001 05:10:05 -0700 (PDT) Received: from spandex (rtp-vpn-164.cisco.com [10.82.192.164]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AKY03767; Tue, 26 Jun 2001 05:09:56 -0700 (PDT) Message-ID: <020d01c0fe39$0d081b80$d45904d1@cisco.com> From: "Melinda Shore" To: "Andrew Molitor" , References: Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt Date: Tue, 26 Jun 2001 08:10:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > From: Andrew Molitor > To: > Sent: Monday, June 25, 2001 5:14 PM > Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt > The issue of 'discover' versus 'configure' has been raised > a few times. Is it extremely desirable to have the middlebox able to > spill its guts vis-a-vis: > - capabilities (NAT, pinholes, etc) > - interfaces > - plumbing (NAT after pinholes, NAT before pinholes, etc) > - other? > > via MIDCOM, or is it acceptable or desirable to force this > information to be configured into the Agent? Discovering middleboxes in the network is out of scope; discovering capabilities of "found" middleboxes is not. Nevertheless I think we're heading into the weeds and that we should stop. Our charter is limited and while we need to keep extensibility a priority we really should not be loading up on defined features that don't have applicability to the problem at hand. If someone really, really believes that we need to know what the interfaces on a middlebox are in order to support application traversal, they should explain 1) the problem they feel it solves, 2) why they feel it solves it, and 3) which other possible approaches to solving the problem were considered and rejected. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 26 11:21: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 LAA20303 for ; Tue, 26 Jun 2001 11:21:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12995; Tue, 26 Jun 2001 11:09:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12967 for ; Tue, 26 Jun 2001 11:09:53 -0400 (EDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18608 for ; Tue, 26 Jun 2001 11:09:13 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA17441 for ; Tue, 26 Jun 2001 10:10:58 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 26 Jun 2001 10:07:11 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 10:07:10 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BBFEF@crchy271.us.nortel.com> From: "Sanjoy Sen" To: "'Bob Penfield'" , Melinda Shore , Andrew Molitor , midcom Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Tue, 26 Jun 2001 10:07:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FE51.A911DC60" 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_001_01C0FE51.A911DC60 Content-Type: text/plain; charset="iso-8859-1" I think having the "direction" field is useful. For cases with NAPT and SIP, where the NAPT binding can be completed only in later phases of the session initiation and may be changed again later, the association of a direction parameter with the pinhole at least gives the Middle-box a sense of what kind of address to expect to complete the NAPT binding. This gives some added level of security. Sanjoy -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Sunday, June 24, 2001 7:30 AM To: Melinda Shore; Andrew Molitor; midcom Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt ----- Original Message ----- From: "Melinda Shore" To: "Bob Penfield" ; "Andrew Molitor" ; Sent: Sunday, June 24, 2001 8:02 AM Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt > > In order to ensure the > > desired packet forwarding/admission, the pin-hole would need to be > > associated with the interface that the packets would be arriving on. Packets > > arriving on the other interface that happen to match the source address > > prefix/mask for that pin-hole spec would be blocked. > > I think we're saying the same thing. Given that > we've got source addresses and destination addresses > in the IP headers, isn't putting additional directionality > information redundant (and potentially confusing if there > are conflicts)? I think you missed my point. What about a spoofed source address? Granted that stops only one kind of attack on only one side of the middlebox. Also, with all the multi-homing, redundant links and other kinds of complex routing isn't it possible, if the middlebox represents the destination address of a packet, that packets with the same source and destination could arrive at either side. Maybe that's a stretch, but I'm not a routing expert. If I am implementing a middlebox, being able to have a separate pin-hole tables for each interface is more efficient. Theses boxes usually need to operate at or near wire-speed. (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0FE51.A911DC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] draft-ietf-midcom-requirements-01.txt

I think having the "direction" field is = useful. For cases with NAPT and SIP, where the NAPT binding can be = completed only in later phases of the session initiation and may be = changed again later, the association of a direction parameter with the = pinhole at least gives the Middle-box a sense of what kind of address = to expect to complete the NAPT binding. This gives some added level of = security.

Sanjoy 

-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
Sent: Sunday, June 24, 2001 7:30 AM
To: Melinda Shore; Andrew Molitor; midcom
Subject: Re: [midcom] = draft-ietf-midcom-requirements-01.txt




----- Original Message -----
From: "Melinda Shore" = <mshore@cisco.com>
To: "Bob Penfield" = <bpenfield@acmepacket.com>; "Andrew Molitor"
<amolitor@visi.com>; = <midcom@ietf.org>
Sent: Sunday, June 24, 2001 8:02 AM
Subject: Re: [midcom] = draft-ietf-midcom-requirements-01.txt


> > In order to ensure the
> > desired packet forwarding/admission, the = pin-hole would need to be
> > associated with the interface that the = packets would be arriving on.
Packets
> > arriving on the other interface that = happen to match the source address
> > prefix/mask for that pin-hole spec would = be blocked.
>
> I think we're saying the same thing.  = Given that
> we've got source addresses and destination = addresses
> in the IP headers, isn't putting additional = directionality
> information redundant (and potentially = confusing if there
> are conflicts)?

I think you missed my point. What about a spoofed = source address? Granted
that stops only one kind of attack on only one side = of the middlebox. Also,
with all the multi-homing, redundant links and other = kinds of complex
routing isn't it possible, if the middlebox = represents the destination
address of a packet, that packets with the same = source and destination could
arrive at either side. Maybe that's a stretch, but = I'm not a routing expert.

If I am implementing a middlebox, being able to have = a separate pin-hole
tables for each interface is more efficient. Theses = boxes usually need to
operate at or near wire-speed.

(-:bob



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C0FE51.A911DC60-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 26 13:26: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 NAA28175 for ; Tue, 26 Jun 2001 13:26:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18366; Tue, 26 Jun 2001 13:09:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18335 for ; Tue, 26 Jun 2001 13:09:23 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27218 for ; Tue, 26 Jun 2001 13:08:42 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5QH8a419186 for ; Tue, 26 Jun 2001 13:08:36 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5QH8aV19157 for ; Tue, 26 Jun 2001 13:08:36 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FE62.C0802E90" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Tue, 26 Jun 2001 11:09:25 -0600 Message-ID: Thread-Topic: [midcom] draft-ietf-midcom-requirements-01.txt Thread-Index: AcD+UkF0gTyTRmgkTmCaK4lLg2eTfQADo3rA From: "Zmolek, Andrew (Andrew)" To: "Sanjoy Sen" , "Bob Penfield" , "Melinda Shore" , "Andrew Molitor" , "midcom" 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 multi-part message in MIME format. ------_=_NextPart_001_01C0FE62.C0802E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Supposing there were a "direction" or "interface" field as some have proposed, some underlying knowledge of the architecture around the middlebox must then be shared between the midcom agent and the middlebox. My question is whether this assumption is reasonable. It seems to me that either: =20 a) The specific architecture is just a local usage issue and the right thing will happen in any specific instance, no matter how many distinct networks are joined at the middlebox because the proper context is set in other ways. Or, =20 b) Specifying such a field useful only for a deployed agent/middlebox architecture conforming to a simplified general case and has no value for anything more complex. =20 On a related note: solving the spoofed address problem seems best done with protocols that passes both architecture and policy information. Does midcom really fit the bill for this? I'm not convinced of that at all. =20 --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Tuesday, June 26, 2001 9:07 AM To: 'Bob Penfield'; Melinda Shore; Andrew Molitor; midcom Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt I think having the "direction" field is useful. For cases with NAPT and SIP, where the NAPT binding can be completed only in later phases of the session initiation and may be changed again later, the association of a direction parameter with the pinhole at least gives the Middle-box a sense of what kind of address to expect to complete the NAPT binding. This gives some added level of security. Sanjoy =20 -----Original Message-----=20 From: Bob Penfield [ mailto:bpenfield@acmepacket.com ]=20 Sent: Sunday, June 24, 2001 7:30 AM=20 To: Melinda Shore; Andrew Molitor; midcom=20 Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt=20 ----- Original Message -----=20 From: "Melinda Shore" =20 To: "Bob Penfield" ; "Andrew Molitor"=20 ; =20 Sent: Sunday, June 24, 2001 8:02 AM=20 Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt=20 > > In order to ensure the=20 > > desired packet forwarding/admission, the pin-hole would need to be=20 > > associated with the interface that the packets would be arriving on. Packets=20 > > arriving on the other interface that happen to match the source address=20 > > prefix/mask for that pin-hole spec would be blocked.=20 >=20 > I think we're saying the same thing. Given that=20 > we've got source addresses and destination addresses=20 > in the IP headers, isn't putting additional directionality=20 > information redundant (and potentially confusing if there=20 > are conflicts)?=20 I think you missed my point. What about a spoofed source address? Granted=20 that stops only one kind of attack on only one side of the middlebox. Also,=20 with all the multi-homing, redundant links and other kinds of complex=20 routing isn't it possible, if the middlebox represents the destination=20 address of a packet, that packets with the same source and destination could=20 arrive at either side. Maybe that's a stretch, but I'm not a routing expert.=20 If I am implementing a middlebox, being able to have a separate pin-hole tables for each interface is more efficient. Theses boxes usually need to=20 operate at or near wire-speed.=20 (-:bob=20 _______________________________________________=20 midcom mailing list=20 midcom@ietf.org=20 http://www.ietf.org/mailman/listinfo/midcom =20 ------_=_NextPart_001_01C0FE62.C0802E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] draft-ietf-midcom-requirements-01.txt
Supposing there were a "direction" or = "interface" field=20 as some have proposed, some underlying knowledge of the architecture = around the=20 middlebox must then be shared between the midcom agent and the = middlebox. My=20 question is whether this assumption is reasonable. It seems to me that=20 either:
 
a) The=20 specific architecture is just a local usage issue and the right thing = will=20 happen in any specific instance, no matter how many distinct networks = are joined=20 at the middlebox because the proper context is set in = other ways.=20 Or,
 
b)=20 Specifying such a field useful only for a deployed agent/middlebox = architecture=20 conforming to a simplified general case and has no value for anything = more=20 complex.
 
On a=20 related note: solving the spoofed address problem seems best done with = protocols=20 that passes both architecture and policy information. Does midcom really = fit the=20 bill for this? I'm not convinced of that at all.
 

--Andy Zmolek
    Technology & = Standards=20 Engineer
      CTO=20 Standards
        Avaya=20 Inc.

          &= nbsp;=20 zmolek@avaya.com
         = ;    =20 +1 720 444 4001

-----Original Message-----
From: Sanjoy Sen=20 [mailto:sanjoy@nortelnetworks.com]
Sent: Tuesday, June 26, = 2001 9:07=20 AM
To: 'Bob Penfield'; Melinda Shore; Andrew Molitor;=20 midcom
Subject: RE: [midcom]=20 draft-ietf-midcom-requirements-01.txt

I think having the "direction" field is useful. For = cases with=20 NAPT and SIP, where the NAPT binding can be completed only in later = phases of=20 the session initiation and may be changed again later, the association = of a=20 direction parameter with the pinhole at least gives the Middle-box a = sense of=20 what kind of address to expect to complete the NAPT binding. This = gives some=20 added level of security.

Sanjoy 

-----Original Message-----
From: Bob=20 Penfield [mailto:bpenfield@acmepacket.com<= /A>]=20
Sent: Sunday, June 24, 2001 7:30 AM =
To: Melinda Shore; Andrew Molitor; midcom
Subject: Re: [midcom] = draft-ietf-midcom-requirements-01.txt=20




----- Original Message -----
From:=20 "Melinda Shore" <mshore@cisco.com>
To: = "Bob=20 Penfield" <bpenfield@acmepacket.com>; "Andrew Molitor" =
<amolitor@visi.com>; <midcom@ietf.org> =
Sent: Sunday, June 24, 2001 8:02 AM
Subject:=20 Re: [midcom] draft-ietf-midcom-requirements-01.txt


> > In order to ensure the
>=20 > desired packet forwarding/admission, the pin-hole would need to = be=20
> > associated with the interface that the = packets=20 would be arriving on.
Packets =
> > arriving on the other interface that happen to = match the=20 source address
> > prefix/mask for = that pin-hole=20 spec would be blocked.
>
> I think we're saying the same thing.  Given = that=20
> we've got source addresses and destination=20 addresses
> in the IP headers, isn't = putting=20 additional directionality
> information = redundant=20 (and potentially confusing if there
> are = conflicts)?

I think you missed my point. What about a spoofed = source=20 address? Granted
that stops only one kind of = attack on=20 only one side of the middlebox. Also,
with = all the=20 multi-homing, redundant links and other kinds of complex =
routing isn't it possible, if the middlebox represents the=20 destination
address of a packet, that = packets with the=20 same source and destination could
arrive at = either=20 side. Maybe that's a stretch, but I'm not a routing expert. =

If I am implementing a middlebox, being able to have = a=20 separate pin-hole
tables for each interface = is more=20 efficient. Theses boxes usually need to
operate at or=20 near wire-speed.

(-:bob



_______________________________________________=20
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom =

------_=_NextPart_001_01C0FE62.C0802E90-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 26 18:57:31 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 SAA05205 for ; Tue, 26 Jun 2001 18:57:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01344; Tue, 26 Jun 2001 18:50:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01317 for ; Tue, 26 Jun 2001 18:50:09 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03536 for ; Tue, 26 Jun 2001 18:49:29 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5QMncw26876 for ; Tue, 26 Jun 2001 23:49:38 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Tue, 26 Jun 2001 23:49:25 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 23:49:23 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C3044500F@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'march@cisco.com'" Cc: "'Midcom IETF (E-mail)'" Date: Tue, 26 Jun 2001 23:49:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0FE92.39A8AD90" Subject: [midcom] FW: I-D ACTION:draft-aoun-midcom-network-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_01C0FE92.39A8AD90 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FE92.39A8AD90" ------_=_NextPart_001_01C0FE92.39A8AD90 Content-Type: text/plain; charset="iso-8859-1" Hi, It's been a while since Elliot sent his draft middle box discovery requirements ID, and since then there were no discussions on middle box discovery. I wrote this small ID to stimulate interest on Middle Discovery procedures. I would like to see if there is still interest on the subject and how can we move this forward for IETF52 Comments are appreciated. Thanks Cedric -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, June 26, 2001 1:01 PM To: IETF-Announce; @loki.ietf.org@zrtps0jn Subject: I-D ACTION:draft-aoun-midcom-network-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network topology considerations in the MIDCOM Architectural framework Author(s) : C. Aoun Filename : draft-aoun-midcom-network-00.txt Pages : Date : 25-Jun-01 In the present Internet architecture, packet transparency is lost due to the introduction of Middle Boxes that either modifies the contents of the IP packet, or drops it (Ref [RFC2775]). This draft presents in the context of the MIDCOM workgroup framework several Middle Boxes network deployment scenarios that needs to be considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aoun-midcom-network-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-aoun-midcom-network-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-aoun-midcom-network-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_001_01C0FE92.39A8AD90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-aoun-midcom-network-00.txt

Hi,
 It's been a while since Elliot sent his draft = middle box discovery requirements ID, and since then there were no = discussions on middle box discovery.

I wrote this small ID to stimulate interest on Middle = Discovery procedures.
I would like to see if there is still interest on = the subject and how can we move this forward for IETF52
Comments are appreciated.
Thanks
Cedric


-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Tuesday, June 26, 2001 1:01 PM
To: IETF-Announce; @loki.ietf.org@zrtps0jn
Subject: I-D = ACTION:draft-aoun-midcom-network-00.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = Network topology considerations in the MIDCOM
          &nb= sp;           &nb= sp;   Architectural framework
        Author(s)       : C. Aoun
        Filename        : = draft-aoun-midcom-network-00.txt
        Pages           : =
        Date    =         : 25-Jun-01
       =20
In the present Internet architecture, packet = transparency is lost
due to the introduction of Middle Boxes that either = modifies the
contents of the IP packet, or drops it (Ref = [RFC2775]).
This draft presents in the context of the MIDCOM = workgroup framework
several Middle Boxes network deployment scenarios = that needs      
to be considered.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aoun-midcom-= network-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-aoun-midcom-network-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-aoun-midcom-network-00.txt".
       =20
NOTE:   The mail server at ietf.org can = return the document in
        MIME-encoded form by using the "mpack" = utility.  To use this
        feature, = insert the command "ENCODING mime" before the = "FILE"
        command.  To decode the response(s), you will need = "munpack" or
        a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
        exhibit = different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have = been split
        up into = multiple messages), so check your local documentation on
        how to = manipulate these messages.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C0FE92.39A8AD90-- ------_=_NextPart_000_01C0FE92.39A8AD90 Content-Type: message/rfc822 To: Subject: Date: Tue, 26 Jun 2001 13:00:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0FE92.39A8AD90" ------_=_NextPart_002_01C0FE92.39A8AD90 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C0FE92.39A8AD90" ------_=_NextPart_003_01C0FE92.39A8AD90 Content-Type: text/plain ------_=_NextPart_003_01C0FE92.39A8AD90 Content-Type: text/html

  ------_=_NextPart_003_01C0FE92.39A8AD90-- ------_=_NextPart_002_01C0FE92.39A8AD90 Content-Type: application/octet-stream; name="ATT98865" Content-Disposition: attachment; filename="ATT98865" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010625095443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aoun-midcom-network-00.txt ------_=_NextPart_002_01C0FE92.39A8AD90 Content-Type: message/external-body; site="internet-drafts"; dir="draft-aoun-midcom-network-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0FE92.39A8AD90-- ------_=_NextPart_000_01C0FE92.39A8AD90-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 26 19:43: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 TAA14442 for ; Tue, 26 Jun 2001 19:43:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02460; Tue, 26 Jun 2001 19:27:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02427 for ; Tue, 26 Jun 2001 19:27:00 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10774 for ; Tue, 26 Jun 2001 19:26:20 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA02433 for ; Tue, 26 Jun 2001 16:26:10 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA07007 for ; Tue, 26 Jun 2001 16:26:56 -0700 (PDT) Received: from xch-pssbh-01.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Tue, 26 Jun 2001 16:26:51 -0700 Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Jun 2001 16:26:50 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DDA@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Bob Penfield'" , midcom mail-list Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt Date: Tue, 26 Jun 2001 16:26:47 -0700 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 >From: Bob Penfield [mailto:bpenfield@acmepacket.com] >Sent: Friday, June 22, 2001 2:34 PM >I do not see a need to make an explicit distinction in the protocol between >control flows and content flows. The pin-hole request to allow the control >flow thru to an in-path agent is basically the same as a pin-hole request to >allow the content flow thru for a given session. Why does the middlebox need >to know that one pin-hole is for control flow and the other is for content >flow? Bob's interpretation of the text differs from mine, suggesting that the text should be clarified so that we can understand exactly what is being proposed. I understood the text to say that the Application Control Flow, mentioned in Section 7, would provide a mechanism for the Middlebox to ensure that the Midcom agent receive control information, I assume for the case of the OOP Agent (e.g., Section 7.1.1). I thus viewed it to be primarily a mechanism to support out-of-path Agents. Question: if we would restrict the protocol to solely in-path agents, will Section 7 and the Application Control Flow "go away"? If not, please identify what else this flow is accomplishing. The Application content flow, by contrast, is not actually discussed, despite it forming the header to Section 8. I presumed that the authors' intention for the content flow is that that it would occur in an unmodified state between the hosts and the middlebox, without any intermediate agency of the Midcom Agent. Would the authors please verify that this is correct? If it isn't, then please answer Bob's question above. I previously mentioned that our firewalls want to authenticate the hosts, in addition to the MidCom Agent. Towards that end I understand that the Source and Destination address of the Pinhole Descriptor, mentioned in Section 5.2.1, is the source/destination address of the communicating hosts, and not the source/destination address of the Midcom Agent and Middlebox. Since this point is very important, I would appreciate the authors explicitly verifying that this is their intention. Thanks! --Eric _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jun 26 19:54: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 TAA16821 for ; Tue, 26 Jun 2001 19:54:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03155; Tue, 26 Jun 2001 19:49:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03130 for ; Tue, 26 Jun 2001 19:49:49 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15614 for ; Tue, 26 Jun 2001 19:49:10 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA16281 for ; Tue, 26 Jun 2001 16:48:59 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA15704 for ; Tue, 26 Jun 2001 16:49:47 -0700 (PDT) Received: from xch-pssbh-01.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP for midcom@ietf.org; Tue, 26 Jun 2001 16:49:39 -0700 Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Jun 2001 16:49:38 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DDB@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: midcom mail-list Date: Tue, 26 Jun 2001 16:49:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] Confusion re. text in requirements-01 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 My first point is a question, the rest are text in requirements-01 that I wasn't able to grok. In Section 5.3.2 Where the communication relationship between a Middlebox and a MIDCOM Agent are broken, all existing pin-holes must be closed. Question: Are you requiring "keep alive" overheads? In Section 6 A given Middlebox may support multiple concurrent trust relationships with a number of MIDCOM Agents. Resources, such as a Pinhole- Descriptor, may be shared across MIDCOM Agents and a Middlebox. As Pinhole-Descriptors may be shared across Middlebox functions, a Pinhole-Descriptor may be created by one function, and terminated by a different one. Are these two separate paragraphs (thoughts) or a single one? That is, what is a "middlebox function" in this context? Is this text saying that different Midcom agents can terminate each others sessions? If so, what controls are there if they are located in different security domains? In Section 7.1 A MIDCOM Agent shall be able to request a pin-hole from a Middlebox for the purposes of establishing a presence on the external network. I don't understand what the authors are saying in this paragraph. In Section 10.8 If a peer does not understand an option it must be clear whether the action required is to proceed without the unknown attribute being taken into account or the request is to be rejected. Where attributes What is a "peer"? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 11:12: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 LAA20740 for ; Wed, 27 Jun 2001 11:12:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12232; Wed, 27 Jun 2001 11:00:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12192 for ; Wed, 27 Jun 2001 11:00:18 -0400 (EDT) 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 KAA15182 for ; Wed, 27 Jun 2001 10:59:37 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5RExtN17345; Wed, 27 Jun 2001 07:59:55 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-20.cisco.com [10.21.96.20]) by airborne.cisco.com (Mirapoint) with ESMTP id AEG16133; Wed, 27 Jun 2001 07:59:45 -0700 (PDT) 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: <15161.62687.533000.59760@gargle.gargle.HOWL> Date: Wed, 27 Jun 2001 10:59:43 -0400 To: "Fleischman, Eric W" Cc: midcom mail-list Subject: Re: [midcom] Confusion re. text in requirements-01 In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DDB@XCH-NW-01.nw.nos.boeing.com> References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DDB@XCH-NW-01.nw.nos.boeing.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 26 Jun 2001 at 16:49 -0700, Fleischman, Eric W apparently wrote: > In Section 5.3.2 > Where the communication relationship between a Middlebox and a MIDCOM > Agent are broken, all existing pin-holes must be closed. > > Question: Are you requiring "keep alive" overheads? The question is whether "we" are requiring them. A middlebox needs to be able to kill off pinholes for whatever reason. That means keeping state information, in order to remember to do so. That state could be an absolute timer, and that's a reasonable option but too rigid to have as the only one. The alternatives are observed traffic and/or keepalives. If an agent chooses to use an absolute timer, that's fine. If it chooses to use keepalives, who should be responsible for the keepalives? The middlebox has to have state anyway, in order to kill off the pinhole eventually. The agent *may* need state, but not all agents do. I'm leaning toward having the middlebox send a query toward the agent -- "do you still want this?", but I still haven't done a decent analysis. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 11:29: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 LAA02451 for ; Wed, 27 Jun 2001 11:29:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13449; Wed, 27 Jun 2001 11:19:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13381 for ; Wed, 27 Jun 2001 11:19:54 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25743 for ; Wed, 27 Jun 2001 11:19:13 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA11036 for ; Wed, 27 Jun 2001 10:20:03 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA28246 for ; Wed, 27 Jun 2001 08:19:50 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Wed, 27 Jun 2001 08:19:39 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Jun 2001 08:19:38 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DE1@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Scott Brim'" Cc: midcom mail-list Subject: RE: [midcom] Confusion re. text in requirements-01 Date: Wed, 27 Jun 2001 08:19:30 -0700 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 Scott, My own preference is to exclusively rely upon timers in the middlebox to close the pinholes, and I'd really prefer not having keep alives (believing they are non-elegant and waste bandwidth), but I will defer to the experience of those who have actually built these systems. Concerning your middlebox querying the Midcom Agents idea, that would be fine except for the question of how long a middlebox needs to wait before concluding that the Midcom Agent is gone. Lots of issues arise such as slow links, latencies due to the sheer remoteness of the Midcom Agent to the middlebox, and the possibility that the Midcom Agent is experiencing a DoS attack. Back in the 90s, many addressed this issue by waiting double the normal round-trip time. However, do the middleboxes want to keep such round-trip time statistics and is that approach still appropriate for a more-hostile Internet? What do you think? --Eric -----Original Message----- From: Scott Brim [mailto:sbrim@cisco.com] Sent: Wednesday, June 27, 2001 8:00 AM To: Fleischman, Eric W Cc: midcom mail-list Subject: Re: [midcom] Confusion re. text in requirements-01 On 26 Jun 2001 at 16:49 -0700, Fleischman, Eric W apparently wrote: > In Section 5.3.2 > Where the communication relationship between a Middlebox and a MIDCOM > Agent are broken, all existing pin-holes must be closed. > > Question: Are you requiring "keep alive" overheads? The question is whether "we" are requiring them. A middlebox needs to be able to kill off pinholes for whatever reason. That means keeping state information, in order to remember to do so. That state could be an absolute timer, and that's a reasonable option but too rigid to have as the only one. The alternatives are observed traffic and/or keepalives. If an agent chooses to use an absolute timer, that's fine. If it chooses to use keepalives, who should be responsible for the keepalives? The middlebox has to have state anyway, in order to kill off the pinhole eventually. The agent *may* need state, but not all agents do. I'm leaning toward having the middlebox send a query toward the agent -- "do you still want this?", but I still haven't done a decent analysis. ...Scott _______________________________________________ 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 Jun 27 13:10: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 NAA24715 for ; Wed, 27 Jun 2001 13:10:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18689; Wed, 27 Jun 2001 12:58:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18659 for ; Wed, 27 Jun 2001 12:58:05 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24123 for ; Wed, 27 Jun 2001 12:57:24 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA01098 for ; Wed, 27 Jun 2001 09:57:12 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA08205 for ; Wed, 27 Jun 2001 09:57:55 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP for midcom@ietf.org; Wed, 27 Jun 2001 09:57:44 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Jun 2001 09:57:41 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DE3@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: midcom@ietf.org Date: Wed, 27 Jun 2001 09:57:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] requirements-01 status 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, We've now had a flurry of emails on the requirements draft. Many important points have been made. However, what have we learned from this email: what is our status? I believe that we have consensus that directionality in the Pinhole-descriptor is redundant. Was there a consensus on Christian Huitema's posting where he said: >Next comment concerns the figure on page 6. The "Application Control >Flow" line should be removed. It it a throw back of the "OOP" debate; we >debated that OOP should maybe be mentioned in the framework with due >precautions; it certainly does not belong in the requirements. >Similarly, the paragraph that states that "The Middlebox must support >the explicit forwarding of application control session information" >should be removed, as well as the whole of section 7. I fully agree with Christian's comment here, except for the part about there being a consensus on OOP, which I feel was never reached. I think that our strong division on OOP will hinder our making progress and we really need a "Plan B" (i.e., a compromise). However, if I'm having a "senior moment" and there really was a compromise reached on OOP, is Christian's summary of it above accurate? If so, is the WG ready to accept his recommendation "as is"? --Eric _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 13:14: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 NAA24922 for ; Wed, 27 Jun 2001 13:14:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19262; Wed, 27 Jun 2001 13:03:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19233 for ; Wed, 27 Jun 2001 13:03:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24374 for ; Wed, 27 Jun 2001 13:02:34 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5RH2px06444; Wed, 27 Jun 2001 10:02:51 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-20.cisco.com [10.21.96.20]) by airborne.cisco.com (Mirapoint) with ESMTP id AEG18028; Wed, 27 Jun 2001 10:02:32 -0700 (PDT) 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: <15162.4518.245000.969028@gargle.gargle.HOWL> Date: Wed, 27 Jun 2001 13:02:30 -0400 To: "Christian Huitema" Cc: "midcom mail-list" Subject: RE: [midcom] Confusion re. text in requirements-01 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 Christian, I think we already have agreement on the possibilities (see, for example, my mail on June 15th). We should go further and narrow them down. A midcom protocol which requires agents and middleboxes to support all possible mechanisms for state control will not be lean and mean. Let's try to decide, up front, if some are universally better than others, or at least that some are no worse than others, and eliminate alternatives. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 13:40: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 NAA07912 for ; Wed, 27 Jun 2001 13:40:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18207; Wed, 27 Jun 2001 12:45:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18179 for ; Wed, 27 Jun 2001 12:45:24 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17869 for ; Wed, 27 Jun 2001 12:44:38 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Jun 2001 09:03:37 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Jun 2001 09:03:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 27 Jun 2001 09:03:15 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 27 Jun 2001 09:02:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Confusion re. text in requirements-01 Date: Wed, 27 Jun 2001 09:02:39 -0700 Message-ID: Thread-Topic: [midcom] Confusion re. text in requirements-01 Thread-Index: AcD/HSris7hCpN4cR8i+wD2WUU+AtwAA/ktQ From: "Christian Huitema" To: "Scott Brim" , "Fleischman, Eric W" Cc: "midcom mail-list" X-OriginalArrivalTime: 27 Jun 2001 16:02:41.0233 (UTC) FILETIME=[981C3410:01C0FF22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA18180 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: 8bit The current text introduces a confusion between the objective, which is garbage collection of stale pinholes, and the means, for which they suggest tying pinholes to a continued association between the agent and the firewall. There is no debate that there is a requirement to be able to perform efficient garbage collection. However, if you analyze the scenarios, you find the following usage: 1) Some holes are just open forever. An example would be, "map incoming connections on TCP port 25 to the internal mail server." 2) Some holes are open by a "controller" and may well be renewed or closed by another controller. Think of enabling firewall traversal for a legacy server that has does not understand midcom, using some kind of management console. I think that a good replacement would be the insertion of a text like what follows here: -- Begin proposed text -- A firewall control protocol will create "state" on both a firewall and an internal host. This state must be kept coherent. Failure to do so can result in the following anomalies: * An internal server is advertised in the DNS and is up and running on the internal network, but the firewall mapping has been lost: the external clients who attempt to use the service see their connection fail; the server does not receive any connection request. * An internal server crashes. A backup server tries to take over, but the port is still reserved to the previous server in the firewall; a request to map the same port to the new server is refused. * A connection between an internal host and an external peer has been established by a signaling server. The signaling server crashes, so that when the session ends there is no way to close the port in the firewall. The firewall maintains the port open, possibly forever. * A signaling server that had crashed comes back on line, and asks the firewall to close all ports open during the previous incarnation; as a result, media sessions between internal and external peers are suddenly interrupted. It is important that the firewall control protocol contains adequate ways to recover from the crash of either the firewall or the controlling device. Among the possible solutions are: * Assigning a time to live to all openings, * Allowing the firewall to close an opening if no traffic is observed during a specified time, * Allowing the firewall to close an opening upon the end of a TCP connection, * Allowing controllers to draw an inventory of the existing openings, * Allowing authorized entities, different from the original requester, to explicitly close existing openings. Each of these methods has advantages and drawbacks. For example, assigning a time to live guarantees that port openings will be automatically closed if the internal requester fails to renew the opening request, but it will cause media connections to be closed if a signaling server crashes. Allowing an automatic close after an observed lack of traffic would allow communication to persist even if a signaling server crashes, but require a steady flow of traffic; this is adequate for most multimedia applications, but inadequate for applications such as shared white boards, which can remain "silent" for long periods; it is also inadequate for servers who are waiting for external connections. The specific method of closing the state may in fact be a combination of these methods. -- End proposed text -- -- Christian Huitema > -----Original Message----- > From: Scott Brim [mailto:sbrim@cisco.com] > Sent: Wednesday, June 27, 2001 8:00 AM > To: Fleischman, Eric W > Cc: midcom mail-list > Subject: Re: [midcom] Confusion re. text in requirements-01 > > On 26 Jun 2001 at 16:49 -0700, Fleischman, Eric W apparently wrote: > > In Section 5.3.2 > > Where the communication relationship between a Middlebox and a MIDCOM > > Agent are broken, all existing pin-holes must be closed. > > > > Question: Are you requiring "keep alive" overheads? > > The question is whether "we" are requiring them. > > A middlebox needs to be able to kill off pinholes for whatever reason. > That means keeping state information, in order to remember to do so. > That state could be an absolute timer, and that's a reasonable option > but too rigid to have as the only one. The alternatives are observed > traffic and/or keepalives. If an agent chooses to use an absolute > timer, that's fine. If it chooses to use keepalives, who should be > responsible for the keepalives? The middlebox has to have state anyway, > in order to kill off the pinhole eventually. The agent *may* need > state, but not all agents do. I'm leaning toward having the middlebox > send a query toward the agent -- "do you still want this?", but I still > haven't done a decent analysis. > > ...Scott > > > _______________________________________________ > 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 Jun 27 13:47: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 NAA12205 for ; Wed, 27 Jun 2001 13:47:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20136; Wed, 27 Jun 2001 13:28:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20107 for ; Wed, 27 Jun 2001 13:28:38 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29442 for ; Wed, 27 Jun 2001 13:27:56 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA10186 for ; Wed, 27 Jun 2001 10:27:45 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA05940 for ; Wed, 27 Jun 2001 10:27:22 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Wed, 27 Jun 2001 10:27:19 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Jun 2001 10:27:18 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DE4@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Christian Huitema'" , Scott Brim Cc: midcom mail-list Subject: RE: [midcom] Confusion re. text in requirements-01 Date: Wed, 27 Jun 2001 10:27:17 -0700 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 Thank you, Christian, for this thought-provoking and valuable posting. I believe that your "holes are open forever" point (i.e., in your first set of bullets) is outside of our scope. That scenario has to do with the policies by which a firewall is initially configured, and is not subject to the additional class of "pinhole openings" which are within our charter. If we take the case of a single firewall supporting a very large campus, it is unlikely and non-scalable to imagine that that firewall can track the state of the many internal hosts which may easily number in the tens of thousands. It is more scalable for a midcom agent to track the state of the host which requested the services, but that agent will at most have visibility in the general case to the requesting machine, not the destination machine. Therefore I do not believe that there is any way for the firewall to know the state of its internal hosts, since the midcom agent may well be external to the firewall. Therefore, I see no way to avoid these anomalies and believe that the protocol must anticipate and expect these anomalies to occur -- and potentially compensate for them. What is an "internal host" to a firewall protecting a domain which includes another firewall protecting a subdomain? That is, are the hosts behind the second firewall an "internal host" to the outer firewall? (This isn't mythical, we've got this situation.) While I don't think we can do anything about your second set of bullets other than anticipate that these anomalies will occur, I do appreciate and value your (third) final set of bullets as viable alternatives for us to consider. Are you proposing that we leave it up to implementers to select one alternative, rather than designing one (or a subset) into the protocol? --Eric -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Wednesday, June 27, 2001 9:03 AM To: Scott Brim; Fleischman, Eric W Cc: midcom mail-list Subject: RE: [midcom] Confusion re. text in requirements-01 The current text introduces a confusion between the objective, which is garbage collection of stale pinholes, and the means, for which they suggest tying pinholes to a continued association between the agent and the firewall. There is no debate that there is a requirement to be able to perform efficient garbage collection. However, if you analyze the scenarios, you find the following usage: 1) Some holes are just open forever. An example would be, "map incoming connections on TCP port 25 to the internal mail server." 2) Some holes are open by a "controller" and may well be renewed or closed by another controller. Think of enabling firewall traversal for a legacy server that has does not understand midcom, using some kind of management console. I think that a good replacement would be the insertion of a text like what follows here: -- Begin proposed text -- A firewall control protocol will create "state" on both a firewall and an internal host. This state must be kept coherent. Failure to do so can result in the following anomalies: * An internal server is advertised in the DNS and is up and running on the internal network, but the firewall mapping has been lost: the external clients who attempt to use the service see their connection fail; the server does not receive any connection request. * An internal server crashes. A backup server tries to take over, but the port is still reserved to the previous server in the firewall; a request to map the same port to the new server is refused. * A connection between an internal host and an external peer has been established by a signaling server. The signaling server crashes, so that when the session ends there is no way to close the port in the firewall. The firewall maintains the port open, possibly forever. * A signaling server that had crashed comes back on line, and asks the firewall to close all ports open during the previous incarnation; as a result, media sessions between internal and external peers are suddenly interrupted. It is important that the firewall control protocol contains adequate ways to recover from the crash of either the firewall or the controlling device. Among the possible solutions are: * Assigning a time to live to all openings, * Allowing the firewall to close an opening if no traffic is observed during a specified time, * Allowing the firewall to close an opening upon the end of a TCP connection, * Allowing controllers to draw an inventory of the existing openings, * Allowing authorized entities, different from the original requester, to explicitly close existing openings. Each of these methods has advantages and drawbacks. For example, assigning a time to live guarantees that port openings will be automatically closed if the internal requester fails to renew the opening request, but it will cause media connections to be closed if a signaling server crashes. Allowing an automatic close after an observed lack of traffic would allow communication to persist even if a signaling server crashes, but require a steady flow of traffic; this is adequate for most multimedia applications, but inadequate for applications such as shared white boards, which can remain "silent" for long periods; it is also inadequate for servers who are waiting for external connections. The specific method of closing the state may in fact be a combination of these methods. -- End proposed text -- -- Christian Huitema > -----Original Message----- > From: Scott Brim [mailto:sbrim@cisco.com] > Sent: Wednesday, June 27, 2001 8:00 AM > To: Fleischman, Eric W > Cc: midcom mail-list > Subject: Re: [midcom] Confusion re. text in requirements-01 > > On 26 Jun 2001 at 16:49 -0700, Fleischman, Eric W apparently wrote: > > In Section 5.3.2 > > Where the communication relationship between a Middlebox and a MIDCOM > > Agent are broken, all existing pin-holes must be closed. > > > > Question: Are you requiring "keep alive" overheads? > > The question is whether "we" are requiring them. > > A middlebox needs to be able to kill off pinholes for whatever reason. > That means keeping state information, in order to remember to do so. > That state could be an absolute timer, and that's a reasonable option > but too rigid to have as the only one. The alternatives are observed > traffic and/or keepalives. If an agent chooses to use an absolute > timer, that's fine. If it chooses to use keepalives, who should be > responsible for the keepalives? The middlebox has to have state anyway, > in order to kill off the pinhole eventually. The agent *may* need > state, but not all agents do. I'm leaning toward having the middlebox > send a query toward the agent -- "do you still want this?", but I still > haven't done a decent analysis. > > ...Scott > > > _______________________________________________ > 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 Jun 27 14:33:28 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 OAA09888 for ; Wed, 27 Jun 2001 14:33:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22426; Wed, 27 Jun 2001 14:17:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22395 for ; Wed, 27 Jun 2001 14:17:40 -0400 (EDT) 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 OAA02316 for ; Wed, 27 Jun 2001 14:16:59 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 6A9898143 for ; Wed, 27 Jun 2001 12:32:12 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id NAA02303 for ; Wed, 27 Jun 2001 13:17:39 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Wed, 27 Jun 2001 13:17:39 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] Confusion re. text in requirements-01 In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DE1@XCH-NW-01.nw.nos.boeing.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 Wed, 27 Jun 2001, Fleischman, Eric W wrote: > Scott, > > My own preference is to exclusively rely upon timers in the middlebox > to close the pinholes, and I'd really prefer not having keep alives > (believing they are non-elegant and waste bandwidth), but I will defer > to the experience of those who have actually built these systems. I assume you still allow Agents to explicitly close pinholes? I had a bad moment when I read the first line, but I think you mean that timers, if used, should be in the middlebox itself. A wrinkle from SIP-land: A stateless SIP proxy operating as a MIDCOM Agent can get keepalives from the endpoints of a call, in the form of re-INVITEs. To the vast amusement of those of us not intimate with SIP, it turns out the re-INVITEs look pretty much like INVITEs, and a stateless proxy can't necessarily tell the difference. Thus, it becomes convenient to be able to express keepalive in the form of 'open a pinhole like this' and 'bind a NAT thing like this.' That is, if keepalives for the middlebox state generated by a request of some sort can be implemented by re-issuing the request, that is most helpful. Of course, this is simply propogating the behavior of SIP forward into MIDCOM, which might be considered brokenness-creep. On the other hand, this approach also solves some of the 'lost INVITE' cases for call setup. In short, Agents WILL issue what are semantically keepalives, in at least some cases. Whether they have an explicit keepalive method available remains open. Some Middleboxes, of course, will have internal timers for state, which timers will operate in one of a couple of different ways, as I and others have indicated. I am very dubious of a middlebox-to-Agent 'I am about to delete this, do you want it?' transaction. It screams of complexity and race conditions. What works for me is this (I know I am getting ahead of requirements into How To -- this is intended as an illustrative example, not a proposed protocol): - upon opening a pinhole or otherwise creating state, the Agent can specify a timeout value, and a type (which is either Activity Based or Absolute) - the reply from the middlebox can indicate (perhaps): OK I don't do timers at all, your state won't time out I don't do Activity Based timers so I used Absolute instead, with your timeout value I don't do Absolute timers, so you're getting my default Activity Based timeout of seconds - a request isomorphic to a previous request for which state still exists in the middlebox is considered a keepalive, and simply restarts middlebox timers (if any) for any associated state, and performs any other reasonable 'renewal' of the state. - the middlebox may implement a one-way 'I deleted this piece of state for this reason' alert/trap method to let Agents know when their state disappears. This set of methods seems to be to cover most of the bases, without being insanely complicated. It's nothing more than a small handful of reply codes, a specific requirement for what to do with duplicate requests, and an optional trap method. Apart from the notion of Absolute timers, and the proposed ability of the middlebox to do some sort of 'I can't do timers like that so I used this other thing', this set of methods has actually been built and works in the land of SIP. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 14:33:34 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 OAA09951 for ; Wed, 27 Jun 2001 14:33:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22533; Wed, 27 Jun 2001 14:18:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22460 for ; Wed, 27 Jun 2001 14:18:19 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02800 for ; Wed, 27 Jun 2001 14:17:38 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5RIHZ028919 for ; Wed, 27 Jun 2001 14:17:35 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 27 Jun 2001 14:17:39 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 14:17:42 -0400 Message-ID: From: "Fernando Cuervo" To: "'Fleischman, Eric W'" , "'Christian Huitema'" , Scott Brim Cc: midcom mail-list Subject: RE: [midcom] Confusion re. text in requirements-01 Date: Wed, 27 Jun 2001 14:17:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FF35.712A48C0" X-Orig: 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_001_01C0FF35.712A48C0 Content-Type: text/plain; charset="iso-8859-1" Christian, all, I believe it would be possible and necessary to support all alternatives in the third set of bullets. If we think of the MB as providing a "pinhole-service" to an agent , it might be possible to express the conditions of the "service" as either time-dependent, traffic-dependent (which includes a closed TCP connection ) or control-dependent (which may include authorised 3rd parties). One of the assumptions about MBs is that they are policy enabled, therefore, more complex behaviours could be implemented depending on the specific knowledge of the agent or the traffic. Ultimately, the "terms" of the "service" requested by the agent depend on stuff that only the agent may know (type of service, service behaviour when the controller crashes, etc.) Fernando Cuervo > -----Original Message----- > From: Fleischman, Eric W [SMTP:Eric.Fleischman@PSS.Boeing.com] > Sent: Wednesday, June 27, 2001 1:27 PM > To: 'Christian Huitema'; Scott Brim > Cc: midcom mail-list > Subject: RE: [midcom] Confusion re. text in requirements-01 > [Cuervo, Fernando [CAR:5N10:EXCH]] stuff removed... > While I don't think we can do anything about your second set of bullets > other than > anticipate that these anomalies will occur, I do appreciate and value your > (third) final > set of bullets as viable alternatives for us to consider. Are you > proposing that we > leave it up to implementers to select one alternative, rather than > designing one (or a > subset) into the protocol? > > --Eric > > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > [Cuervo, Fernando [CAR:5N10:EXCH]] stuff removed... > It is important that the firewall control protocol contains adequate > ways to recover from the crash of either the firewall or the controlling > device. Among the possible solutions are: > > * Assigning a time to live to all openings, > > * Allowing the firewall to close an opening if no traffic is > observed during a specified time, > > * Allowing the firewall to close an opening upon the end of a TCP > connection, > > * Allowing controllers to draw an inventory of the existing > openings, > > * Allowing authorized entities, different from the original > requester, to explicitly close existing openings. > > Each of these methods has advantages and drawbacks. For example, > assigning a time to live guarantees that port openings will be > automatically closed if the internal requester fails to renew the > opening request, but it will cause media connections to be closed if a > signaling server crashes. Allowing an automatic close after an observed > lack of traffic would allow communication to persist even if a signaling > server crashes, but require a steady flow of traffic; this is adequate > for most multimedia applications, but inadequate for applications such > as shared white boards, which can remain "silent" for long periods; it > is also inadequate for servers who are waiting for external connections. > The specific method of closing the state may in fact be a combination of > these methods. > > -- End proposed text -- > > -- Christian Huitema > > > -----Original Message----- > > From: Scott Brim [mailto:sbrim@cisco.com] > > Sent: Wednesday, June 27, 2001 8:00 AM > > To: Fleischman, Eric W > > Cc: midcom mail-list > > Subject: Re: [midcom] Confusion re. text in requirements-01 > > > > On 26 Jun 2001 at 16:49 -0700, Fleischman, Eric W apparently wrote: > > > In Section 5.3.2 > > > Where the communication relationship between a Middlebox and a > MIDCOM > > > Agent are broken, all existing pin-holes must be closed. > > > > > > Question: Are you requiring "keep alive" overheads? > > > > The question is whether "we" are requiring them. > > > > A middlebox needs to be able to kill off pinholes for whatever reason. > > That means keeping state information, in order to remember to do so. > > That state could be an absolute timer, and that's a reasonable option > > but too rigid to have as the only one. The alternatives are observed > > traffic and/or keepalives. If an agent chooses to use an absolute > > timer, that's fine. If it chooses to use keepalives, who should be > > responsible for the keepalives? The middlebox has to have state > anyway, > > in order to kill off the pinhole eventually. The agent *may* need > > state, but not all agents do. I'm leaning toward having the middlebox > > send a query toward the agent -- "do you still want this?", but I > still > > haven't done a decent analysis. > > > > ...Scott > > > > > > _______________________________________________ > > 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 ------_=_NextPart_001_01C0FF35.712A48C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Confusion re. text in requirements-01

Christian, = all,

I believe it would = be possible and necessary to support all alternatives in the third set = of bullets.
If we think of the = MB as providing a "pinhole-service" to an agent , it might be = possible to express the
conditions of the = "service" as either time-dependent, traffic-dependent (which = includes a closed TCP connection
) or = control-dependent (which may include authorised 3rd parties). One of = the assumptions about MBs is that
they are policy = enabled, therefore, more complex behaviours could be implemented = depending on
the specific = knowledge of the agent or the traffic. Ultimately, the = "terms" of the "service" requested by the = agent
depend on stuff = that only the agent  may know (type of service, service behaviour = when the controller crashes,
etc.)

Fernando = Cuervo

    -----Original Message-----
    From:   Fleischman, Eric W = [SMTP:Eric.Fleischman@PSS.Boeing.com]
    Sent:   Wednesday, June 27, 2001 1:27 PM
    To:     'Christian Huitema'; Scott Brim
    Cc:     midcom mail-list
    Subject:       = RE: [midcom] Confusion re. text in = requirements-01

    [Cuervo, = Fernando [CAR:5N10:EXCH]]  stuff removed...
    While I don't think we can do = anything about your second set of bullets other than
    anticipate that these anomalies will = occur, I do appreciate and value your (third) final
    set of bullets as viable alternatives = for us to consider. Are you proposing that we
    leave it up to implementers to select = one alternative, rather than designing one (or a
    subset) into the protocol?

    --Eric

    -----Original Message-----
    From: Christian Huitema = [mailto:huitema@windows.mic= rosoft.com]

    [Cuervo, = Fernando [CAR:5N10:EXCH]]  stuff removed...
    It is important that the firewall = control protocol contains adequate
    ways to recover from the crash of = either the firewall or the controlling
    device. Among the possible solutions = are:

    *       = Assigning a time to live to all openings,

    *       = Allowing the firewall to close an opening if no traffic is
    observed during a specified = time,

    *       = Allowing the firewall to close an opening upon the end of a TCP
    connection,

    *       = Allowing controllers to draw an inventory of the existing
    openings,

    *       = Allowing authorized entities, different from the original
    requester, to explicitly close = existing openings.

    Each of these methods has advantages = and drawbacks. For example,
    assigning a time to live guarantees = that port openings will be
    automatically closed if the internal = requester fails to renew the
    opening request, but it will cause = media connections to be closed if a
    signaling server crashes. Allowing an = automatic close after an observed
    lack of traffic would allow = communication to persist even if a signaling
    server crashes, but require a steady = flow of traffic; this is adequate
    for most multimedia applications, but = inadequate for applications such
    as shared white boards, which can = remain "silent" for long periods; it
    is also inadequate for servers who = are waiting for external connections.
    The specific method of closing the = state may in fact be a combination of
    these methods.

    -- End proposed text --

    -- Christian Huitema

    > -----Original Message-----
    > From: Scott Brim = [mailto:sbrim@cisco.com]
    > Sent: Wednesday, June 27, 2001 = 8:00 AM
    > To: Fleischman, Eric W
    > Cc: midcom mail-list
    > Subject: Re: [midcom] Confusion = re. text in requirements-01
    >
    > On 26 Jun 2001 at 16:49 -0700, = Fleischman, Eric W apparently wrote:
    > > In Section 5.3.2
    > > Where the communication = relationship between a Middlebox and a
    MIDCOM
    > > Agent are broken, all = existing pin-holes must be closed.
    > >
    > >     = Question: Are you requiring "keep alive" overheads?
    >
    > The question is whether = "we" are requiring them.
    >
    > A middlebox needs to be able to = kill off pinholes for whatever reason.
    > That means keeping state = information, in order to remember to do so.
    > That state could be an absolute = timer, and that's a reasonable option
    > but too rigid to have as the = only one.  The alternatives are observed
    > traffic and/or keepalives.  = If an agent chooses to use an absolute
    > timer, that's fine.  If it = chooses to use keepalives, who should be
    > responsible for the = keepalives?  The middlebox has to have state
    anyway,
    > in order to kill off the pinhole = eventually.  The agent *may* need
    > state, but not all agents = do.  I'm leaning toward having the middlebox
    > send a query toward the agent -- = "do you still want this?", but I
    still
    > haven't done a decent = analysis.
    >
    > ...Scott
    >
    >
    > = _______________________________________________
    > 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=

------_=_NextPart_001_01C0FF35.712A48C0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 15:12: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 PAA03058 for ; Wed, 27 Jun 2001 15:12:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24248; Wed, 27 Jun 2001 15:01:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24219 for ; Wed, 27 Jun 2001 15:01:13 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25316 for ; Wed, 27 Jun 2001 15:00:31 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA06153; Wed, 27 Jun 2001 12:00:19 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA08164; Wed, 27 Jun 2001 12:01:08 -0700 (PDT) Received: from xch-pssbh-01.nw.nos.boeing.com (xch-pssbh-01.nw.nos.boeing.com [192.42.227.32]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id f5RJ16701085; Wed, 27 Jun 2001 14:01:06 -0500 (CDT) Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Jun 2001 11:46:51 -0700 Message-ID: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DE7@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Andrew Molitor'" , midcom@ietf.org Subject: RE: [midcom] Confusion re. text in requirements-01 Date: Wed, 27 Jun 2001 11:46:51 -0700 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 >> Eric Fleischman wrote: >> My own preference is to exclusively rely upon timers in the >> middlebox to close the pinholes, and I'd really prefer not >> having keep alives (believing they are non-elegant and waste >> bandwidth), but I will defer to the experience of those who >> have actually built these systems. > >Andrew Molitor wrote: >I assume you still allow Agents to explicitly close pinholes? >I had a bad moment when I read the first line, but I think you mean >that timers, if used, should be in the middlebox itself. Thank you for pointing out the error in my careless writing. Yes, I indeed meant what you stated. I definitely wouldn't want to deprecate the midcom agent closing their own pinholes. > A wrinkle from SIP-land: A stateless SIP proxy operating as >a MIDCOM Agent can get keepalives from the endpoints of a call, in >the form of re-INVITEs. To the vast amusement of those of us not >intimate with SIP, it turns out the re-INVITEs look pretty much like >INVITEs, and a stateless proxy can't necessarily tell the difference. Perhaps I'm not correctly understanding your point, but the proposed keep-alives are between the Midcom Agent and the middlebox. The fact that a SIP proxy can be a Midcom Agent and that it can get periodic re-Invites does not, by itself, take us where we want to get. For example, it doesn't involve the Middlebox in those re-invites. Also, I am reluctant to build a framework which relies upon something which can happen, since that something can also not happen. That is, if we rely upon this "might happen" to become a "must happen" in order to support a (potentially complex) keep-alive scenario, then we've built in some fairly high risk fate sharing between Midcom and SIP, since it anticipates SIP changing their "may" into a "must". > I am very dubious of a middlebox-to-Agent 'I am about to delete >this, do you want it?' transaction. It screams of complexity and race >conditions. I share your sentiments. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 15:18: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 PAA07855 for ; Wed, 27 Jun 2001 15:18:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24398; Wed, 27 Jun 2001 15:06:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24369 for ; Wed, 27 Jun 2001 15:06:11 -0400 (EDT) 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 PAA28865 for ; Wed, 27 Jun 2001 15:05:30 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5RJ5ih15471; Wed, 27 Jun 2001 12:05:45 -0700 (PDT) Received: from spandex (rtp-vpn-199.cisco.com [10.82.192.199]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALE11088; Wed, 27 Jun 2001 12:04:52 -0700 (PDT) Message-ID: <03da01c0ff3c$39357820$d45904d1@cisco.com> From: "Melinda Shore" To: "Fleischman, Eric W" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DE3@XCH-NW-01.nw.nos.boeing.com> Subject: Re: [midcom] requirements-01 status Date: Wed, 27 Jun 2001 15:05:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 fully agree with Christian's comment here, except for the part about there being a > consensus on OOP, which I feel was never reached. There's strong feeling in both directions, which I'm about 75% certain will come back and dog us during the review process. I'm consulting with a Higher Power or two. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 15:39: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 PAA17754 for ; Wed, 27 Jun 2001 15:39:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24989; Wed, 27 Jun 2001 15:27:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24962 for ; Wed, 27 Jun 2001 15:27:39 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14167 for ; Wed, 27 Jun 2001 15:26:57 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5RJRFx02977 for ; Wed, 27 Jun 2001 12:27:15 -0700 (PDT) Received: from spandex (rtp-vpn-199.cisco.com [10.82.192.199]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALE12140; Wed, 27 Jun 2001 12:26:59 -0700 (PDT) Message-ID: <051e01c0ff3f$4681ad20$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Wed, 27 Jun 2001 15:27:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Out-of-path agents 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 Thumbs down - let's make text related to out-of-path agents and packet diversion disappear from the deliverables. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 16:29:31 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 QAA08424 for ; Wed, 27 Jun 2001 16:29:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26831; Wed, 27 Jun 2001 16:15:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26802 for ; Wed, 27 Jun 2001 16:15:09 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28485 for ; Wed, 27 Jun 2001 16:14:29 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AE528A4F0146; Wed, 27 Jun 2001 16:13:06 -0400 Message-ID: <002701c0ff44$f4143d40$2300000a@acmepacket.com> From: "Bob Penfield" To: "Fleischman, Eric W" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DE3@XCH-NW-01.nw.nos.boeing.com> Subject: Re: [midcom] requirements-01 status Date: Wed, 27 Jun 2001 16:08:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Fleischman, Eric W" To: Sent: Wednesday, June 27, 2001 12:57 PM Subject: [midcom] requirements-01 status > OK, We've now had a flurry of emails on the requirements draft. Many important points > have been made. However, what have we learned from this email: what is our status? > > I believe that we have consensus that directionality in the Pinhole-descriptor is redundant. I'm not sure I agree with this. I know we have gone back and forth on directionality and being able to associate a pinhole-descriptor with an interface. Could you summarize what you believe is the consensus on any requirements (or lack there of) for making sure that packets only flow thru the middlebox in the direction the MIDCOM Agents wants them to. > > Was there a consensus on Christian Huitema's posting where he said: > > >Next comment concerns the figure on page 6. The "Application Control > >Flow" line should be removed. It it a throw back of the "OOP" debate; we > >debated that OOP should maybe be mentioned in the framework with due > >precautions; it certainly does not belong in the requirements. > >Similarly, the paragraph that states that "The Middlebox must support > >the explicit forwarding of application control session information" > >should be removed, as well as the whole of section 7. > > I fully agree with Christian's comment here, except for the part about there being a > consensus on OOP, which I feel was never reached. I think that our strong division on > OOP will hinder our making progress and we really need a "Plan B" (i.e., a compromise). > However, if I'm having a "senior moment" and there really was a compromise reached on OOP, > is Christian's summary of it above accurate? If so, is the WG ready to accept his > recommendation "as is"? > > --Eric > > _______________________________________________ > 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 Jun 27 16:42: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 QAA17101 for ; Wed, 27 Jun 2001 16:42:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27558; Wed, 27 Jun 2001 16:31:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27532 for ; Wed, 27 Jun 2001 16:31:55 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09732 for ; Wed, 27 Jun 2001 16:31:14 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA27825 for ; Wed, 27 Jun 2001 13:31:05 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA29004 for ; Wed, 27 Jun 2001 13:31:53 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Wed, 27 Jun 2001 13:31:41 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Jun 2001 13:31:41 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEA@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Bob Penfield'" , midcom@ietf.org Subject: RE: [midcom] requirements-01 status Date: Wed, 27 Jun 2001 13:31:31 -0700 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 >> I believe that we have consensus that directionality in the >>Pinhole-descriptor is redundant. > >From: Bob Penfield [mailto:bpenfield@acmepacket.com] >I'm not sure I agree with this. I know we have gone back and forth on >directionality and being able to associate a pinhole-descriptor with an >interface. Could you summarize what you believe is the consensus on any >requirements (or lack there of) for making sure that packets only flow thru >the middlebox in the direction the MIDCOM Agents wants them to. Picture the following possible Pinhole-Descriptor values stored in a middlebox: S_Addr S_Port Protocol D_Addr D_Port 110.14.75.100 575 UDP 156.10.97.11 10600 156.10.97.11 10600 UDP 110.14.75.100 575 This is a bidirectional (duplex) flow. Delete one of these lines and it is a simplex connection. Please note that the Flow Direction tuple proposed in Section 5.2.1 is missing because that information is redundant (i.e., the flow direction is inherent going from the source address to destination address). _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 17:13:29 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 RAA07786 for ; Wed, 27 Jun 2001 17:13:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28595; Wed, 27 Jun 2001 17:03:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28567 for ; Wed, 27 Jun 2001 17:03:15 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29981 for ; Wed, 27 Jun 2001 17:02:34 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12611 for ; Wed, 27 Jun 2001 17:02:20 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12604 for ; Wed, 27 Jun 2001 17:02:20 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FF4C.96ACBFF8" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [midcom] requirements-01 status Date: Wed, 27 Jun 2001 15:03:17 -0600 Message-ID: Thread-Topic: [midcom] requirements-01 status Thread-Index: AcD/SItOyjeecvY8SP+ARnolvdDiKwAA1vPw From: "Zmolek, Andrew (Andrew)" To: "Fleischman, Eric W" , "Bob Penfield" , 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 multi-part message in MIME format. ------_=_NextPart_001_01C0FF4C.96ACBFF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > the flow direction is inherent going from the source address to=20 > destination address). This assumes the middlebox is smart enough to discern to which interface each rule applies. We should either capture that assumption or recognize the possibility that a poorly engineered middlebox could in theory allow spoofed packets to travel backwards, particularly if a wildcard is used. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 ------_=_NextPart_001_01C0FF4C.96ACBFF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] requirements-01 status

> the flow direction is inherent going from the = source address to
> destination address).

This assumes the middlebox is smart enough to discern = to which interface each rule applies. We should either capture that = assumption or recognize the possibility that a poorly engineered = middlebox could in theory allow spoofed packets to travel backwards, = particularly if a wildcard is used.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001

------_=_NextPart_001_01C0FF4C.96ACBFF8-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 17:20: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 RAA12387 for ; Wed, 27 Jun 2001 17:20:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28740; Wed, 27 Jun 2001 17:08:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28711 for ; Wed, 27 Jun 2001 17:08:06 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03622 for ; Wed, 27 Jun 2001 17:07:25 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AABAA850252; Wed, 27 Jun 2001 17:06:02 -0400 Message-ID: <007d01c0ff4c$50393e20$2300000a@acmepacket.com> From: "Bob Penfield" To: "Fleischman, Eric W" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEA@XCH-NW-01.nw.nos.boeing.com> Subject: Re: [midcom] requirements-01 status Date: Wed, 27 Jun 2001 17:01:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Fleischman, Eric W" To: "'Bob Penfield'" ; Sent: Wednesday, June 27, 2001 4:31 PM Subject: RE: [midcom] requirements-01 status > >> I believe that we have consensus that directionality in the > >>Pinhole-descriptor is redundant. > > > >From: Bob Penfield [mailto:bpenfield@acmepacket.com] > >I'm not sure I agree with this. I know we have gone back and forth on > >directionality and being able to associate a pinhole-descriptor with an > >interface. Could you summarize what you believe is the consensus on any > >requirements (or lack there of) for making sure that packets only flow thru > >the middlebox in the direction the MIDCOM Agents wants them to. > > Picture the following possible Pinhole-Descriptor values stored in a > middlebox: > S_Addr S_Port Protocol D_Addr D_Port > 110.14.75.100 575 UDP 156.10.97.11 10600 > 156.10.97.11 10600 UDP 110.14.75.100 575 > > This is a bidirectional (duplex) flow. Delete one of these lines and it > is a simplex connection. Please note that the Flow Direction tuple > proposed in Section 5.2.1 is missing because that information is redundant > (i.e., the flow direction is inherent going from the source address to > destination address). > So it does not matter what physical interface a packet comes in on, if it matches the pinhole-descriptor it gets through. People are really OK with this? I don't think I could sell a firewall that allowed that to any IT manager I know. In the firewall that we have, you have to specify the source and destination interfaces (LAN, WAN, DMZ, or * for any) as well as source and destination IP addresses. (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 18:14:34 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 SAA20214 for ; Wed, 27 Jun 2001 18:14:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00101; Wed, 27 Jun 2001 17:54:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00071 for ; Wed, 27 Jun 2001 17:54:14 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05542 for ; Wed, 27 Jun 2001 17:53:32 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5RLrWq19970 for ; Wed, 27 Jun 2001 17:53:32 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5RLrVv19964 for ; Wed, 27 Jun 2001 17:53:31 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FF53.B8C8BF4A" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [midcom] Out-of-path agents Date: Wed, 27 Jun 2001 15:54:21 -0600 Message-ID: Thread-Topic: [midcom] Out-of-path agents Thread-Index: AcD/QNAazNf7mZ3YRk6NLzmDcpJBIAAEpgZg From: "Zmolek, Andrew (Andrew)" To: "Melinda Shore" , 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 multi-part message in MIME format. ------_=_NextPart_001_01C0FF53.B8C8BF4A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It would be useful to understand the rationale behind this decision, even the decision isn't debatable. Could you elaborate? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, June 27, 2001 1:28 PM To: midcom@ietf.org Subject: [midcom] Out-of-path agents Thumbs down - let's make text related to out-of-path agents and packet diversion disappear from the deliverables. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0FF53.B8C8BF4A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Out-of-path agents

It would be useful to understand the rationale behind = this decision, even the decision isn't debatable. Could you = elaborate?

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Wednesday, June 27, 2001 1:28 PM
To: midcom@ietf.org
Subject: [midcom] Out-of-path agents


Thumbs down - let's make text related to out-of-path = agents and
packet diversion disappear from the = deliverables.

Thanks,

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/= mailman/listinfo/midcom

------_=_NextPart_001_01C0FF53.B8C8BF4A-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 18:23:07 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 SAA26163 for ; Wed, 27 Jun 2001 18:23:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00735; Wed, 27 Jun 2001 18:08:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00705 for ; Wed, 27 Jun 2001 18:08:43 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15729 for ; Wed, 27 Jun 2001 18:08:01 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA04361 for ; Wed, 27 Jun 2001 15:07:52 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA25587 for ; Wed, 27 Jun 2001 15:08:37 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Wed, 27 Jun 2001 15:08:22 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Jun 2001 15:08:22 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEF@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Bob Penfield'" , "Fleischman, Eric W" , midcom@ietf.org Subject: RE: [midcom] requirements-01 status Date: Wed, 27 Jun 2001 15:08:20 -0700 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 Bob Penfield wrote: >So it does not matter what physical interface a packet comes in on, if it >matches the pinhole-descriptor it gets through. People are really OK with >this? I don't think I could sell a firewall that allowed that to any IT >manager I know. > >In the firewall that we have, you have to specify the source and destination >interfaces (LAN, WAN, DMZ, or * for any) as well as source and destination >IP addresses. Wait a minute here, Bob. What this thread was talking about was that the FlowDirection tuple of the Pinhole-Descriptor proposed in Section 5.2.1 was redundant, and therefore should be eliminated. I don't think that there is any agreement yet on whether the resulting 5-tuple is a complete Pinhole-Descriptor or not. Why doesn't the list leverage your posting to discuss whether egress_port ingress_port are also descriptor requirements or not -- or whether additional information should be added to the descriptor. Question: If you are arguing that ingress_port and egress_port should be part of the descriptor, how will the Midcom Agent know that type of information -- and need it know it? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 18:44: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 SAA09975 for ; Wed, 27 Jun 2001 18:44:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01695; Wed, 27 Jun 2001 18:32:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01667 for ; Wed, 27 Jun 2001 18:32:03 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01707 for ; Wed, 27 Jun 2001 18:31:20 -0400 (EDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Jun 2001 11:11:51 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Jun 2001 11:11:41 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Jun 2001 11:11:51 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Jun 2001 11:11:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Confusion re. text in requirements-01 Date: Wed, 27 Jun 2001 11:11:10 -0700 Message-ID: Thread-Topic: [midcom] Confusion re. text in requirements-01 Thread-Index: AcD/Kvxc2coa96VPRFiZ5bt70ZBQBwAB3ZnA From: "Christian Huitema" To: "Scott Brim" Cc: "midcom mail-list" X-OriginalArrivalTime: 27 Jun 2001 18:11:10.0796 (UTC) FILETIME=[8B5E28C0:01C0FF34] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA01668 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: 8bit Well, I have this model of an "off line" agent that only connects to the middle box when it has something useful to say. The one thing I would not want is to associate validity of pinholes with the maintenance of a "session" between the midcom agent and the midcom box. The model of operation I believe we should enable is to associate a "lifetime" with every pinhole, and to have the possibility of setting that lifetime as "infinite." If a finite lifetime expires, the hole is automatically closed by the midcom box, unless an authorized controller renews it. A corollary of allowing infinite lifetime is that you have to have a way to perform an inventory, so an external manager can clear out the crumbs. (By the way, this is the model adopted by the UPNP forum for NAT traversal.) Don't get me wrong, I am not against the concept of having a session between an agent and the midcom box. There are good reasons to do that, such as factoring a single session based authentication for multiple midcom commands in a single session. Since authentication is likely to be heavy duty, the factoring can give a big performance boost in some configurations, e.g. sip proxy. But I believe that tying the lifetime of a pinhole to the life time of the session is just wrong. -- Christian Huitema > -----Original Message----- > From: Scott Brim [mailto:sbrim@cisco.com] > Sent: Wednesday, June 27, 2001 10:03 AM > To: Christian Huitema > Cc: midcom mail-list > Subject: RE: [midcom] Confusion re. text in requirements-01 > > Christian, I think we already have agreement on the possibilities (see, > for example, my mail on June 15th). We should go further and narrow > them down. A midcom protocol which requires agents and middleboxes to > support all possible mechanisms for state control will not be lean and > mean. Let's try to decide, up front, if some are universally better > than others, or at least that some are no worse than others, and > eliminate alternatives. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 19:17: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 TAA00710 for ; Wed, 27 Jun 2001 19:17:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02670; Wed, 27 Jun 2001 19:07:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02639 for ; Wed, 27 Jun 2001 19:07:02 -0400 (EDT) Received: from hotmail.com (f260.law9.hotmail.com [64.4.8.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24516 for ; Wed, 27 Jun 2001 19:06:21 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Jun 2001 16:06:31 -0700 Received: from 63.126.135.11 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Jun 2001 23:06:30 GMT X-Originating-IP: [63.126.135.11] From: "John LaCour" To: midcom@ietf.org Date: Wed, 27 Jun 2001 18:06:30 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jun 2001 23:06:31.0029 (UTC) FILETIME=[CD732250:01C0FF5D] Subject: [midcom] more general comments and comments on 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 Hello everyone. I've just caught up on reading the last few weeks messages and thought it would be a good time to share my thoughts with the working group. In a few of my comments I mention what I think Agents and Middleboxes should do. I want to be clear - I'm not advocating that we require agents or middleboxes to implement things in any particular way outside of the MIDCOM protocol itself. I'd also like to mention that I think its very important that we try to do things in a generic way so that we don't preclude any particular applications from using MIDCOM. This means being extensible and not necessarily supporting every application and topology initially. My apologies in advance if I've touched on things that have been resolved prior to my involvement in the working group. My comments on the recent Protocol Requirements and discussions: 1. I agree with Bob Penfield and Andrew Molitor that the MIDCOM protocol should support the ability to aggregate pin-holes and other requests so that they can be addressed as a unit. Presumably the Agent would provide some kind of group-id when making a request. This will also facilitate the objective of keeping the protocol less chatty by allowing a group of pin-holes to be closed at once (timers to be reset, etc.). Middleboxes and Agents aren't required to support this, but the protocol must support it. 2. Regarding Middleboxes redirecting flows to agents, I don't want to REQUIRE this. I would very much like to include in the MIDCOM protocol a request type which essentially accomplishes this. e.g. For traffic from A -> B now send it from A -> C. In most cases, the middlebox may perform essentially a NAT, but in the case of an already established TCP connection, it may proxy the connection hence the need for something different. 3. The whole issues of interfaces, flow direction, and what the agent is assumed to know about the network topology, etc. is a key decision. Fundamentally, an agent is requesting that the middlebox perform some function (or NOT perform some function). Whether the interfaces and direction is relevant depends on how the specific function is implemented varies by te middlebox. Before we can answer how relevant direction and interfaces are, I think we need to answer the question of whether we expect middlebox vendors to implement the function, i.e. 'open pin-hole', the same way. My position is that the we don't force middlebox vendors to implement the functions the same way. The protocol must support the optional delivery of all information from the agent to the middlebox. I believe this will include 'direction' and/or 'interface' for most middleboxes. I agree that including discovery of these things is something that we don't want to do in the protocol and therefore this will need to be administratively configured on the agent and middlebox. 4. I don't think we should require the middlebox to undo things it did on behalf of an agent when the agent deregisters or 'dies'. Some applications (bandwidth regulators, profanity sensors, anti-virus, intrusion detection systems, honeypots, etc.) may use midcom agents to request that the middlebox block network traffic. I don't want the middlebox to open this traffic back-up if the agent restarts. This also means we need to support 'close pin-hole' when there was never an 'open pin-hole'. The middlebox owns its resources and chooses its own implementation for garbage collection and (probably by policy) how to handle resources that were requested by agents that have disappeared or unregistered. This isn't to say we can't support timers for the requests... 5. The MIDCOM protocol must support time-out values such as those suggested by Andrew Molitor. Specifically, inactivity timeout and a hard time out. The MIDCOM agent is essentially a trusted party responsible (in the case of pin-holes) for helping managing security. Because the agent is closer to the application, it should help manage the length of time that the requested resources are available. 6. I don't want to preclude the middlebox from altering packet information. If a middlebox performs some function which alters packet data to faciliate the operation of an application, it may be advantageous for an agent to make smarter decisions about when the middlebox should perform that function. 7. In section 5 of the requirements, "...the MIDCOM protocol need to be extensible to allow the requirements of future applications..." What about vendor-specific extensions? I'd like to be able to use MIDCOM if I have a middlebox with a function that no other middlebox has. 8. In section 5.1 of Requirements, its mentioned the protocol may require NAT. I'd like get a bit more granular and say that the protocol must support the ability to request a NAT with specific addresses as well as the ability to request a NAT assignment from the middlebox. 9. Another general concern which needs to be addressed is the case where one or more agents request the same or overlapping resources from a middlebox. Each request from an agent will need to include a request-id or something similar so that the middlebox can keep track of the requests in some sort of state table. Without this, trying to figure out how to handle conflicting requests or multiple requests for the same thing gets really messy. 10. I'm not sure that individual message authentication is necessary if a lower layer protocol (TLS, SSL, IPSEC, etc.) provides for authentication of the data stream. Should we get all of the various MIDCOM drafts listed on the MIDCOM home page? Regards, -John -- John LaCour Technology Strategy johnlacour@hotmail.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 19:19: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 TAA02394 for ; Wed, 27 Jun 2001 19:19:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02730; Wed, 27 Jun 2001 19:08:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02699 for ; Wed, 27 Jun 2001 19:08:05 -0400 (EDT) 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 TAA25102 for ; Wed, 27 Jun 2001 19:07:24 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id BD9698116 for ; Wed, 27 Jun 2001 17:22:30 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id SAA18931 for ; Wed, 27 Jun 2001 18:08:04 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Wed, 27 Jun 2001 18:08:04 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] requirements-01 status In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEF@XCH-NW-01.nw.nos.boeing.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 Wed, 27 Jun 2001, Fleischman, Eric W wrote: > Bob Penfield wrote: > >So it does not matter what physical interface a packet comes in on, if it > >matches the pinhole-descriptor it gets through. People are really OK with > >this? I don't think I could sell a firewall that allowed that to any IT > >manager I know. > > > >In the firewall that we have, you have to specify the source and destination > >interfaces (LAN, WAN, DMZ, or * for any) as well as source and destination > >IP addresses. > > Wait a minute here, Bob. What this thread was talking about was > that the FlowDirection tuple of the Pinhole-Descriptor proposed > in Section 5.2.1 was redundant, and therefore should be eliminated. > I don't think that there is any agreement yet on whether the resulting > 5-tuple is a complete Pinhole-Descriptor or not. Why doesn't the > list leverage your posting to discuss whether egress_port ingress_port > are also descriptor requirements or not -- or whether additional > information should be added to the descriptor. There are at least two loosely related notions of directionality. A pinhole description can usefully say 'traffic originating from and going to ' as a unidirectional pinhole specification. By replacing the word from with the phrase 'to or from' the pinhole becomes the bidirectional equivalent. Of course, and are just some sort of endpoint specifications, in general. The other, related, notion we've been worrying about is whether and might not include interface names. That is, do we allow interface identifiers to be part of an endpoint description? [ this is, I think, the substance of Eric's remarks, rephrased in my own witty informal way. Right? ] There is a school of thought that says if the endpoint specifications include IP address, then interface information is redundant since everyone does IP address checking at the interface itself. Therefore the source IP address can only come from a specific interface, and a destination IP address can only be going to a specific interface, so why bother calling out the interfaces explicitly? Point 1: it is without a doubt a requirement to allow specification of unidirectional pinholes (see below), that is to say 'from A going to B, but not from B going to A' in a pinhole specification. Point 2: If you don't happen to know the IP addresses, it may well be useful to associate an interface name in the endpoint, so you don't have to say 'from anyplace to B', you can instead say, in effect 'from anyplace outside to B' or more usefully 'from anyplace on the DMZ to B.' It's not obvious to me that this is vastly useful, but it seems superficially an improvement. Why Point 1: In IP Telephony, your pinholes always look like 'allow UDP traffic from anywhere to '. If this implies the opposite direction of flow, you get: 'from to anywhere' as also permitted. This means that if I want to break into your network, all I have to do is call you, and keep you talking. I can then send UDP packets from my 'phone' into anywhere at all in your network. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 19:50: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 TAA22470 for ; Wed, 27 Jun 2001 19:50:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03868; Wed, 27 Jun 2001 19:40:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03801 for ; Wed, 27 Jun 2001 19:40:20 -0400 (EDT) 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 TAA15443 for ; Wed, 27 Jun 2001 19:39:39 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5RNdvN19439; Wed, 27 Jun 2001 16:39:57 -0700 (PDT) Received: from spandex (rtp-vpn-140.cisco.com [10.82.192.140]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALE22908; Wed, 27 Jun 2001 16:36:55 -0700 (PDT) Message-ID: <012e01c0ff62$4ca16f60$d45904d1@cisco.com> From: "Melinda Shore" To: "Zmolek, Andrew (Andrew)" , References: Subject: Re: [midcom] Out-of-path agents Date: Wed, 27 Jun 2001 19:28:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > From: Zmolek, Andrew (Andrew) > To: Melinda Shore ; > Sent: Wednesday, June 27, 2001 5:54 PM > Subject: RE: [midcom] Out-of-path agents > It would be useful to understand the rationale behind this decision, > even the decision isn't debatable. Could you elaborate? Basically, 1) it wasn't part of the original proposal, 2) we're going to be held to our charter, 3) it's controversial, which makes it harder to justify. I think we need to treat this as an admonition to be serious about our sticking to our charter and deliverables. If you're not clear about the reasons it's controversial within the IETF and what the architectural issues are, you should take a look at last week's OPES discussion on the general IETF mailing list. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jun 27 19:51: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 TAA23152 for ; Wed, 27 Jun 2001 19:51:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03914; Wed, 27 Jun 2001 19:40:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03878 for ; Wed, 27 Jun 2001 19:40:25 -0400 (EDT) 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 TAA15488 for ; Wed, 27 Jun 2001 19:39:45 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5RNdxh08178; Wed, 27 Jun 2001 16:39:59 -0700 (PDT) Received: from spandex (rtp-vpn-140.cisco.com [10.82.192.140]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALE22946; Wed, 27 Jun 2001 16:38:14 -0700 (PDT) Message-ID: <012f01c0ff62$664bdea0$d45904d1@cisco.com> From: "Melinda Shore" To: "Bob Penfield" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEA@XCH-NW-01.nw.nos.boeing.com> <007d01c0ff4c$50393e20$2300000a@acmepacket.com> Subject: Re: [midcom] requirements-01 status Date: Wed, 27 Jun 2001 19:37:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > So it does not matter what physical interface a packet comes in on, if it > matches the pinhole-descriptor it gets through. People are really OK with > this? I don't think I could sell a firewall that allowed that to any IT > manager I know. Firewalls and routers do this today (do ingress/egress filtering). This is something that presumably will be static and integral to the middlebox and its interfaces, handled through whatever management tools are used for the middlebox, and not something that's going to be changed on the fly by a midcom agent. Requiring that agents have knowledge of network topology to that level of detail is unnecessary and complex and difficult and unnecessary. We don't need it, either. Let's stick to the problem of providing an interface between applications and firewalls/NATs. Please - when advocating for something funky, 1) provide a use case, 2) let us know what other possible solutions were considered and rejected, and 3) why you think that your suggestion is the preferred one. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 04:58: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 EAA09586 for ; Thu, 28 Jun 2001 04:58:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00097; Thu, 28 Jun 2001 04:42:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00064 for ; Thu, 28 Jun 2001 04:42:20 -0400 (EDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09442 for ; Thu, 28 Jun 2001 04:41:38 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 28 Jun 2001 08:49:09 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Thu, 28 Jun 2001 08:48:56 +0100 Message-ID: To: Eric.Fleischman@pss.boeing.com, midcom@ietf.org Subject: RE: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 08:41:07 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 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 Eric, I'm not sure that concensus has been reached on the pin-hole direction issue because we are still discussing the multiple interfaces issue. In many respects this is one and the same problem i.e. what view of the Middlebox, its physical connections and flows that cross it are made available via the MIDCOM protocol to a MIDCOM Agent wishing to use the services provided by the Middlebox to enable a given application to work correctly. regards Richard > -----Original Message----- > From: Fleischman, Eric W [mailto:Eric.Fleischman@PSS.Boeing.com] > Sent: 27 June 2001 17:58 > To: midcom@ietf.org > Subject: [midcom] requirements-01 status > > > OK, We've now had a flurry of emails on the requirements > draft. Many important points > have been made. However, what have we learned from this > email: what is our status? > > I believe that we have consensus that directionality in the > Pinhole-descriptor is redundant. > > Was there a consensus on Christian Huitema's posting where he said: > > >Next comment concerns the figure on page 6. The "Application Control > >Flow" line should be removed. It it a throw back of the > "OOP" debate; we > >debated that OOP should maybe be mentioned in the framework with due > >precautions; it certainly does not belong in the requirements. > >Similarly, the paragraph that states that "The Middlebox must support > >the explicit forwarding of application control session information" > >should be removed, as well as the whole of section 7. > > I fully agree with Christian's comment here, except for the > part about there being a > consensus on OOP, which I feel was never reached. I think > that our strong division on > OOP will hinder our making progress and we really need a > "Plan B" (i.e., a compromise). > However, if I'm having a "senior moment" and there really was > a compromise reached on OOP, > is Christian's summary of it above accurate? If so, is the WG > ready to accept his > recommendation "as is"? > > --Eric > > _______________________________________________ > 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 Jun 28 11:12: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 LAA11686 for ; Thu, 28 Jun 2001 11:12:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13432; Thu, 28 Jun 2001 10:54:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13404 for ; Thu, 28 Jun 2001 10:54:05 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28276 for ; Thu, 28 Jun 2001 10:53:21 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A48BACF0252; Thu, 28 Jun 2001 10:51:55 -0400 Message-ID: <010501c0ffe0$fb6dad00$2300000a@acmepacket.com> From: "Bob Penfield" To: "John LaCour" , References: Subject: Re: [midcom] more general comments and comments on Requirements Date: Thu, 28 Jun 2001 10:45:32 -0400 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 Hi John, I agree with most of your comments. I have a few embellishments detailed below. ----- Original Message ----- From: "John LaCour" To: Sent: Wednesday, June 27, 2001 7:06 PM Subject: [midcom] more general comments and comments on Requirements > Hello everyone. I've just caught up on reading the last > few weeks messages and thought it would be a good time to > share my thoughts with the working group. > > In a few of my comments I mention what I think Agents > and Middleboxes should do. I want to be clear - I'm not > advocating that we require agents or middleboxes to implement > things in any particular way outside of the MIDCOM protocol > itself. > > I'd also like to mention that I think its very important > that we try to do things in a generic way so that we don't > preclude any particular applications from using MIDCOM. > This means being extensible and not necessarily supporting > every application and topology initially. > > My apologies in advance if I've touched on things that have been > resolved prior to my involvement in the working group. > > > My comments on the recent Protocol Requirements and discussions: > > > 1. I agree with Bob Penfield and Andrew Molitor that the MIDCOM > protocol should support the ability to aggregate pin-holes > and other requests so that they can be addressed as a unit. > Presumably the Agent would provide some kind of group-id when > making a request. The group/session id could be defined by the agent or by the middlebox. If we decide that the agent defines it, we need to way to make sure the id is unique such that multiple agents connecting to the middlebox do not use duplicate ids. I personally would like the protocol to support a middlebox which gives out an id at the request of the agent. > > This will also facilitate the objective of keeping the protocol > less chatty by allowing a group of pin-holes to be closed > at once (timers to be reset, etc.). > > Middleboxes and Agents aren't required to support this, but the > protocol must support it. > > > 2. Regarding Middleboxes redirecting flows to agents, I don't > want to REQUIRE this. > > I would very much like to include in the MIDCOM protocol a > request type which essentially accomplishes this. e.g. > For traffic from A -> B now send it from A -> C. In most > cases, the middlebox may perform essentially a NAT, but in > the case of an already established TCP connection, it > may proxy the connection hence the need for something different. > > > 3. The whole issues of interfaces, flow direction, and what the agent > is assumed to know about the network topology, etc. is a key > decision. > > Fundamentally, an agent is requesting that the middlebox perform > some function (or NOT perform some function). Whether the > interfaces and direction is relevant depends on how the specific > function is implemented varies by te middlebox. Before we can > answer how relevant direction and interfaces are, I think we need > to answer the question of whether we expect middlebox vendors to > implement the function, i.e. 'open pin-hole', the same way. > > My position is that the we don't force middlebox vendors to > implement the functions the same way. The protocol must support > the optional delivery of all information from the agent to the > middlebox. I believe this will include 'direction' > and/or 'interface' for most middleboxes. I agree that including > discovery of these things is something that we don't want to do in > the protocol and therefore this will need to be administratively > configured on the agent and middlebox. I agree!! If a middlebox does not support 'direction' or 'interface', that's fine. But if it does, the agent should be able include that information in its pin-hole requests. As far as interface, what I want to be able to express is the domain/realm an interface or set of interfaces is connected to. If a middlebox is connected to only two domains/realms, a 'direction' would suffice. The middlebox and the agent would have to be configured the same so that both knew which was inside and which was outside. If a middlebox is connected to more than two domains/realms, both the middlebox and the agent would have to be configured with the same set of names or ids for those domains/realms. The association of the names or ids with physical interfaces is up to the middlebox. > > > 4. I don't think we should require the middlebox to undo things it > did on behalf of an agent when the agent deregisters or 'dies'. > > Some applications (bandwidth regulators, profanity sensors, > anti-virus, intrusion detection systems, honeypots, etc.) may use > midcom agents to request that the middlebox block network traffic. > I don't want the middlebox to open this traffic back-up if the agent > restarts. This also means we need to support 'close pin-hole' when > there was never an 'open pin-hole'. > > The middlebox owns its resources and chooses its own implementation > for garbage collection and (probably by policy) how to handle > resources that were requested by agents that have disappeared or > unregistered. This isn't to say we can't support timers for the > requests... > > > 5. The MIDCOM protocol must support time-out values such as those > suggested by Andrew Molitor. Specifically, inactivity timeout and > a hard time out. The MIDCOM agent is essentially a trusted party > responsible (in the case of pin-holes) for helping managing security. > Because the agent is closer to the application, it should help manage > the length of time that the requested resources are available. > > > 6. I don't want to preclude the middlebox from altering packet > information. If a middlebox performs some function which alters > packet data to faciliate the operation of an application, it may be > advantageous for an agent to make smarter decisions about when the > middlebox should perform that function. > > > 7. In section 5 of the requirements, "...the MIDCOM protocol need to be > extensible to allow the requirements of future applications..." > > What about vendor-specific extensions? I'd like to be able to use > MIDCOM if I have a middlebox with a function that no other middlebox > has. > > > 8. In section 5.1 of Requirements, its mentioned the protocol may > require NAT. I'd like get a bit more granular and say that the > protocol must support the ability to request a NAT with specific > addresses as well as the ability to request a NAT assignment from > the middlebox. > > > 9. Another general concern which needs to be addressed is the case > where one or more agents request the same or overlapping resources > from a middlebox. Each request from an agent will need to include a > request-id or something similar so that the middlebox can keep track > of the requests in some sort of state table. Without this, trying to > figure out how to handle conflicting requests or multiple requests > for the same thing gets really messy. > > > 10. I'm not sure that individual message authentication is necessary if a > lower layer protocol (TLS, SSL, IPSEC, etc.) provides for > authentication of the data stream. > > > Should we get all of the various MIDCOM drafts listed on the MIDCOM > home page? > > > Regards, > -John > -- > John LaCour > Technology Strategy > johnlacour@hotmail.com > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.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 Thu Jun 28 13:56:57 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 NAA07765 for ; Thu, 28 Jun 2001 13:56:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22446; Thu, 28 Jun 2001 13:50:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22417 for ; Thu, 28 Jun 2001 13:50:26 -0400 (EDT) Received: from nemo.corp.equinix.com (somehost-5.equinix.net [207.20.85.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02543 for ; Thu, 28 Jun 2001 13:49:44 -0400 (EDT) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id KAA12632; Thu, 28 Jun 2001 10:49:48 -0700 (PDT) Message-Id: <200106281749.KAA12632@nemo.corp.equinix.com> Subject: Re: [midcom] more general comments and comments on Requirements To: johnlacour@hotmail.com (John LaCour) Date: Thu, 28 Jun 2001 10:49:48 -0700 (PDT) Cc: midcom@ietf.org In-Reply-To: from "John LaCour" at Jun 27, 2001 06:06:30 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 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 John LaCour writes: > 4. I don't think we should require the middlebox to undo things it > did on behalf of an agent when the agent deregisters or 'dies'. > > Some applications (bandwidth regulators, profanity sensors, > anti-virus, intrusion detection systems, honeypots, etc.) may use > midcom agents to request that the middlebox block network traffic. > I don't want the middlebox to open this traffic back-up if the agent > restarts. This also means we need to support 'close pin-hole' when > there was never an 'open pin-hole'. > > The middlebox owns its resources and chooses its own implementation > for garbage collection and (probably by policy) how to handle > resources that were requested by agents that have disappeared or > unregistered. This isn't to say we can't support timers for the > requests... A variant of the need to support 'close pin-hole' when there was never an 'open pin-hole' might also arise when there are multiple midcom agents which might address the same middle box. A midcom agent which was not the requestor of a pin-hole might request that a pin-hole be closed. There are obvious rights and privileges issues here, but I think we do need to build appropriately secure methods for this into the protocol. > > 6. I don't want to preclude the middlebox from altering packet > information. If a middlebox performs some function which alters > packet data to faciliate the operation of an application, it may be > advantageous for an agent to make smarter decisions about when the > middlebox should perform that function. Boy, do I not want to go down *this* rathole. As Melinda mentioned, anyone with a taste for why not should look at the discussion of OPES on the main IETF mailing list. Let the Midcom agents' role be limited to asking that a flow be permitted, and let the middlebox make the decisions about how the permitted flow should be treated. regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 14:08: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 OAA16012 for ; Thu, 28 Jun 2001 14:08:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23104; Thu, 28 Jun 2001 14:01:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23066 for ; Thu, 28 Jun 2001 14:01:10 -0400 (EDT) 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 OAA10383 for ; Thu, 28 Jun 2001 14:00:28 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id SAA07191; Thu, 28 Jun 2001 18:01:05 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 28 Jun 2001 18:01:04 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 11:01:03 -0700 Message-ID: From: "Maciocco, Christian" To: "'John LaCour'" , midcom@ietf.org Subject: RE: [midcom] more general comments and comments on Requirements Date: Thu, 28 Jun 2001 11:00:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > 6. I don't want to preclude the middlebox from altering packet > information. If a middlebox performs some function which alters > packet data to faciliate the operation of an application, it may be > advantageous for an agent to make smarter decisions about when the > middlebox should perform that function. John, OPES, if chartered as a WG will look at these issues. There was quite some discussions the last two weeks on the IETF mailing list and the proposed OPES group list (ietf-openproxy@imc.org) Christian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 14:33:04 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 OAA03613 for ; Thu, 28 Jun 2001 14:33:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24265; Thu, 28 Jun 2001 14:28:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24233 for ; Thu, 28 Jun 2001 14:27:58 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29456 for ; Thu, 28 Jun 2001 14:27:16 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A6AD8C850146; Thu, 28 Jun 2001 14:25:49 -0400 Message-ID: <018201c0fffe$bb9a46c0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Melinda Shore" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEA@XCH-NW-01.nw.nos.boeing.com> <007d01c0ff4c$50393e20$2300000a@acmepacket.com> <012f01c0ff62$664bdea0$d45904d1@cisco.com> Subject: Re: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 14:18:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Melinda Shore" > Please - when advocating for something funky, 1) provide a use > case, 2) let us know what other possible solutions were considered > and rejected, and 3) why you think that your suggestion is the > preferred one. OK, here goes. Case 1: A middlebox is doing ingress/egress filtering for SIP signalled sessions between two domains (A and B). No address translation is required. The middlebox is just a "bump on the wire" with 2 interfaces, no routing capability. Any allowed packet received on the interface to domain-A will be sent out the interface to domain-B and vice versa. A server in domain-A is performing the SIP proxy and the MIDCOM agent functions. The destination endpoint IP addresses and ports are extracted from the SDP in the SIP messages. Assume this is a multi-domain SIP network, thus the endpoints are not necessarily in either domain-A or domain-B, but could be one or more domain-hops away. If this is the case, neither the middlebox, nor the MIDCOM agent can determine the direction of the flows from the IP addresses without knowing the network topology beyond domains A and B. The MIDCOM agent does know that the RTP stream from the calling party to the called party will flow from domain-A to domain-B through the middlebox (the SIP proxy in domain-A has learned from a location service that the next-hop is a SIP proxy in domain-B) and that the RTP stream from the called party to the calling party will flow from domain-B to domain-A. +-----------+ +-----------+ +-----------+ +-----------+ |Originating| | Domain-A | | Domain-B | |Terminating| | Domain | | | | | | Domain | | [UAC]-->+---+->[SP/MA]->+[MB]+-->[SP]--->+---+->[UAS] | | | | | | | | | +-----------+ +-----------+ +-----------+ +-----------+ Without including some sort of interface/domain information in the pin-hole descriptor, the middlebox would have to allow the packets through regardless of which interface they come in on. If the middlebox has separate pin-hole tables for each interface (to minimize delay in packet forwarding), it would need to duplicate the pin-hole descriptor in both tables. Thus it opens 4 pin-holes instead of 2. The best way I can think of to express the 2 pin-holes I want is "from A: to B:UAS" for the calling to called flow, and "from B: to A:UAC" for the called to calling flow. Case 2: A middlebox performing NAT and firewall between a public domain (i.e. public IP addresses) and multiple private domains. This middlebox is a bump on 2 wires. It has 2 pairs of interfaces. One pair connects the public domain (call it A) with one private domain (call it B) and the other pair connects the public domain with a different private domain (call it C). Both domains B and C both use the same set of private addresses (e.g. 10.x.x.x). Without the domain information, the middlebox cannot distinguish between the private domains. +-----------+ +----+ +--------+ | +---+----+---+Domain-B| | | | | +--------+ | Domain-A | | MB | | | | | +--------+ | +---+----+---+Domain-C| +-----------+ +----+ +--------+ I can provide a detailed example from SIPland of how this would work, but I think that would be too much right now (for me and for all the readers). I think that the domain or the realm is what needs to be expressed in the protocol rather than specific interfaces. The middlebox can figure out the physical interface from the domain/realm identifier. This identifier could be a name or a number. The middlebox would own this identifier (no need for global uniqueness). MIDCOM Agents and Middleboxes should not be required to support this. But the protocol should so that middleboxes and MIDCOM agents that do support it can use it in the protocol. OK, let the flaming begin. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 15:21: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 PAA07903 for ; Thu, 28 Jun 2001 15:21:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26201; Thu, 28 Jun 2001 15:15:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26170 for ; Thu, 28 Jun 2001 15:15:10 -0400 (EDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02916 for ; Thu, 28 Jun 2001 15:14:26 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA26897 for ; Thu, 28 Jun 2001 14:16:07 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 28 Jun 2001 14:06:21 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 14:12:11 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BBFFB@crchy271.us.nortel.com> From: "Sanjoy Sen" To: "'Bob Penfield'" , Melinda Shore , midcom Subject: RE: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 14:11:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10006.34AD7030" X-Orig: 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_001_01C10006.34AD7030 Content-Type: text/plain; charset="iso-8859-1" I agree with Bob. How would the MB know about the direction the packets will be flowing from the flow tuple (src., dest. addr,ports, protocol> if the endpoints are multi-hop away from the MB? Another instance from VoIP that I can think of where the interface/direction parameter will be required is when the MA wants to open a pinhole in one direction to allow the calling user receive Early Media (announcements, ring-back tones etc) before the call set-up is completed. Sanjoy -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Thursday, June 28, 2001 1:18 PM To: Melinda Shore; midcom Subject: Re: [midcom] requirements-01 status ----- Original Message ----- From: "Melinda Shore" > Please - when advocating for something funky, 1) provide a use > case, 2) let us know what other possible solutions were considered > and rejected, and 3) why you think that your suggestion is the > preferred one. OK, here goes. Case 1: A middlebox is doing ingress/egress filtering for SIP signalled sessions between two domains (A and B). No address translation is required. The middlebox is just a "bump on the wire" with 2 interfaces, no routing capability. Any allowed packet received on the interface to domain-A will be sent out the interface to domain-B and vice versa. A server in domain-A is performing the SIP proxy and the MIDCOM agent functions. The destination endpoint IP addresses and ports are extracted from the SDP in the SIP messages. Assume this is a multi-domain SIP network, thus the endpoints are not necessarily in either domain-A or domain-B, but could be one or more domain-hops away. If this is the case, neither the middlebox, nor the MIDCOM agent can determine the direction of the flows from the IP addresses without knowing the network topology beyond domains A and B. The MIDCOM agent does know that the RTP stream from the calling party to the called party will flow from domain-A to domain-B through the middlebox (the SIP proxy in domain-A has learned from a location service that the next-hop is a SIP proxy in domain-B) and that the RTP stream from the called party to the calling party will flow from domain-B to domain-A. +-----------+ +-----------+ +-----------+ +-----------+ |Originating| | Domain-A | | Domain-B | |Terminating| | Domain | | | | | | Domain | | [UAC]-->+---+->[SP/MA]->+[MB]+-->[SP]--->+---+->[UAS] | | | | | | | | | +-----------+ +-----------+ +-----------+ +-----------+ Without including some sort of interface/domain information in the pin-hole descriptor, the middlebox would have to allow the packets through regardless of which interface they come in on. If the middlebox has separate pin-hole tables for each interface (to minimize delay in packet forwarding), it would need to duplicate the pin-hole descriptor in both tables. Thus it opens 4 pin-holes instead of 2. The best way I can think of to express the 2 pin-holes I want is "from A: to B:UAS" for the calling to called flow, and "from B: to A:UAC" for the called to calling flow. Case 2: A middlebox performing NAT and firewall between a public domain (i.e. public IP addresses) and multiple private domains. This middlebox is a bump on 2 wires. It has 2 pairs of interfaces. One pair connects the public domain (call it A) with one private domain (call it B) and the other pair connects the public domain with a different private domain (call it C). Both domains B and C both use the same set of private addresses (e.g. 10.x.x.x). Without the domain information, the middlebox cannot distinguish between the private domains. +-----------+ +----+ +--------+ | +---+----+---+Domain-B| | | | | +--------+ | Domain-A | | MB | | | | | +--------+ | +---+----+---+Domain-C| +-----------+ +----+ +--------+ I can provide a detailed example from SIPland of how this would work, but I think that would be too much right now (for me and for all the readers). I think that the domain or the realm is what needs to be expressed in the protocol rather than specific interfaces. The middlebox can figure out the physical interface from the domain/realm identifier. This identifier could be a name or a number. The middlebox would own this identifier (no need for global uniqueness). MIDCOM Agents and Middleboxes should not be required to support this. But the protocol should so that middleboxes and MIDCOM agents that do support it can use it in the protocol. OK, let the flaming begin. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C10006.34AD7030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] requirements-01 status

I agree with Bob. How would the MB know about the = direction the packets will be flowing from the flow tuple (src., dest. = addr,ports, protocol> if the endpoints are multi-hop away from the = MB?

Another instance from VoIP that I can think of where = the interface/direction parameter will be required is when the MA wants = to open a pinhole in one direction to allow the calling user receive = Early Media (announcements, ring-back tones etc) before the call set-up = is completed.

Sanjoy
 

-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
Sent: Thursday, June 28, 2001 1:18 PM
To: Melinda Shore; midcom
Subject: Re: [midcom] requirements-01 status



----- Original Message -----
From: "Melinda Shore" = <mshore@cisco.com>
<snip>
> Please - when advocating for something funky, = 1) provide a use
> case, 2) let us know what other possible = solutions were considered
> and rejected, and 3) why you think that your = suggestion is the
> preferred one.

OK, here goes.

Case 1:

A middlebox is doing ingress/egress filtering for SIP = signalled sessions
between two domains (A and B). No address = translation is required. The
middlebox is just a "bump on the wire" = with 2 interfaces, no routing
capability. Any allowed packet received on the = interface to domain-A will be
sent out the interface to domain-B and vice versa. A = server in domain-A is
performing the SIP proxy and the MIDCOM agent = functions. The destination
endpoint IP addresses and ports are extracted from = the SDP in the SIP
messages. Assume this is a multi-domain SIP network, = thus the endpoints are
not necessarily in either domain-A or domain-B, but = could be one or more
domain-hops away. If this is the case, neither the = middlebox, nor the MIDCOM
agent can determine the direction of the flows from = the IP addresses without
knowing the network topology beyond domains A and B. = The MIDCOM agent does
know that the RTP stream from the calling party to = the called party will
flow from domain-A to domain-B through the middlebox = (the SIP proxy in
domain-A has learned from a location service that = the next-hop is a SIP
proxy in domain-B) and that the RTP stream from the = called party to the
calling party will flow from domain-B to = domain-A.

+-----------+   = +-----------+    +-----------+   = +-----------+
|Originating|   | Domain-A  = |    |  Domain-B |   |Terminating|
|   Domain  |   = |           = |    = |           = |   |  Domain   |
|   = [UAC]-->+---+->[SP/MA]->+[MB]+-->[SP]--->+---+->[UAS]&= nbsp;   |
|           = |   = |           = |    = |           = |   = |           |
+-----------+   = +-----------+    +-----------+   = +-----------+

Without including some sort of interface/domain = information in the pin-hole
descriptor, the middlebox would have to allow the = packets through regardless
of which interface they come in on. If the middlebox = has separate pin-hole
tables for each interface (to minimize delay in = packet forwarding), it would
need to duplicate the pin-hole descriptor in both = tables. Thus it opens 4
pin-holes instead of 2.

The best way I can think of to express the 2 = pin-holes I want is "from
A:<any> to B:UAS" for the calling to = called flow, and "from B:<any> to
A:UAC" for the called to calling flow.

Case 2:

A middlebox performing NAT and firewall between a = public domain (i.e. public
IP addresses) and multiple private domains. This = middlebox is a bump on 2
wires. It has 2 pairs of interfaces. One pair = connects the public domain
(call it A) with one private domain (call it B) and = the other pair connects
the public domain with a different private domain = (call it C). Both domains
B and C both use the same set of private addresses = (e.g. 10.x.x.x). Without
the domain information, the middlebox cannot = distinguish between the private
domains.

+-----------+   +----+   = +--------+
|           = +---+----+---+Domain-B|
|           = |   |    |   +--------+
| Domain-A  |   | MB |
|           = |   |    |   +--------+
|           = +---+----+---+Domain-C|
+-----------+   +----+   = +--------+

I can provide a detailed example from SIPland of how = this would work, but I
think that would be too much right now (for me and = for all the readers).

I think that the domain or the realm is what needs to = be expressed in the
protocol rather than specific interfaces. The = middlebox can figure out the
physical interface from the domain/realm identifier. = This identifier could
be a name or a number. The middlebox would own this = identifier (no need for
global uniqueness).

MIDCOM Agents and Middleboxes should not be required = to support this. But
the protocol should so that middleboxes and MIDCOM = agents that do support it
can use it in the protocol.

OK, let the flaming begin.

cheers,

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C10006.34AD7030-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 15:31:44 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 PAA15117 for ; Thu, 28 Jun 2001 15:31:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26455; Thu, 28 Jun 2001 15:26:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26424 for ; Thu, 28 Jun 2001 15:26:38 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11071 for ; Thu, 28 Jun 2001 15:25:52 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A46C8CAC0146; Thu, 28 Jun 2001 15:24:28 -0400 Message-ID: <021001c10006$e1b4a280$2300000a@acmepacket.com> From: "Bob Penfield" To: References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEA@XCH-NW-01.nw.nos.boeing.com> <007d01c0ff4c$50393e20$2300000a@acmepacket.com> <012f01c0ff62$664bdea0$d45904d1@cisco.com> Subject: Re: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 15:16:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > > Firewalls and routers do this today (do ingress/egress filtering). > This is something that presumably will be static and integral to > the middlebox and its interfaces, handled through whatever management > tools are used for the middlebox, and not something that's going to > be changed on the fly by a midcom agent. The whole idea of MIDCOM was to allow applications to access these functions for dynamic flows so these devices would not need application intelligence. Shouldn't the same parameters used for statically configured pin-holes be used for dynamic pin-holes? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 15:35:15 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 PAA17590 for ; Thu, 28 Jun 2001 15:35:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26596; Thu, 28 Jun 2001 15:29:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26531 for ; Thu, 28 Jun 2001 15:29:51 -0400 (EDT) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13365 for ; Thu, 28 Jun 2001 15:29:07 -0400 (EDT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GFN00H4GNGURN@firewall.mcit.com> for midcom@ietf.org; Thu, 28 Jun 2001 19:29:18 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GFN00L01NFJN1@pmismtp03.wcomnet.com> for midcom@ietf.org; Thu, 28 Jun 2001 19:29:16 +0000 (GMT) Received: from rccc6131 ([166.35.224.209]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GFN00JEKNFIJN@pmismtp03.wcomnet.com> for midcom@ietf.org; Thu, 28 Jun 2001 19:28:31 +0000 (GMT) Date: Thu, 28 Jun 2001 14:28:25 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] requirements-01 status In-reply-to: <85AA7486A2C1D411BCA20000F8073E43016BBFFB@crchy271.us.nortel.com> To: midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <002701c10008$81096720$01010101@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Xxfta6UJfXdcHHQ3xa88QA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 multi-part message in MIME format. --Boundary_(ID_Xxfta6UJfXdcHHQ3xa88QA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: [midcom] requirements-01 statusI also agree with Bob, this should be closely considered in the requirements. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Sanjoy Sen Sent: Thursday, June 28, 2001 2:12 PM To: 'Bob Penfield'; Melinda Shore; midcom Subject: RE: [midcom] requirements-01 status I agree with Bob. How would the MB know about the direction the packets will be flowing from the flow tuple (src., dest. addr,ports, protocol> if the endpoints are multi-hop away from the MB? Another instance from VoIP that I can think of where the interface/direction parameter will be required is when the MA wants to open a pinhole in one direction to allow the calling user receive Early Media (announcements, ring-back tones etc) before the call set-up is completed. Sanjoy -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Thursday, June 28, 2001 1:18 PM To: Melinda Shore; midcom Subject: Re: [midcom] requirements-01 status ----- Original Message ----- From: "Melinda Shore" > Please - when advocating for something funky, 1) provide a use > case, 2) let us know what other possible solutions were considered > and rejected, and 3) why you think that your suggestion is the > preferred one. OK, here goes. Case 1: A middlebox is doing ingress/egress filtering for SIP signalled sessions between two domains (A and B). No address translation is required. The middlebox is just a "bump on the wire" with 2 interfaces, no routing capability. Any allowed packet received on the interface to domain-A will be sent out the interface to domain-B and vice versa. A server in domain-A is performing the SIP proxy and the MIDCOM agent functions. The destination endpoint IP addresses and ports are extracted from the SDP in the SIP messages. Assume this is a multi-domain SIP network, thus the endpoints are not necessarily in either domain-A or domain-B, but could be one or more domain-hops away. If this is the case, neither the middlebox, nor the MIDCOM agent can determine the direction of the flows from the IP addresses without knowing the network topology beyond domains A and B. The MIDCOM agent does know that the RTP stream from the calling party to the called party will flow from domain-A to domain-B through the middlebox (the SIP proxy in domain-A has learned from a location service that the next-hop is a SIP proxy in domain-B) and that the RTP stream from the called party to the calling party will flow from domain-B to domain-A. +-----------+ +-----------+ +-----------+ +-----------+ |Originating| | Domain-A | | Domain-B | |Terminating| | Domain | | | | | | Domain | | [UAC]-->+---+->[SP/MA]->+[MB]+-->[SP]--->+---+->[UAS] | | | | | | | | | +-----------+ +-----------+ +-----------+ +-----------+ Without including some sort of interface/domain information in the pin-hole descriptor, the middlebox would have to allow the packets through regardless of which interface they come in on. If the middlebox has separate pin-hole tables for each interface (to minimize delay in packet forwarding), it would need to duplicate the pin-hole descriptor in both tables. Thus it opens 4 pin-holes instead of 2. The best way I can think of to express the 2 pin-holes I want is "from A: to B:UAS" for the calling to called flow, and "from B: to A:UAC" for the called to calling flow. Case 2: A middlebox performing NAT and firewall between a public domain (i.e. public IP addresses) and multiple private domains. This middlebox is a bump on 2 wires. It has 2 pairs of interfaces. One pair connects the public domain (call it A) with one private domain (call it B) and the other pair connects the public domain with a different private domain (call it C). Both domains B and C both use the same set of private addresses (e.g. 10.x.x.x). Without the domain information, the middlebox cannot distinguish between the private domains. +-----------+ +----+ +--------+ | +---+----+---+Domain-B| | | | | +--------+ | Domain-A | | MB | | | | | +--------+ | +---+----+---+Domain-C| +-----------+ +----+ +--------+ I can provide a detailed example from SIPland of how this would work, but I think that would be too much right now (for me and for all the readers). I think that the domain or the realm is what needs to be expressed in the protocol rather than specific interfaces. The middlebox can figure out the physical interface from the domain/realm identifier. This identifier could be a name or a number. The middlebox would own this identifier (no need for global uniqueness). MIDCOM Agents and Middleboxes should not be required to support this. But the protocol should so that middleboxes and MIDCOM agents that do support it can use it in the protocol. OK, let the flaming begin. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom --Boundary_(ID_Xxfta6UJfXdcHHQ3xa88QA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [midcom] requirements-01 status
I also=20 agree with Bob, this should be closely considered in the requirements.=20
-----Original Message-----
From: = midcom-admin@ietf.org=20 [mailto:midcom-admin@ietf.org]On Behalf Of Sanjoy = Sen
Sent:=20 Thursday, June 28, 2001 2:12 PM
To: 'Bob Penfield'; Melinda = Shore;=20 midcom
Subject: RE: [midcom] requirements-01=20 status

I agree with Bob. How would the MB know about the = direction=20 the packets will be flowing from the flow tuple (src., dest. = addr,ports,=20 protocol> if the endpoints are multi-hop away from the = MB?

Another instance from VoIP that I can think of where = the=20 interface/direction parameter will be required is when the MA wants to = open a=20 pinhole in one direction to allow the calling user receive Early Media = (announcements, ring-back tones etc) before the call set-up is=20 completed.

Sanjoy
 

-----Original Message-----
From: Bob=20 Penfield [mailto:bpenfield@acmepacket.com<= /A>]=20
Sent: Thursday, June 28, 2001 1:18 PM =
To: Melinda Shore; midcom
Subject: = Re: [midcom]=20 requirements-01 status



----- Original Message -----
From:=20 "Melinda Shore" <mshore@cisco.com>
<snip>
> Please - when = advocating for=20 something funky, 1) provide a use
> case, = 2) let us=20 know what other possible solutions were considered
> and rejected, and 3) why you think that your suggestion = is=20 the
> preferred one.

OK, here goes.

Case 1:

A middlebox is doing ingress/egress filtering for = SIP=20 signalled sessions
between two domains (A = and B). No=20 address translation is required. The
middlebox is just=20 a "bump on the wire" with 2 interfaces, no routing
capability. Any allowed packet received on the interface to = domain-A=20 will be
sent out the interface to domain-B = and vice=20 versa. A server in domain-A is
performing = the SIP=20 proxy and the MIDCOM agent functions. The destination
endpoint IP addresses and ports are extracted from the SDP in = the=20 SIP
messages. Assume this is a multi-domain = SIP=20 network, thus the endpoints are
not = necessarily in=20 either domain-A or domain-B, but could be one or more
domain-hops away. If this is the case, neither the middlebox, = nor the=20 MIDCOM
agent can determine the direction of = the flows=20 from the IP addresses without
knowing the = network=20 topology beyond domains A and B. The MIDCOM agent does =
know that the RTP stream from the calling party to the called = party=20 will
flow from domain-A to domain-B through = the=20 middlebox (the SIP proxy in
domain-A has = learned from=20 a location service that the next-hop is a SIP
proxy in=20 domain-B) and that the RTP stream from the called party to the=20
calling party will flow from domain-B to = domain-A.=20

+-----------+   = +-----------+   =20 +-----------+   +-----------+
|Originating|   | Domain-A  = |    | =20 Domain-B |   |Terminating|
|  =20 Domain  |  =20 |          =20 |   =20 |           = |  =20 |  Domain   |
|  =20 = [UAC]-->+---+->[SP/MA]->+[MB]+-->[SP]--->+---+->[UAS]&n= bsp;  =20 |
|           = |   = |          =20 |   =20 |           = |  =20 |           | =
+-----------+   = +-----------+   =20 +-----------+   +-----------+

Without including some sort of interface/domain = information in=20 the pin-hole
descriptor, the middlebox would = have to=20 allow the packets through regardless
of = which=20 interface they come in on. If the middlebox has separate = pin-hole=20
tables for each interface (to minimize delay in = packet=20 forwarding), it would
need to duplicate the = pin-hole=20 descriptor in both tables. Thus it opens 4
pin-holes=20 instead of 2.

The best way I can think of to express the 2 = pin-holes I want=20 is "from
A:<any> to B:UAS" for the = calling to=20 called flow, and "from B:<any> to
A:UAC" for the=20 called to calling flow.

Case 2:

A middlebox performing NAT and firewall between a = public=20 domain (i.e. public
IP addresses) and = multiple private=20 domains. This middlebox is a bump on 2
wires. It has 2=20 pairs of interfaces. One pair connects the public domain =
(call it A) with one private domain (call it B) and the other = pair=20 connects
the public domain with a different = private=20 domain (call it C). Both domains
B and C = both use the=20 same set of private addresses (e.g. 10.x.x.x). Without =
the domain information, the middlebox cannot distinguish = between the=20 private
domains.

+-----------+   +----+   = +--------+=20
|          =20 +---+----+---+Domain-B|
|           = |   |    |   +--------+ =
| Domain-A  |   | MB |
|           = |   |    |   +--------+ =
|           = +---+----+---+Domain-C|
+-----------+  =20 +----+   +--------+

I can provide a detailed example from SIPland of how = this=20 would work, but I
think that would be too = much right=20 now (for me and for all the readers).

I think that the domain or the realm is what needs = to be=20 expressed in the
protocol rather than = specific=20 interfaces. The middlebox can figure out the
physical=20 interface from the domain/realm identifier. This identifier = could=20
be a name or a number. The middlebox would own this = identifier (no need for
global = uniqueness).=20

MIDCOM Agents and Middleboxes should not be required = to=20 support this. But
the protocol should so = that=20 middleboxes and MIDCOM agents that do support it
can=20 use it in the protocol.

OK, let the flaming begin.

cheers,

(-:bob

Robert F. Penfield
Chief = Software=20 Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA = 01801=20
bpenfield@acmepacket.com




_______________________________________________=20
midcom mailing list
midcom@ietf.org
http://www.ietf.org/= mailman/listinfo/midcom=20

--Boundary_(ID_Xxfta6UJfXdcHHQ3xa88QA)-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 15:43: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 PAA23428 for ; Thu, 28 Jun 2001 15:43:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27079; Thu, 28 Jun 2001 15:39:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27051 for ; Thu, 28 Jun 2001 15:39:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19713 for ; Thu, 28 Jun 2001 15:38:19 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5SJcbx27326; Thu, 28 Jun 2001 12:38:37 -0700 (PDT) Received: from spandex (sjc-vpn-tmp127.cisco.com [10.21.64.127]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALK01566; Thu, 28 Jun 2001 12:38:27 -0700 (PDT) Message-ID: <015701c1000a$0b5b72a0$d45904d1@cisco.com> From: "Melinda Shore" To: "Sanjoy Sen" , "'Bob Penfield'" , "midcom" References: <85AA7486A2C1D411BCA20000F8073E43016BBFFB@crchy271.us.nortel.com> Subject: Re: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 15:39:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > From: Sanjoy Sen > To: 'Bob Penfield' ; Melinda Shore ; midcom > Sent: Thursday, June 28, 2001 3:11 PM > Subject: RE: [midcom] requirements-01 status > I agree with Bob. How would the MB know about the direction the packets will > be flowing from the flow tuple (src., dest. addr,ports, protocol> if the > endpoints are multi-hop away from the MB? A middlebox with more that's got to forward to more than one interface is often referred to as a "router," and there are already mechanisms to do interface selection. I am *extremely* wary of 1) trying to replicate network-layer functions in the application layer, and 2) trying to export network topology information to applications. I believe that the correct approach here is to rely on routers to do their job, including route determination/selection. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 16:59: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 QAA16552 for ; Thu, 28 Jun 2001 16:59:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29141; Thu, 28 Jun 2001 16:43:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29112 for ; Thu, 28 Jun 2001 16:43:19 -0400 (EDT) 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 QAA04627 for ; Thu, 28 Jun 2001 16:42:35 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5SKeeH04100; Thu, 28 Jun 2001 13:40:56 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-8.cisco.com [10.21.96.8]) by airborne.cisco.com (Mirapoint) with ESMTP id AEI05768; Thu, 28 Jun 2001 13:42:07 -0700 (PDT) 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: <15163.38557.316000.255922@gargle.gargle.HOWL> Date: Thu, 28 Jun 2001 16:42:05 -0400 To: "Bob Penfield" Cc: "Melinda Shore" , Subject: Re: [midcom] requirements-01 status In-Reply-To: <018201c0fffe$bb9a46c0$2300000a@acmepacket.com> References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEA@XCH-NW-01.nw.nos.boeing.com> <007d01c0ff4c$50393e20$2300000a@acmepacket.com> <012f01c0ff62$664bdea0$d45904d1@cisco.com> <018201c0fffe$bb9a46c0$2300000a@acmepacket.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 28 Jun 2001 at 14:18 -0400, Bob Penfield apparently wrote: > From: "Melinda Shore" > > > Please - when advocating for something funky, 1) provide a use > > case, 2) let us know what other possible solutions were considered > > and rejected, and 3) why you think that your suggestion is the > > preferred one. > > OK, here goes. It looks to me like those saying interface specification is not necessary are assuming other functions in the middlebox which might not be there. These test cases are pretty interesting. In the first case you have a pure firewall. It does no routing, it does not even need to be configured to know what prefixes are reachable on what interface. I could pick this up at the supermarket, plug it in, and it would work. Its only rule is "if it comes in here, check what's allowed, if it's allowed send it out there". Since it knows nothing except its allowed pinholes, interface information seems necessary. The second case is more elaborate but again, the key is that the box can do its job with a lot less software (money), if it has information about allowed interfaces in the pinholes. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 17:08:26 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 RAA22734 for ; Thu, 28 Jun 2001 17:08:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29920; Thu, 28 Jun 2001 17:03:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29885 for ; Thu, 28 Jun 2001 17:03:43 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19024 for ; Thu, 28 Jun 2001 17:03:00 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5SL2x915212 for ; Thu, 28 Jun 2001 17:02:59 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5SL2xF15204 for ; Thu, 28 Jun 2001 17:02:59 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10015.D3D37B50" Subject: RE: [midcom] requirements-01 status X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Thu, 28 Jun 2001 15:03:49 -0600 Message-ID: Thread-Topic: [midcom] requirements-01 status Thread-Index: AcEAExOgNi23Or/jSVSy//JynzOehwAAODHw From: "Zmolek, Andrew (Andrew)" To: "Scott Brim" , "Bob Penfield" Cc: "Melinda Shore" , 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 multi-part message in MIME format. ------_=_NextPart_001_01C10015.D3D37B50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If interface specification did become a legitimate part of midcom, how would an interface be specified? By some number? By some string? Would this be something of a shared understanding between the middlebox and the agent? Wouldn't this make agent (and middlebox) configuration more complex? Even though I see some value in interface specification, I still think it creates at least as many problems as it solves. There are better ways of providing topology information to a middlebox, and why make the application agent have to worry about this? That's a really hard sell. Does a good protocol exist for providing topology information to middleboxes and other perimeter devices? If midcom is not the place for this (and I don't think it is), then what would be used for this? Snooping routing protocols? I don't see a clean answer here, either... --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Scott Brim [mailto:sbrim@cisco.com] Sent: Thursday, June 28, 2001 2:42 PM To: Bob Penfield Cc: Melinda Shore; midcom@ietf.org Subject: Re: [midcom] requirements-01 status On 28 Jun 2001 at 14:18 -0400, Bob Penfield apparently wrote: > From: "Melinda Shore" > > > Please - when advocating for something funky, 1) provide a use > > case, 2) let us know what other possible solutions were considered > > and rejected, and 3) why you think that your suggestion is the > > preferred one. >=20 > OK, here goes. It looks to me like those saying interface specification is not necessary are assuming other functions in the middlebox which might not be there. These test cases are pretty interesting. In the first case you have a pure firewall. It does no routing, it does not even need to be configured to know what prefixes are reachable on what interface. I could pick this up at the supermarket, plug it in, and it would work. Its only rule is "if it comes in here, check what's allowed, if it's allowed send it out there". Since it knows nothing except its allowed pinholes, interface information seems necessary. The second case is more elaborate but again, the key is that the box can do its job with a lot less software (money), if it has information about allowed interfaces in the pinholes. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C10015.D3D37B50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] requirements-01 status

If interface specification did become a legitimate = part of midcom, how would an interface be specified? By some number? By = some string? Would this be something of a shared understanding between = the middlebox and the agent? Wouldn't this make agent (and middlebox) = configuration more complex?

Even though I see some value in interface = specification, I still think it creates at least as many problems as it = solves. There are better ways of providing topology information to a = middlebox, and why make the application agent have to worry about this? = That's a really hard sell.

Does a good protocol exist for providing topology = information to middleboxes and other perimeter devices? If midcom is not = the place for this (and I don't think it is), then what would be used = for this? Snooping routing protocols? I don't see a clean answer here, = either...

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Scott Brim [mailto:sbrim@cisco.com]
Sent: Thursday, June 28, 2001 2:42 PM
To: Bob Penfield
Cc: Melinda Shore; midcom@ietf.org
Subject: Re: [midcom] requirements-01 status


On 28 Jun 2001 at 14:18 -0400, Bob Penfield apparently = wrote:
> From: "Melinda Shore" = <mshore@cisco.com>
> <snip>
> > Please - when advocating for something = funky, 1) provide a use
> > case, 2) let us know what other possible = solutions were considered
> > and rejected, and 3) why you think that = your suggestion is the
> > preferred one.
>
> OK, here goes.

It looks to me like those saying interface = specification is not
necessary are assuming other functions in the = middlebox which might not
be there.

These test cases are pretty interesting.  In the = first case you have a
pure firewall.  It does no routing, it does not = even need to be
configured to know what prefixes are reachable on = what interface.  I
could pick this up at the supermarket, plug it in, = and it would work.
Its only rule is "if it comes in here, check = what's allowed, if it's
allowed send it out there".  Since it knows = nothing except its allowed
pinholes, interface information seems = necessary.  The second case is
more elaborate but again, the key is that the box can = do its job with a
lot less software (money), if it has information = about allowed
interfaces in the pinholes.

...Scott


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/= mailman/listinfo/midcom

------_=_NextPart_001_01C10015.D3D37B50-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 17:34:44 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 RAA04400 for ; Thu, 28 Jun 2001 17:34:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00535; Thu, 28 Jun 2001 17:29:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00504 for ; Thu, 28 Jun 2001 17:29:11 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04280 for ; Thu, 28 Jun 2001 17:28:27 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A1265150288; Thu, 28 Jun 2001 17:27:02 -0400 Message-ID: <003b01c10017$d149b140$2300000a@acmepacket.com> From: "Bob Penfield" To: "Melinda Shore" , "midcom" References: <85AA7486A2C1D411BCA20000F8073E43016BBFFB@crchy271.us.nortel.com> <015701c1000a$0b5b72a0$d45904d1@cisco.com> Subject: Re: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 17:18:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Melinda Shore" To: "Sanjoy Sen" ; "'Bob Penfield'" ; "midcom" Sent: Thursday, June 28, 2001 3:39 PM Subject: Re: [midcom] requirements-01 status > > From: Sanjoy Sen > > To: 'Bob Penfield' ; Melinda Shore ; midcom > > Sent: Thursday, June 28, 2001 3:11 PM > > Subject: RE: [midcom] requirements-01 status > > > > I agree with Bob. How would the MB know about the direction the packets will > > be flowing from the flow tuple (src., dest. addr,ports, protocol> if the > > endpoints are multi-hop away from the MB? > > A middlebox with more that's got to forward to more than one > interface is often referred to as a "router," and there are > already mechanisms to do interface selection. There is no routing in either case. In case 2 there are two separate pipes: Pipe 1 from A to B and Pipe 2 from A to C. Packets do not cross from pipe 1 to pipe 2. If it goes in to pipe 1 from domain-A, it comes out in domain-B. If it goes into pipe 2, it comes out in domain-C. It is just more economical to have one middlebox handle multiple pipes. The function would be the same if each pipe had a separate middlebox on it. > I am *extremely* > wary of 1) trying to replicate network-layer functions in the > application layer, and What network-layer function does case 1 replicate? It is just a simplified firewall. > 2) trying to export network topology > information to applications. I believe that the correct > approach here is to rely on routers to do their job, including > route determination/selection. It is a very simplistic form of the topology. Its a name that is useful to the application like "inside" and "outside". > > Melinda > > > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 17:48:21 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 RAA08660 for ; Thu, 28 Jun 2001 17:48:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01075; Thu, 28 Jun 2001 17:42:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01048 for ; Thu, 28 Jun 2001 17:42:04 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04626 for ; Thu, 28 Jun 2001 17:41:19 -0400 (EDT) Received: from 157.54.9.100 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Jun 2001 14:24:00 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Jun 2001 14:23:06 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 28 Jun 2001 14:23:06 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Jun 2001 14:22:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 14:22:24 -0700 Message-ID: Thread-Topic: [midcom] requirements-01 status Thread-Index: AcEACoalJ+eBgrrjRF2UpTXslsWfJAADRtCQ From: "Christian Huitema" To: "Melinda Shore" , "Sanjoy Sen" , "Bob Penfield" , "midcom" X-OriginalArrivalTime: 28 Jun 2001 21:22:25.0764 (UTC) FILETIME=[6D651240:01C10018] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA01049 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: 8bit I agree with Melinda here. The internal IP packets that are authorized to sneak through a "pin-hole" will carry an internal source address and an "external" destination address; the internal routing mechanisms will direct these packet towards the firewall. If the firewall is to forward these packets, it will have to do that based solely on the value of the destination address -- there is no "scope of address" field in the IPv4 packet. To operate properly, the firewall must have an internal routing table that maps an IP address to an exit interface. Thus, the "interface" to which an address is bound on a given midcom box has to be deductible from the IP address itself. Ergo, direction and scope fields are redundant. -- Christian Huitema > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, June 28, 2001 12:39 PM > To: Sanjoy Sen; 'Bob Penfield'; midcom > Subject: Re: [midcom] requirements-01 status > > > From: Sanjoy Sen > > To: 'Bob Penfield' ; Melinda Shore > ; midcom > > Sent: Thursday, June 28, 2001 3:11 PM > > Subject: RE: [midcom] requirements-01 status > > > > I agree with Bob. How would the MB know about the direction the packets > will > > be flowing from the flow tuple (src., dest. addr,ports, protocol> if the > > endpoints are multi-hop away from the MB? > > A middlebox with more that's got to forward to more than one > interface is often referred to as a "router," and there are > already mechanisms to do interface selection. I am *extremely* > wary of 1) trying to replicate network-layer functions in the > application layer, and 2) trying to export network topology > information to applications. I believe that the correct > approach here is to rely on routers to do their job, including > route determination/selection. > > 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 Thu Jun 28 18:10: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 SAA22141 for ; Thu, 28 Jun 2001 18:10:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01789; Thu, 28 Jun 2001 18:00:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01745 for ; Thu, 28 Jun 2001 18:00:31 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14302 for ; Thu, 28 Jun 2001 17:59:48 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A87A8CFB0146; Thu, 28 Jun 2001 17:58:18 -0400 Message-ID: <007401c1001c$28ae9960$2300000a@acmepacket.com> From: "Bob Penfield" To: "Zmolek, Andrew \(Andrew\)" , "Scott Brim" Cc: "Melinda Shore" , References: Subject: Re: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 17:49:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 Andrew Zmolek wrote: > If interface specification did become a legitimate part of midcom, how > would an interface be specified? By some number? By some string? Would > this be something of a shared understanding between the middlebox and > the agent? Wouldn't this make agent (and middlebox) configuration more > complex? It could be as simple as using the domain names of the networks. I don't think the configuration is all that complex. In the middlebox you just need to label each interface with the domain name it is connected to. In the agent, the label would be associated with the signalling proxies. Say I have a network "mydomain.com" and you have a network "yourdomain.com" and we want to exchange SIP traffic and have a middlebox at the peering point to do the filtering. There will likely be a SIP proxy in my network and a SIP proxy in your network that will handle the SIP signalling for sessions that go across the peering point. These proxies know about each other and probably have a secure connection (e.g. TLS) between them. Whichever proxy performs the role of MIDCOM agent will know that the 2 sides of the middlebox are "mydomain.com" and "yourdomain.com". The middlebox has the interfaces labeled with "mydomain.com" and "yourdomain.com" so it can make the proper pin-holes. > > Even though I see some value in interface specification, I still think > it creates at least as many problems as it solves. There are better ways > of providing topology information to a middlebox, and why make the > application agent have to worry about this? That's a really hard sell. I think this kind of information would be statically configured in the middlebox and the agent. There is no need to exchange this information in any protocol. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 18:10: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 SAA22681 for ; Thu, 28 Jun 2001 18:10:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01873; Thu, 28 Jun 2001 18:01:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01839 for ; Thu, 28 Jun 2001 18:01:26 -0400 (EDT) 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 SAA15082 for ; Thu, 28 Jun 2001 18:00:41 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5SM0qh15155; Thu, 28 Jun 2001 15:00:52 -0700 (PDT) Received: from spandex (sjc-vpn-tmp127.cisco.com [10.21.64.127]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALL01203; Thu, 28 Jun 2001 15:00:47 -0700 (PDT) Message-ID: <025701c1001d$ed94fb60$d45904d1@cisco.com> From: "Melinda Shore" To: "Scott Brim" , "Bob Penfield" Cc: References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEA@XCH-NW-01.nw.nos.boeing.com><007d01c0ff4c$50393e20$2300000a@acmepacket.com><012f01c0ff62$664bdea0$d45904d1@cisco.com><018201c0fffe$bb9a46c0$2300000a@acmepacket.com> <15163.38557.316000.255922@gargle.gargle.HOWL> Subject: Re: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 18:01:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > From: Scott Brim > To: Bob Penfield > Cc: Melinda Shore ; > Sent: Thursday, June 28, 2001 4:42 PM > Subject: Re: [midcom] requirements-01 status > It looks to me like those saying interface specification is not > necessary are assuming other functions in the middlebox which might not > be there. I think we're all assuming that there's going to be some interaction with the routing function in the middlebox, whether it's asking it to route pinhole requests or to make the routing table available to the middlebox function that's talking to the agent. I'll try to be clearer about my concerns: 1) Exporting routing tables to midcom agents scales poorly. Picture a default-free middlebox. 2) What happens when there are changes to the routing table on the middlebox? Do you really want to have agents become participants in the routing system? 3) Routing pinhole requests is necessarily tied to routing packets. I think we should leave the separation of routing and forwarding to other groups. 4) Exporting routing tables to midcom agents exposes network topology, which is a security concern and which is deemed unacceptable by some network administrators 5) Routing functions can be expensive to implement - longest partial match, etc. Why should they be implemented in two places in order to get one packet out one interface? I think we need to be really, really careful here. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 18:21: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 SAA29992 for ; Thu, 28 Jun 2001 18:21:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02234; Thu, 28 Jun 2001 18:16:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02205 for ; Thu, 28 Jun 2001 18:16:19 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26102 for ; Thu, 28 Jun 2001 18:15:36 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA18772 for ; Thu, 28 Jun 2001 23:15:46 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA69440 for ; Thu, 28 Jun 2001 23:15:45 +0100 Message-ID: <3B3BA8A9.7ABCC46D@hursley.ibm.com> Date: Thu, 28 Jun 2001 16:59:05 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: midcom@ietf.org References: <200106141108.HAA24729@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.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 I'm a bit puzzled by the isolated reference to Diffserv sitting in the middle of Figure 1, and the very brief mention at the beginning of the Introduction. While it is true that one possible location for diffserv classification and shaping is in a border router which is also a NAT and/or firewall, it can be done in any router or in hosts. And it has its own policy distribution mechanisms (COPS, SNMPCONF). So I would recommend removing the two brief references. I don't see why diffserv would be a midcom issue. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 18:54: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 SAA23969 for ; Thu, 28 Jun 2001 18:54:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02884; Thu, 28 Jun 2001 18:31:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02859 for ; Thu, 28 Jun 2001 18:31:12 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06871 for ; Thu, 28 Jun 2001 18:30:29 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA30708 for ; Thu, 28 Jun 2001 23:30:40 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA41396 for ; Thu, 28 Jun 2001 23:30:39 +0100 Message-ID: <3B3BAC1E.DC9E31D4@hursley.ibm.com> Date: Thu, 28 Jun 2001 17:13:50 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: midcom@ietf.org References: <3B33C33B.985C24B7@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: draft-ietf-midcom-requirements-01.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 > 9. Resource control requirements ... > The Middlebox may provide QoS transport facilities for packet flows, > for example, by setting DS-bytes or MPLS mappings. I think this is wrong in general, and it is certainly wrong in the reference to diffserv. Firstly the correct phrase is "DS code points" and they are 6 bits long, not a byte. The reference is RFC 2474. However, diffserv shouldn't be mentioned at all (see my previous comment on the scenarios). Diffserv management is complicated enough already, and we shouldn't add midcom to the mix. I am very doubtful in general whether midcom should go near QOS management, so personally I would remove the MPLS reference too. Do you seriously want hosts hidden behind a firewall to know about MPLS mappings used by some ISP??? Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 19:04:26 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 TAA01412 for ; Thu, 28 Jun 2001 19:04:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03398; Thu, 28 Jun 2001 18:51:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03323 for ; Thu, 28 Jun 2001 18:51:20 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21397 for ; Thu, 28 Jun 2001 18:50:40 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5SMojw20479 for ; Thu, 28 Jun 2001 23:50:45 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Thu, 28 Jun 2001 23:50:35 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 23:50:33 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C3044503D@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'melinda'" , "Midcom IETF (E-mail)" Subject: FW: [midcom] Out-of-path agents Date: Thu, 28 Jun 2001 23:50:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10024.BD199E80" 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_001_01C10024.BD199E80 Content-Type: text/plain; charset="iso-8859-1" Melinda, I prefer that we don't close the door to any deployment scenarios. How about putting a small paragraph on : Location of the MIDCOM Agent: The MIDCOM agent could be co-hosted with an application client or server already part of the application, or could be co-hosted with several client/server applications that are completely invisible to the application end parties. -The first MIDCOM Agent type, the In Path Agent, requires to add the MIDCOM agent on to existing hosts thus requiring upgrade of the host (neither S/W or H/W), additional processing power (that might require the processor upgrade) and implicitly an additional cost required per application. -The second case, describing the Out Of Path agent, leaves the end parties completely unaware of any MIDCOM interaction, there is no upgrade requirements (software or H/W) in some cases this solution could be applied. However there are some drawbacks to the invisibility of the MIDCOM Agent, when encrypted application signaling is sent the agent can not determine the used encryption key since it did not participate to any key exchange. In addition the OOP agent requires packet diversion capabilities on the Middle Box, these might be achieved by the following procedure: -Create a relation between an application (identified by a source or destination IANA assigned port) and a MIDCOM agent -Establish a tunnel between the Middle Box and the required MIDCOM agent -Hijack the application traffic type (identified by IANA port numbers or protocol port depending on application type) and route it to the tunnel interface -Load Sharing policies between MIDCOM agent are required (for obvious scalability reasons several MIDCOM Agents might be required) The OOP MIDCOM agent will require to have load monitoring notification messages (which is optional) Middle Box to choose between the MIDCOM agents. -------------- We all agreed that the framework is around providing a mean for application aware entities to request from intermediate network elements certain parameters to allow the application traversal. Within the framework we should cover the different types of MIDCOM agents, even if they do not require any additional requirements within the MIDCOM protocol it is still necessary to high-light the 2 different types. Thanks Cedric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, June 27, 2001 9:28 PM To: midcom Subject: [midcom] Out-of-path agents Thumbs down - let's make text related to out-of-path agents and packet diversion disappear from the deliverables. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C10024.BD199E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [midcom] Out-of-path agents

Melinda,

I prefer that we don't close the door to any = deployment scenarios.

How about putting a small paragraph on :

Location of the MIDCOM Agent:
The MIDCOM agent could be co-hosted with an = application client or server already part of the application, or could = be co-hosted with several client/server applications that are = completely invisible to the application end parties.

-The first MIDCOM Agent type, the In Path Agent, = requires to add the MIDCOM agent on to existing hosts thus requiring = upgrade of the host (neither S/W or H/W), additional processing power = (that might require the processor upgrade) and implicitly an additional = cost required per application.

-The second case, describing the Out Of Path agent, = leaves the end parties completely unaware of any MIDCOM interaction, = there is no upgrade requirements (software or H/W) in some cases this = solution could be applied. However there are some drawbacks to the = invisibility of the MIDCOM Agent, when encrypted application signaling = is sent the agent can not determine the used encryption key since it = did not participate to any key exchange.

In addition the OOP agent requires packet diversion = capabilities on the Middle Box, these might be achieved by the = following procedure:

-Create a relation between an application (identified = by a source or destination IANA assigned port) and a MIDCOM = agent
-Establish a tunnel between the Middle Box and the = required MIDCOM agent
-Hijack the application traffic type (identified by = IANA port numbers or protocol port depending on application type) and = route it to the tunnel interface

-Load Sharing policies between MIDCOM agent are = required (for obvious scalability reasons several MIDCOM Agents might = be required)

The OOP MIDCOM agent will require to have load = monitoring notification messages (which is optional) Middle Box to = choose between the MIDCOM agents.

--------------
We all agreed that the framework is around providing = a mean for application aware entities to request from intermediate = network elements certain parameters to allow the application = traversal.

Within the framework we should cover the different = types of MIDCOM agents, even if they do not require any additional = requirements within the MIDCOM protocol it is still necessary to = high-light the 2 different types.

Thanks
Cedric


-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Wednesday, June 27, 2001 9:28 PM
To: midcom
Subject: [midcom] Out-of-path agents


Thumbs down - let's make text related to out-of-path = agents and
packet diversion disappear from the = deliverables.

Thanks,

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C10024.BD199E80-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 19:34: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 TAA19128 for ; Thu, 28 Jun 2001 19:34:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04492; Thu, 28 Jun 2001 19:26:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04460 for ; Thu, 28 Jun 2001 19:26:08 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13663 for ; Thu, 28 Jun 2001 19:25:27 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA03819 for ; Thu, 28 Jun 2001 16:25:14 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA03567 for ; Thu, 28 Jun 2001 16:26:05 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 28 Jun 2001 16:26:00 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Jun 2001 16:25:59 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DFD@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Bob Penfield'" , "Zmolek, Andrew (Andrew)" , Scott Brim Cc: Melinda Shore , midcom@ietf.org Subject: RE: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 16:25:59 -0700 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 >From: Bob Penfield [mailto:bpenfield@acmepacket.com] >Andrew Zmolek wrote: >> If interface specification did become a legitimate part of midcom, how >> would an interface be specified? By some number? By some string? Would >> this be something of a shared understanding between the middlebox and >> the agent? Wouldn't this make agent (and middlebox) configuration more >> complex? > >It could be as simple as using the domain names of the networks. I don't >think the configuration is all that complex. In the middlebox you just need >to label each interface with the domain name it is connected to. In the >agent, the label would be associated with the signalling proxies. > >Say I have a network "mydomain.com" and you have a network "yourdomain.com" >and we want to exchange SIP traffic and have a middlebox at the peering I'm afraid that it won't be as simple as your example because the scenario you have in mind is for communications between companies. However, Midcom also has to work for communications WITHIN huge companies. Domain names don't cut it in the latter case because I can not assure you that there isn't some middlebox somewhere within any given arbitrary subdomain (e.g., xxx.yyy.mydomain.com) that could be enumerated. --Eric _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jun 28 20:45:44 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 UAA09387 for ; Thu, 28 Jun 2001 20:45:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06661; Thu, 28 Jun 2001 20:37:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06631 for ; Thu, 28 Jun 2001 20:37:26 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03022 for ; Thu, 28 Jun 2001 20:36:44 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21]) by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f5T037i29172; Thu, 28 Jun 2001 17:03:07 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 17:33:40 -0700 Message-ID: From: John LaCour To: "'Christian Huitema'" , Melinda Shore , midcom Subject: RE: [midcom] requirements-01 status Date: Thu, 28 Jun 2001 17:39:29 -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 The only way that we can allow the middlebox to figure out which interfaces and direction to apply the requests to is if the MIDCOM interface on the middlebox is administratively tied to one pair of interfaces and one direction. Otherwise, there are numerous problems with letting the middlebox figure out on its own which interfaces to which the request should be applied. Consider the following case: 1) Agent requests pin-hole 2) Middlebox consults routing table and other configuration parameters and creates pin-hole. 3) Routing table changes 4) Packet arrives but there is no pin-hole on the current route. So let us argue that this is an implementation detail for middlebox vendors. They will need to create pending pin-holes across all interfaces until you get a packet that matches, set that pin-hole, and close all of the other pending pin-holes. It gets even uglier when you consider a request to create a deny policy. I think the reason why many of us want interfaces and direction specified in the protocol is so that dynamic policies can be installed explicitly and based on the same information as static policies. Also, so we don't have to run multiple MIDCOM agents on a middlebox for all of the possible combinations of interfaces which may be transited. I'd like to suggest that we include in the protocol a field such as 'middlebox-id' that could be used to reference an abstraction of a logical middlebox. A logical middlebox would be comprised of 'inside' and 'outside' interfaces. The middlebox could be administratively configured so that a given middlebox-id is tied to two interfaces on a physical middlebox. Simple configurations or middleboxes which want to figure out how to install policies on their own could omit the 'middlebox-id' field. Protocol requests would include something like 'inside-address', 'outside-address', 'middlebox-id', and 'direction'. Direction would be 'in', 'out', or 'bi-directional'. This would decrease the complexity required to implement MIDCOM in middleboxes, allow one instance of the protocol to manage several logical middleboxes, and avoid having to come up with some standard representation of interfaces in the protocol. -John > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > I agree with Melinda here. The internal IP packets that are authorized > to sneak through a "pin-hole" will carry an internal source > address and > an "external" destination address; the internal routing > mechanisms will > direct these packet towards the firewall. If the firewall is > to forward > these packets, it will have to do that based solely on the > value of the > destination address -- there is no "scope of address" field > in the IPv4 > packet. To operate properly, the firewall must have an > internal routing > table that maps an IP address to an exit interface. Thus, the > "interface" to which an address is bound on a given midcom > box has to be > deductible from the IP address itself. Ergo, direction and > scope fields > are redundant. > > -- Christian Huitema > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Thursday, June 28, 2001 12:39 PM > > To: Sanjoy Sen; 'Bob Penfield'; midcom > > Subject: Re: [midcom] requirements-01 status > > > > > From: Sanjoy Sen > > > To: 'Bob Penfield' ; Melinda Shore > > ; midcom > > > Sent: Thursday, June 28, 2001 3:11 PM > > > Subject: RE: [midcom] requirements-01 status > > > > > > > I agree with Bob. How would the MB know about the direction the > packets > > will > > > be flowing from the flow tuple (src., dest. addr,ports, > protocol> if > the > > > endpoints are multi-hop away from the MB? > > > > A middlebox with more that's got to forward to more than one > > interface is often referred to as a "router," and there are > > already mechanisms to do interface selection. I am *extremely* > > wary of 1) trying to replicate network-layer functions in the > > application layer, and 2) trying to export network topology > > information to applications. I believe that the correct > > approach here is to rely on routers to do their job, including > > route determination/selection. > > > > 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 > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 01:17: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 BAA19672 for ; Fri, 29 Jun 2001 01:17:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18591; Fri, 29 Jun 2001 01:08:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18520 for ; Fri, 29 Jun 2001 01:08:35 -0400 (EDT) Received: from linux.aravox.com (linux.aravox.com [209.46.41.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12917 for ; Fri, 29 Jun 2001 01:07:53 -0400 (EDT) Received: (from jladwig@localhost) by linux.aravox.com (8.9.3/8.9.3) id AAA28051; Fri, 29 Jun 2001 00:06:44 -0500 From: John Ladwig Message-Id: <200106290506.AAA28051@linux.aravox.com> Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt To: brian@hursley.ibm.com (Brian E Carpenter) Date: Fri, 29 Jun 2001 00:06:44 -0500 (CDT) Cc: midcom@ietf.org In-Reply-To: <3B3BAC1E.DC9E31D4@hursley.ibm.com> from "Brian E Carpenter" at Jun 28, 2001 05:13:50 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 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 > > > 9. Resource control requirements > ... > > The Middlebox may provide QoS transport facilities for packet flows, > > for example, by setting DS-bytes or MPLS mappings. > > I think this is wrong in general, and it is certainly wrong in the > reference to diffserv. > > Firstly the correct phrase is "DS code points" and they are 6 bits long, > not a byte. The reference is RFC 2474. > > However, diffserv shouldn't be mentioned at all (see my previous comment > on the scenarios). Diffserv management is complicated enough already, > and we shouldn't add midcom to the mix. But isn't a middlebox useful as an enforcement point for whatever management you wish to implement? > I am very doubtful in general whether midcom should go near QOS management, so > personally I would remove the MPLS reference too. Do you seriously want hosts > hidden behind a firewall to know about MPLS mappings used by some ISP??? Putting my ISP hat on for a moment, I *very much* want to have the middlebox able to implement MPLS labeling on traffic so that packets may be steered along provisioned/quality-engineered pathways through my infrastructure, to the midcom agent's specifications and policies. Why don't/wouldn't you? Apologies if this has been said, or obsoleted; I'm playing catch-up on the discussion points. -jml _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 07:55:15 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 HAA02471 for ; Fri, 29 Jun 2001 07:55:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06040; Fri, 29 Jun 2001 07:51:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06011 for ; Fri, 29 Jun 2001 07:51:15 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29120 for ; Fri, 29 Jun 2001 07:50:32 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AB318DC10146; Fri, 29 Jun 2001 07:49:05 -0400 Message-ID: <004501c1008f$d194d580$2300000a@acmepacket.com> From: "Bob Penfield" To: "Brian E Carpenter" , References: <200106141108.HAA24729@ietf.org> <3B3BA8A9.7ABCC46D@hursley.ibm.com> Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 07:37:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Brian E Carpenter" To: Sent: Thursday, June 28, 2001 5:59 PM Subject: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > I'm a bit puzzled by the isolated reference to Diffserv > sitting in the middle of Figure 1, and the very brief mention > at the beginning of the Introduction. While it is true that > one possible location for diffserv classification and shaping > is in a border router which is also a NAT and/or firewall, > it can be done in any router or in hosts. And it has its > own policy distribution mechanisms (COPS, SNMPCONF). > So I would recommend removing the two brief references. > I don't see why diffserv would be a midcom issue. Being able to set the DS code point is definitely something that applications are going to want to do. For example, a SIP proxy acting as a midcom agent talking to a middlebox at the border between networks will need to instruct the middlebox to set the DSCP in the RTP packets that will flow thru the middlebox. The RTP packets will not flow thru the SIP proxy/midcom agent. The middlebox is the only place the application will be able to affect QoS for the data flows. > > Brian > > _______________________________________________ > 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 Jun 29 07:56: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 HAA03652 for ; Fri, 29 Jun 2001 07:56:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06088; Fri, 29 Jun 2001 07:51:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06055 for ; Fri, 29 Jun 2001 07:51:38 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29420 for ; Fri, 29 Jun 2001 07:50:55 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AB478DC20146; Fri, 29 Jun 2001 07:49:27 -0400 Message-ID: <004601c1008f$de8b9ee0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Fleischman, Eric W" , "Zmolek, Andrew \(Andrew\)" , "Scott Brim" Cc: "Melinda Shore" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DFD@XCH-NW-01.nw.nos.boeing.com> Subject: Re: [midcom] requirements-01 status Date: Fri, 29 Jun 2001 07:37:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Fleischman, Eric W" To: "'Bob Penfield'" ; "Zmolek, Andrew (Andrew)" ; "Scott Brim" Cc: "Melinda Shore" ; Sent: Thursday, June 28, 2001 7:25 PM Subject: RE: [midcom] requirements-01 status > >From: Bob Penfield [mailto:bpenfield@acmepacket.com] > >Andrew Zmolek wrote: > >> If interface specification did become a legitimate part of midcom, how > >> would an interface be specified? By some number? By some string? Would > >> this be something of a shared understanding between the middlebox and > >> the agent? Wouldn't this make agent (and middlebox) configuration more > >> complex? > > > >It could be as simple as using the domain names of the networks. I don't > >think the configuration is all that complex. In the middlebox you just need > >to label each interface with the domain name it is connected to. In the > >agent, the label would be associated with the signalling proxies. > > > >Say I have a network "mydomain.com" and you have a network "yourdomain.com" > >and we want to exchange SIP traffic and have a middlebox at the peering > > > I'm afraid that it won't be as simple as your example because the scenario > you have in mind is for communications between companies. However, > Midcom also has to work for communications WITHIN huge companies. Domain > names don't cut it in the latter case because I can not assure you that > there isn't some middlebox somewhere within any given arbitrary subdomain > (e.g., xxx.yyy.mydomain.com) that could be enumerated. OK, maybe domain names are not the right thing. It just needs to be a name or number that is an abstract representation of the networks/realms on either side of the middlebox. This would only be used in middleboxes at or near the border of the networks. > > --Eric > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 08:26:54 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 IAA24734 for ; Fri, 29 Jun 2001 08:26:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07035; Fri, 29 Jun 2001 08:21:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07006 for ; Fri, 29 Jun 2001 08:21:48 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20715 for ; Fri, 29 Jun 2001 08:21:04 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5TCLFw09157 for ; Fri, 29 Jun 2001 13:21:15 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Fri, 29 Jun 2001 13:20:48 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 13:20:45 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30445042@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'John Ladwig'" , brian@hursley.ibm.com Cc: midcom@ietf.org Subject: RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt Date: Fri, 29 Jun 2001 13:20:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10095.EA476880" 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_001_01C10095.EA476880 Content-Type: text/plain; charset="iso-8859-1" John, We all agree that the Middle Box is a policy enforcement point, but there is no need to define a PHB on per call, the main purpose of Diffserv is to do traffic prioritization and assign a behavior for certain type of traffic classified by the flow priority (the DSCP in our case). These PHBs are on the MB either by manual config or by propping down policies from a Policy Decision Point. I don't see the need to discuss that in the context of MIDCOM. I see bandwidth reservation functions required on low bandwidth access link interface, where the access interface is between 2 Middle Boxes and the agent requires the bandwidth to be reserved prior to establishing the call. But let's focus on Firewalls and NAT for IETF51, we need to finish the documents ... Cedric -----Original Message----- From: John Ladwig [mailto:jladwig@aravox.com] Sent: Friday, June 29, 2001 7:07 AM To: brian@hursley.ibm.com Cc: midcom@ietf.org Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt > > > 9. Resource control requirements > ... > > The Middlebox may provide QoS transport facilities for packet flows, > > for example, by setting DS-bytes or MPLS mappings. > > I think this is wrong in general, and it is certainly wrong in the > reference to diffserv. > > Firstly the correct phrase is "DS code points" and they are 6 bits long, > not a byte. The reference is RFC 2474. > > However, diffserv shouldn't be mentioned at all (see my previous comment > on the scenarios). Diffserv management is complicated enough already, > and we shouldn't add midcom to the mix. But isn't a middlebox useful as an enforcement point for whatever management you wish to implement? > I am very doubtful in general whether midcom should go near QOS management, so > personally I would remove the MPLS reference too. Do you seriously want hosts > hidden behind a firewall to know about MPLS mappings used by some ISP??? Putting my ISP hat on for a moment, I *very much* want to have the middlebox able to implement MPLS labeling on traffic so that packets may be steered along provisioned/quality-engineered pathways through my infrastructure, to the midcom agent's specifications and policies. Why don't/wouldn't you? Apologies if this has been said, or obsoleted; I'm playing catch-up on the discussion points. -jml _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C10095.EA476880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt

John,
We all agree that the Middle Box is a policy = enforcement point, but
there is no need to define a PHB on per call, the = main purpose of Diffserv
is to do traffic prioritization and assign a = behavior for certain type of traffic classified
by the flow priority (the DSCP in our case).
These PHBs are on the MB either by manual config = or
by propping down policies from a Policy Decision = Point.
I don't see the need to discuss that in the context = of MIDCOM.
I see bandwidth reservation functions required on = low bandwidth access link interface, where the access interface is =
between 2 Middle Boxes and the agent requires the = bandwidth to be reserved prior to establishing the call.
But let's focus on Firewalls and NAT for IETF51, we = need to finish the documents ...
Cedric
-----Original Message-----
From: John Ladwig [mailto:jladwig@aravox.com]=
Sent: Friday, June 29, 2001 7:07 AM
To: brian@hursley.ibm.com
Cc: midcom@ietf.org
Subject: Re: [midcom] Re: = draft-ietf-midcom-requirements-01.txt


>
> >   9.     = Resource control requirements
> ...
> = >          The = Middlebox may provide QoS transport facilities for packet flows, =
> = >          for example, = by setting DS-bytes or MPLS mappings.
>
> I think this is wrong in general, and it is = certainly wrong in the
> reference to diffserv.
>
> Firstly the correct phrase is "DS code = points" and they are 6 bits long,
> not a byte. The reference is RFC 2474.
>
> However, diffserv shouldn't be mentioned at all = (see my previous comment
> on the scenarios). Diffserv management is = complicated enough already,
> and we shouldn't add midcom to the mix.

But isn't a middlebox useful as an enforcement point = for whatever management
you wish to implement?

> I am very doubtful in general whether midcom = should go near QOS management, so
> personally I would remove the MPLS reference = too. Do you seriously want hosts
> hidden behind a firewall to know about MPLS = mappings used by some ISP???

Putting my ISP hat on for a moment, I *very much* = want to have the middlebox
able to implement MPLS labeling on traffic so that = packets may be steered
along provisioned/quality-engineered pathways = through my infrastructure,
to the midcom agent's specifications and = policies.

Why don't/wouldn't you?


Apologies if this has been said, or obsoleted; I'm = playing catch-up on the
discussion points.

    -jml


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C10095.EA476880-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 08:38:31 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 IAA02534 for ; Fri, 29 Jun 2001 08:38:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07746; Fri, 29 Jun 2001 08:34:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07707 for ; Fri, 29 Jun 2001 08:34:21 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29374 for ; Fri, 29 Jun 2001 08:33:37 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A54A8DD50146; Fri, 29 Jun 2001 08:32:10 -0400 Message-ID: <005001c10095$cac01e80$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christian Huitema" , "Melinda Shore" , "Sanjoy Sen" , "midcom" References: Subject: Re: [midcom] requirements-01 status Date: Fri, 29 Jun 2001 08:19:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 >I agree with Melinda here. The internal IP packets that are authorized >to sneak through a "pin-hole" will carry an internal source address and >an "external" destination address; the internal routing mechanisms will >direct these packet towards the firewall. If the firewall is to forward >these packets, it will have to do that based solely on the value of the >destination address -- there is no "scope of address" field in the IPv4 >packet. To operate properly, the firewall must have an internal routing >table that maps an IP address to an exit interface. Thus, the >"interface" to which an address is bound on a given midcom box has to be >deductible from the IP address itself. Ergo, direction and scope fields >are redundant. The middleboxes that I am talking about have no routing tables or routing capability. They sit on a pipe between two routers. Whatever comes in on one end of the pipe is sent out the other end. The routers take care of sending the packets down the right pipe. The "internal IP packets" will only have an internal source address if they originate in my network. If they originate in a neighboring network and came in through a peering point on the other side of my network, the middlebox cannot tell which end of the pipe the pin-hole belongs to. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 08:38: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 IAA02644 for ; Fri, 29 Jun 2001 08:38:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07667; Fri, 29 Jun 2001 08:33:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07637 for ; Fri, 29 Jun 2001 08:33:39 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28875 for ; Fri, 29 Jun 2001 08:32:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5TCXDx01780; Fri, 29 Jun 2001 05:33:13 -0700 (PDT) Received: from spandex (sjc-vpn-tmp220.cisco.com [10.21.64.220]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALP09986; Fri, 29 Jun 2001 05:33:04 -0700 (PDT) Message-ID: <023c01c10097$c8bee560$d45904d1@cisco.com> From: "Melinda Shore" To: "Cedric Aoun" , "Midcom IETF (E-mail)" References: <9154CB41F208D5118DD200508BE39C3044503D@zjguc006.europe.nortel.com> Subject: Re: [midcom] Out-of-path agents Date: Fri, 29 Jun 2001 08:33:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > In addition the OOP agent requires packet diversion capabilities on the > Middle Box, these might be achieved by the following procedure: Really, we can't do this. It's being regarded as an expansion of scope, and we don't have the work that's in scope completed yet. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 09:26: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 JAA01773 for ; Fri, 29 Jun 2001 09:26:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09231; Fri, 29 Jun 2001 09:19:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09200 for ; Fri, 29 Jun 2001 09:19:50 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27085 for ; Fri, 29 Jun 2001 09:19:08 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AFF48DF80146; Fri, 29 Jun 2001 09:17:40 -0400 Message-ID: <00df01c1009c$1aa36aa0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Melinda Shore" , "Scott Brim" Cc: References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEA@XCH-NW-01.nw.nos.boeing.com><007d01c0ff4c$50393e20$2300000a@acmepacket.com><012f01c0ff62$664bdea0$d45904d1@cisco.com><018201c0fffe$bb9a46c0$2300000a@acmepacket.com> <15163.38557.316000.255922@gargle.gargle.HOWL> <025701c1001d$ed94fb60$d45904d1@cisco.com> Subject: Re: [midcom] requirements-01 status Date: Fri, 29 Jun 2001 09:04:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Melinda Shore" To: "Scott Brim" ; "Bob Penfield" Cc: Sent: Thursday, June 28, 2001 6:01 PM Subject: Re: [midcom] requirements-01 status > > From: Scott Brim > > To: Bob Penfield > > Cc: Melinda Shore ; > > Sent: Thursday, June 28, 2001 4:42 PM > > Subject: Re: [midcom] requirements-01 status > > > > It looks to me like those saying interface specification is not > > necessary are assuming other functions in the middlebox which might not > > be there. > > I think we're all assuming that there's going to be some interaction > with the routing function in the middlebox, whether it's asking it to > route pinhole requests or to make the routing table available to > the middlebox function that's talking to the agent. > > I'll try to be clearer about my concerns: > > 1) Exporting routing tables to midcom agents scales poorly. Picture > a default-free middlebox. I agree. I am not suggesting that any routing tables be exported. > > 2) What happens when there are changes to the routing table on the > middlebox? The types of middleboxes I am talking about are just a bump on the wire with no routing information. They don't care when routes change. That's the router's job. > Do you really want to have agents become participants > in the routing system? ABSOLUTELY NOT!!! > > 3) Routing pinhole requests is necessarily tied to routing packets. > I think we should leave the separation of routing and forwarding to > other groups. > > 4) Exporting routing tables to midcom agents exposes network topology, > which is a security concern and which is deemed unacceptable by some > network administrators > > 5) Routing functions can be expensive to implement - longest partial > match, etc. Why should they be implemented in two places in order to > get one packet out one interface? > > I think we need to be really, really careful here. > > Melinda > > > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 09:29:41 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 JAA03889 for ; Fri, 29 Jun 2001 09:29:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09353; Fri, 29 Jun 2001 09:24:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09324 for ; Fri, 29 Jun 2001 09:24:56 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00424 for ; Fri, 29 Jun 2001 09:24:13 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A126D701A6; Fri, 29 Jun 2001 09:22:46 -0400 Message-ID: <00ec01c1009c$d034bd60$2300000a@acmepacket.com> From: "Bob Penfield" To: "Cedric Aoun" , "'John Ladwig'" , Cc: References: <9154CB41F208D5118DD200508BE39C30445042@zjguc006.europe.nortel.com> Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt Date: Fri, 29 Jun 2001 09:10:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Cedric Aoun" To: "'John Ladwig'" ; Cc: Sent: Friday, June 29, 2001 8:20 AM Subject: RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt > John, > We all agree that the Middle Box is a policy enforcement point, but > there is no need to define a PHB on per call, the main purpose of Diffserv > is to do traffic prioritization and assign a behavior for certain type of > traffic classified > by the flow priority (the DSCP in our case). > These PHBs are on the MB either by manual config or > by propping down policies from a Policy Decision Point. > I don't see the need to discuss that in the context of MIDCOM. I disagree. The idea is that a midcom agent be able to "assign" one of these established PHBs to a flow it is enabling thru the middlebox. I don't think anybody wants to use MIDCOM to define PHBs. We just need to be able set the priority for a flow that would otherwise get ordinary best-efforts treatment. > I see bandwidth reservation functions required on low bandwidth access link > interface, where the access interface is > between 2 Middle Boxes and the agent requires the bandwidth to be reserved > prior to establishing the call. > But let's focus on Firewalls and NAT for IETF51, we need to finish the > documents ... > Cedric > -----Original Message----- > From: John Ladwig [mailto:jladwig@aravox.com] > Sent: Friday, June 29, 2001 7:07 AM > To: brian@hursley.ibm.com > Cc: midcom@ietf.org > Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt > > > > > > > 9. Resource control requirements > > ... > > > The Middlebox may provide QoS transport facilities for packet > flows, > > > for example, by setting DS-bytes or MPLS mappings. > > > > I think this is wrong in general, and it is certainly wrong in the > > reference to diffserv. > > > > Firstly the correct phrase is "DS code points" and they are 6 bits long, > > not a byte. The reference is RFC 2474. > > > > However, diffserv shouldn't be mentioned at all (see my previous comment > > on the scenarios). Diffserv management is complicated enough already, > > and we shouldn't add midcom to the mix. > > But isn't a middlebox useful as an enforcement point for whatever management > you wish to implement? > > > I am very doubtful in general whether midcom should go near QOS > management, so > > personally I would remove the MPLS reference too. Do you seriously want > hosts > > hidden behind a firewall to know about MPLS mappings used by some ISP??? > > Putting my ISP hat on for a moment, I *very much* want to have the middlebox > able to implement MPLS labeling on traffic so that packets may be steered > along provisioned/quality-engineered pathways through my infrastructure, > to the midcom agent's specifications and policies. > > Why don't/wouldn't you? > > > Apologies if this has been said, or obsoleted; I'm playing catch-up on the > discussion points. > > -jml > > > _______________________________________________ > 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 Jun 29 09:56: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 JAA21703 for ; Fri, 29 Jun 2001 09:56:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10492; Fri, 29 Jun 2001 09:50:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10421 for ; Fri, 29 Jun 2001 09:50:21 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16836 for ; Fri, 29 Jun 2001 09:49:37 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5TDnlw03245 for ; Fri, 29 Jun 2001 14:49:47 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Fri, 29 Jun 2001 14:49:25 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 14:49:23 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30445048@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Melinda Shore'" , "Midcom IETF (E-mail)" Subject: RE: [midcom] Out-of-path agents Date: Fri, 29 Jun 2001 14:49:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C100A2.4C280E40" 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_001_01C100A2.4C280E40 Content-Type: text/plain; charset="iso-8859-1" OK, in agree to leave the subject in order to finish the documents for July 20th (3 weeks) and get things approved in London. AND interested parties could come back to it later on (after IETF51) to provide guidelines on the subject. Cedric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Friday, June 29, 2001 2:34 PM To: Aoun, Cedric [QPD:0000:EXCH]; Midcom IETF (E-mail) Subject: Re: [midcom] Out-of-path agents > In addition the OOP agent requires packet diversion capabilities on the > Middle Box, these might be achieved by the following procedure: Really, we can't do this. It's being regarded as an expansion of scope, and we don't have the work that's in scope completed yet. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C100A2.4C280E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Out-of-path agents

OK, in agree to leave the subject in order to finish = the documents for July 20th (3 weeks) and
get things approved in London.
AND interested parties could come back to it later = on (after IETF51) to provide guidelines on the subject.
Cedric

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Friday, June 29, 2001 2:34 PM
To: Aoun, Cedric [QPD:0000:EXCH]; Midcom IETF = (E-mail)
Subject: Re: [midcom] Out-of-path agents


> In addition the OOP agent requires packet = diversion capabilities on the
> Middle Box, these might be achieved by the = following procedure:

Really, we can't do this.  It's being regarded = as an expansion of
scope, and we don't have the work that's in scope = completed yet.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C100A2.4C280E40-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 10:11: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 KAA00815 for ; Fri, 29 Jun 2001 10:11:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11395; Fri, 29 Jun 2001 10:06:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11366 for ; Fri, 29 Jun 2001 10:06:44 -0400 (EDT) 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 KAA27545 for ; Fri, 29 Jun 2001 10:06:00 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5TE24H17353; Fri, 29 Jun 2001 07:04:28 -0700 (PDT) Received: from spandex (sjc-vpn-tmp220.cisco.com [10.21.64.220]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALP11098; Fri, 29 Jun 2001 07:03:15 -0700 (PDT) Message-ID: <034101c100a4$6bdd8240$d45904d1@cisco.com> From: "Melinda Shore" To: "Bob Penfield" Cc: References: <9154CB41F208D5118DD200508BE39C30445042@zjguc006.europe.nortel.com> <00ec01c1009c$d034bd60$2300000a@acmepacket.com> Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt Date: Fri, 29 Jun 2001 10:04:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > From: Bob Penfield > To: Cedric Aoun ; 'John Ladwig' ; > brian@hursley.ibm.com> > Cc: > Sent: Friday, June 29, 2001 9:10 AM > Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt > I disagree. The idea is that a midcom agent be able to "assign" one of these > established PHBs to a flow it is enabling thru the middlebox. I don't think > anybody wants to use MIDCOM to define PHBs. We just need to be able set the > priority for a flow that would otherwise get ordinary best-efforts > treatment. We need to leave open the possibility that someone could use midcom to do that, but really, let's stick with the firewall/NAT questions. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 10:13:26 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 KAA02111 for ; Fri, 29 Jun 2001 10:13:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11513; Fri, 29 Jun 2001 10:09:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11479 for ; Fri, 29 Jun 2001 10:09:37 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29316 for ; Fri, 29 Jun 2001 10:08:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5TDd5x01534; Fri, 29 Jun 2001 06:39:05 -0700 (PDT) Received: from spandex (sjc-vpn-tmp220.cisco.com [10.21.64.220]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALP10698; Fri, 29 Jun 2001 06:38:51 -0700 (PDT) Message-ID: <02f901c100a0$f9a21180$d45904d1@cisco.com> From: "Melinda Shore" To: "Bob Penfield" Cc: References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12DEA@XCH-NW-01.nw.nos.boeing.com><007d01c0ff4c$50393e20$2300000a@acmepacket.com><012f01c0ff62$664bdea0$d45904d1@cisco.com><018201c0fffe$bb9a46c0$2300000a@acmepacket.com> <15163.38557.316000.255922@gargle.gargle.HOWL> <025701c1001d$ed94fb60$d45904d1@cisco.com> <00df01c1009c$1aa36aa0$2300000a@acmepacket.com> Subject: Re: [midcom] requirements-01 status Date: Fri, 29 Jun 2001 09:39:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > The types of middleboxes I am talking about are just a bump on the wire with > no routing information. They don't care when routes change. That's the > router's job. Another part of a router's job is to choose which interface a packet goes to. Any time there's more than one interface (and even then, I suppose you could argue) you have to choose to send it to one interface or another. That's routing. And while your middlebox may be a bump in the wire with just two interfaces, we have to accomodate more complex configurations, too. What's being asked for here really is a routing function. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 10:13: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 KAA02378 for ; Fri, 29 Jun 2001 10:13:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11556; Fri, 29 Jun 2001 10:09:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11522 for ; Fri, 29 Jun 2001 10:09:45 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29419 for ; Fri, 29 Jun 2001 10:09:02 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA15150; Fri, 29 Jun 2001 15:09:12 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA81254; Fri, 29 Jun 2001 15:09:10 +0100 Message-ID: <3B3C89BB.6D21B89A@hursley.ibm.com> Date: Fri, 29 Jun 2001 08:59:23 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: John Ladwig CC: midcom@ietf.org Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt References: <200106290506.AAA28051@linux.aravox.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 John Ladwig wrote: > > > > > > 9. Resource control requirements > > ... > > > The Middlebox may provide QoS transport facilities for packet flows, > > > for example, by setting DS-bytes or MPLS mappings. > > > > I think this is wrong in general, and it is certainly wrong in the > > reference to diffserv. > > > > Firstly the correct phrase is "DS code points" and they are 6 bits long, > > not a byte. The reference is RFC 2474. > > > > However, diffserv shouldn't be mentioned at all (see my previous comment > > on the scenarios). Diffserv management is complicated enough already, > > and we shouldn't add midcom to the mix. > > But isn't a middlebox useful as an enforcement point for whatever management > you wish to implement? It might be, but then it should use the regular diffserv configuration mechanisms (COPS, SNMPCONF). The last thing we need is yet another way of doing it. > > > I am very doubtful in general whether midcom should go near QOS management, so > > personally I would remove the MPLS reference too. Do you seriously want hosts > > hidden behind a firewall to know about MPLS mappings used by some ISP??? > > Putting my ISP hat on for a moment, I *very much* want to have the middlebox > able to implement MPLS labeling on traffic so that packets may be steered > along provisioned/quality-engineered pathways through my infrastructure, > to the midcom agent's specifications and policies. So, you think it is an appropriate mixing of function to have the mechanism that controls NAT and firewall penetration also used as a traffic engineering tool? I think this is really using a hammer to operate a screw. It feels *dead wrong* to mix these things up, and it is clearly charter-creep as far as midcom is concerned. > > Why don't/wouldn't you? Because we should keep things separate whenever possible. Simple and modular is better than complex and monolithic. > > Apologies if this has been said, or obsoleted; I'm playing catch-up on the > discussion points. Me too. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 10:18:47 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 KAA05414 for ; Fri, 29 Jun 2001 10:18:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11772; Fri, 29 Jun 2001 10:15:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11744 for ; Fri, 29 Jun 2001 10:15:01 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02687 for ; Fri, 29 Jun 2001 10:14:16 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA34226; Fri, 29 Jun 2001 15:14:26 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA81304; Fri, 29 Jun 2001 15:14:24 +0100 Message-ID: <3B3C8AF4.78EAA5B2@hursley.ibm.com> Date: Fri, 29 Jun 2001 09:04:36 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bob Penfield CC: midcom@ietf.org Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt References: <200106141108.HAA24729@ietf.org> <3B3BA8A9.7ABCC46D@hursley.ibm.com> <004501c1008f$d194d580$2300000a@acmepacket.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 Bob Penfield wrote: > > ----- Original Message ----- > From: "Brian E Carpenter" > To: > Sent: Thursday, June 28, 2001 5:59 PM > Subject: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > > > I'm a bit puzzled by the isolated reference to Diffserv > > sitting in the middle of Figure 1, and the very brief mention > > at the beginning of the Introduction. While it is true that > > one possible location for diffserv classification and shaping > > is in a border router which is also a NAT and/or firewall, > > it can be done in any router or in hosts. And it has its > > own policy distribution mechanisms (COPS, SNMPCONF). > > So I would recommend removing the two brief references. > > I don't see why diffserv would be a midcom issue. > > Being able to set the DS code point is definitely something that > applications are going to want to do. For example, a SIP proxy acting as a > midcom agent talking to a middlebox at the border between networks will need > to instruct the middlebox to set the DSCP in the RTP packets that will flow > thru the middlebox. The RTP packets will not flow thru the SIP proxy/midcom > agent. The middlebox is the only place the application will be able to > affect QoS for the data flows. No, wrong model. The border device (whether it is the midcom version of a middlebox, or any old router) will apply diffserv classification and marking according to policy delivered from the diffserv policy server (a.k.a. PDP) by COPS or SNMPCONF. That is the diffserv management model; there is no need for the SIP proxy to enter the picture. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 11:27: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 LAA15007 for ; Fri, 29 Jun 2001 11:27:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14315; Fri, 29 Jun 2001 11:23:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14289 for ; Fri, 29 Jun 2001 11:23:39 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14585 for ; Fri, 29 Jun 2001 11:22:56 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id ACFB65640144; Fri, 29 Jun 2001 11:21:31 -0400 Message-ID: <006201c100ad$3e785420$2300000a@acmepacket.com> From: "Bob Penfield" To: "Brian E Carpenter" Cc: References: <200106141108.HAA24729@ietf.org> <3B3BA8A9.7ABCC46D@hursley.ibm.com> <004501c1008f$d194d580$2300000a@acmepacket.com> <3B3C8AF4.78EAA5B2@hursley.ibm.com> Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 11:07:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Brian E Carpenter" To: "Bob Penfield" Cc: Sent: Friday, June 29, 2001 10:04 AM Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > Bob Penfield wrote: > > > > ----- Original Message ----- > > From: "Brian E Carpenter" > > To: > > Sent: Thursday, June 28, 2001 5:59 PM > > Subject: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > > > > > I'm a bit puzzled by the isolated reference to Diffserv > > > sitting in the middle of Figure 1, and the very brief mention > > > at the beginning of the Introduction. While it is true that > > > one possible location for diffserv classification and shaping > > > is in a border router which is also a NAT and/or firewall, > > > it can be done in any router or in hosts. And it has its > > > own policy distribution mechanisms (COPS, SNMPCONF). > > > So I would recommend removing the two brief references. > > > I don't see why diffserv would be a midcom issue. > > > > Being able to set the DS code point is definitely something that > > applications are going to want to do. For example, a SIP proxy acting as a > > midcom agent talking to a middlebox at the border between networks will need > > to instruct the middlebox to set the DSCP in the RTP packets that will flow > > thru the middlebox. The RTP packets will not flow thru the SIP proxy/midcom > > agent. The middlebox is the only place the application will be able to > > affect QoS for the data flows. > > No, wrong model. The border device (whether it is the midcom version of > a middlebox, or any old router) will apply diffserv classification and > marking according to policy delivered from the diffserv policy server > (a.k.a. PDP) by COPS or SNMPCONF. That is the diffserv management > model; there is no need for the SIP proxy to enter the picture. > Given that the flows that need preferred treatment are being dynamically created and destroyed in the SIP network, how would that work? How will the border device know which flows get marked and which don't if it is not aware of the dynamic flows? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 12:01: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 MAA16213 for ; Fri, 29 Jun 2001 12:01:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15302; Fri, 29 Jun 2001 11:56:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15274 for ; Fri, 29 Jun 2001 11:56:51 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15948 for ; Fri, 29 Jun 2001 11:56:07 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA17070; Fri, 29 Jun 2001 16:56:18 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA44618; Fri, 29 Jun 2001 16:56:17 +0100 Message-ID: <3B3CA2B2.26E305E4@hursley.ibm.com> Date: Fri, 29 Jun 2001 10:45:54 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bob Penfield CC: midcom@ietf.org Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt References: <200106141108.HAA24729@ietf.org> <3B3BA8A9.7ABCC46D@hursley.ibm.com> <004501c1008f$d194d580$2300000a@acmepacket.com> <3B3C8AF4.78EAA5B2@hursley.ibm.com> <006201c100ad$3e785420$2300000a@acmepacket.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 Bob Penfield wrote: > > ----- Original Message ----- > From: "Brian E Carpenter" > To: "Bob Penfield" > Cc: > Sent: Friday, June 29, 2001 10:04 AM > Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > > > Bob Penfield wrote: > > > > > > ----- Original Message ----- > > > From: "Brian E Carpenter" > > > To: > > > Sent: Thursday, June 28, 2001 5:59 PM > > > Subject: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > > > > > > > I'm a bit puzzled by the isolated reference to Diffserv > > > > sitting in the middle of Figure 1, and the very brief mention > > > > at the beginning of the Introduction. While it is true that > > > > one possible location for diffserv classification and shaping > > > > is in a border router which is also a NAT and/or firewall, > > > > it can be done in any router or in hosts. And it has its > > > > own policy distribution mechanisms (COPS, SNMPCONF). > > > > So I would recommend removing the two brief references. > > > > I don't see why diffserv would be a midcom issue. > > > > > > Being able to set the DS code point is definitely something that > > > applications are going to want to do. For example, a SIP proxy acting as > a > > > midcom agent talking to a middlebox at the border between networks will > need > > > to instruct the middlebox to set the DSCP in the RTP packets that will > flow > > > thru the middlebox. The RTP packets will not flow thru the SIP > proxy/midcom > > > agent. The middlebox is the only place the application will be able to > > > affect QoS for the data flows. > > > > No, wrong model. The border device (whether it is the midcom version of > > a middlebox, or any old router) will apply diffserv classification and > > marking according to policy delivered from the diffserv policy server > > (a.k.a. PDP) by COPS or SNMPCONF. That is the diffserv management > > model; there is no need for the SIP proxy to enter the picture. > > > Given that the flows that need preferred treatment are being dynamically > created and destroyed in the SIP network, how would that work? How will the > border device know which flows get marked and which don't if it is not aware > of the dynamic flows? Diffserv doesn't have per-flow classifiers, so there is nothing a SIP proxy can say for a single new flow. The policy system has to define a classifier for each *type* of traffic, not for individual flows. This is done globally per diffserv domain and is relatively static. The classifier will be given the appropriate classifier specifications by the diffserv policy system. These are n-tuple specifications just like any other. If you grok MIB they look like: DiffServSixTupleClfrEntry ::= SEQUENCE { diffServSixTupleClfrId INTEGER, diffServSixTupleClfrDstAddrType InetAddressType, diffServSixTupleClfrDstAddr InetAddress, diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength, diffServSixTupleClfrSrcAddrType InetAddressType, diffServSixTupleClfrSrcAddr InetAddress, diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength, diffServSixTupleClfrDscp DscpOrAny, diffServSixTupleClfrProtocol Unsigned32, diffServSixTupleClfrDstL4PortMin InetPortNumber, diffServSixTupleClfrDstL4PortMax InetPortNumber, diffServSixTupleClfrSrcL4PortMin InetPortNumber, diffServSixTupleClfrSrcL4PortMax InetPortNumber, diffServSixTupleClfrStatus RowStatus } in other words source and destination address ranges, DSCP, protocol #, port ranges, any of which can be wild-carded. You might set a classifier up for a few hours, but I would expect them to be essentially permament and certainly they don't change on a flow-by-flow basis. If you want that, use Integrated Services. All this is orthogonal to midcom. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 12:49: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 MAA18523 for ; Fri, 29 Jun 2001 12:49:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17474; Fri, 29 Jun 2001 12:45:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17445 for ; Fri, 29 Jun 2001 12:44:58 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18386 for ; Fri, 29 Jun 2001 12:44:14 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5TGi9427264 for ; Fri, 29 Jun 2001 12:44:09 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5TGi8A27248 for ; Fri, 29 Jun 2001 12:44:08 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C100BA.D52E7716" Subject: RE: [midcom] requirements-01 status X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Fri, 29 Jun 2001 10:44:58 -0600 Message-ID: Thread-Topic: [midcom] requirements-01 status Thread-Index: AcEAl+l7WTX63rUSR66Et+T3tMwPRgAILAgA From: "Zmolek, Andrew (Andrew)" To: "Bob Penfield" , "Christian Huitema" , "Melinda Shore" , "Sanjoy Sen" , "midcom" 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 multi-part message in MIME format. ------_=_NextPart_001_01C100BA.D52E7716 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The middleboxes that I am talking about have no routing tables or routing > capability. They sit on a pipe between two routers. Whatever comes in on one > end of the pipe is sent out the other end. The routers take care of sending > the packets down the right pipe. In this simplistic case, the routers can be reasonably expected to take care of anti-spoofing as well, so it really won't matter if the middlebox uses the same set of pinholes on all interfaces. But on the other hand, I don't see a big problem with adding something like a 1-byte token to the spec that could be given meaning outside of midcom. If you want to implement it to mean "interface" then that could be fine as long as you don't expect that byte to mean anything outside of your own closed, preconfigured system. For the general case, I agree with Melinda that interface identification doesn't belong in midcom, especially when it forces application agents (assumed to be ignorant of the routing topology) to make interface decisions. We don't want to force the tail to wag the dog. But adding a 1-byte token might be useful for very simple toplogies with static routing and simple agent configuration. Comments? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 ------_=_NextPart_001_01C100BA.D52E7716 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] requirements-01 status

> The middleboxes that I am talking about have no = routing tables or routing
> capability. They sit on a pipe between two = routers. Whatever comes in on one
> end of the pipe is sent out the other end. The = routers take care of sending
> the packets down the right pipe.

In this simplistic case, the routers can be reasonably = expected to take care of anti-spoofing as well, so it really won't = matter if the middlebox uses the same set of pinholes on all interfaces. = But on the other hand, I don't see a big problem with adding something = like a 1-byte token to the spec that could be given meaning outside of = midcom. If you want to implement it to mean "interface" then = that could be fine as long as you don't expect that byte to mean = anything outside of your own closed, preconfigured system.

For the general case, I agree with Melinda that = interface identification doesn't belong in midcom, especially when it = forces application agents (assumed to be ignorant of the routing = topology) to make interface decisions. We don't want to force the tail = to wag the dog. But adding a 1-byte token might be useful for very = simple toplogies with static routing and simple agent configuration. = Comments?

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001

------_=_NextPart_001_01C100BA.D52E7716-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 13:59: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 NAA21043 for ; Fri, 29 Jun 2001 13:59:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19828; Fri, 29 Jun 2001 13:52:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19797 for ; Fri, 29 Jun 2001 13:52:11 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20798 for ; Fri, 29 Jun 2001 13:51:28 -0400 (EDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 29 Jun 2001 09:22:15 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Jun 2001 09:21:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Jun 2001 09:21:58 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Jun 2001 09:21:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 09:21:16 -0700 Message-ID: Thread-Topic: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Thread-Index: AcEAsnCuD+eRQh7mS5qlettCOqJpOAAA/QxQ From: "Christian Huitema" To: "Brian E Carpenter" , "Bob Penfield" Cc: X-OriginalArrivalTime: 29 Jun 2001 16:21:16.0477 (UTC) FILETIME=[85AC6ED0:01C100B7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA19798 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: 8bit > Given that the flows that need preferred treatment are being dynamically > created and destroyed in the SIP network, how would that work? How will > the > border device know which flows get marked and which don't if it is not > aware > of the dynamic flows? SIP is by no means the only way to initiate transmission of real-time A/V flows between internet hosts. Other ways include SAP, RTSP, documentation of SDP streams in web pages, etc. Then, A/V is by no means the only application that has delay constraints; video games come to mind, and they definitely don't use SIP. There are at least three solutions to the marking problem: * one possibility is to just let the sender do the marking. This works well in a controlled environment, and is in fact enabled by MGCP for VoIP solutions. * another possibility is have a router analyze the traffic, recognize some applications, and "promote" them. This is in fact the modus operandi in most corporate networks today, with priorities based on IP addresses and port ranges. * yet another possibility is to use explicit signaling, such as RSVP, to negotiate the right to use this or that marking. Brian is right when it comes to charter creep. The primary task of this group is to enable the crossing of firewalls and NATs. The IETF already has defined standards for managing quality of service. There is no reason to sneak quality of service work into MIDCOM. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 14:08:57 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 OAA21513 for ; Fri, 29 Jun 2001 14:08:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20587; Fri, 29 Jun 2001 14:03:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20553 for ; Fri, 29 Jun 2001 14:03:34 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21244 for ; Fri, 29 Jun 2001 14:02:50 -0400 (EDT) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 29 Jun 2001 09:11:49 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Jun 2001 09:11:47 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Jun 2001 09:11:47 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Jun 2001 09:11:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] requirements-01 status Date: Fri, 29 Jun 2001 09:11:03 -0700 Message-ID: Thread-Topic: [midcom] requirements-01 status Thread-Index: AcEAl75Ec6fZvkBNSaufljGZaSX1PAAHjtUQ From: "Christian Huitema" To: "Bob Penfield" , "Melinda Shore" , "Sanjoy Sen" , "midcom" X-OriginalArrivalTime: 29 Jun 2001 16:11:03.0867 (UTC) FILETIME=[188790B0:01C100B6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA20554 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: 8bit > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > >I agree with Melinda here. The internal IP packets that are authorized > >to sneak through a "pin-hole" will carry an internal source address and > >an "external" destination address; the internal routing mechanisms will > >direct these packet towards the firewall. If the firewall is to forward > >these packets, it will have to do that based solely on the value of the > >destination address -- there is no "scope of address" field in the IPv4 > >packet. To operate properly, the firewall must have an internal routing > >table that maps an IP address to an exit interface. Thus, the > >"interface" to which an address is bound on a given midcom box has to be > >deductible from the IP address itself. Ergo, direction and scope fields > >are redundant. > > The middleboxes that I am talking about have no routing tables or routing > capability. They sit on a pipe between two routers. Whatever comes in on > one > end of the pipe is sent out the other end. The routers take care of > sending > the packets down the right pipe. Uh? The thing that you describe has essentially no place in the Internet architecture, and is probably out of scope for this WG. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 14:11: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 OAA21589 for ; Fri, 29 Jun 2001 14:11:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20689; Fri, 29 Jun 2001 14:06:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20656 for ; Fri, 29 Jun 2001 14:06:47 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21344 for ; Fri, 29 Jun 2001 14:06:04 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21]) by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f5THWPi19837; Fri, 29 Jun 2001 10:32:29 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 11:02:59 -0700 Message-ID: From: John LaCour To: "'Christian Huitema'" , "'midcom@ietf.org'" Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 11:08:48 -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 > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > documentation of SDP streams in web pages, etc. Then, A/V is > by no means > the only application that has delay constraints; video games come to > mind, and they definitely don't use SIP. There are at least three > solutions to the marking problem: > > > * another possibility is have a router analyze the traffic, recognize s/router/middlebox > some applications, and "promote" them. This is in fact the modus > operandi in most corporate networks today, with priorities based on IP > addresses and port ranges. > > Brian is right when it comes to charter creep. The primary > task of this > group is to enable the crossing of firewalls and NATs. The > IETF already > has defined standards for managing quality of service. There is no > reason to sneak quality of service work into MIDCOM. I agree about charter creep, but lets not paint ourselves into a corner that excludes it for future consideration. > -- Christian Huitema -John _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 15:13:34 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 PAA23428 for ; Fri, 29 Jun 2001 15:13:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21673; Fri, 29 Jun 2001 14:35:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21648 for ; Fri, 29 Jun 2001 14:35:08 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22369 for ; Fri, 29 Jun 2001 14:34:24 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5TIYK024652 for ; Fri, 29 Jun 2001 14:34:20 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 29 Jun 2001 14:34:17 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 14:34:20 -0400 Message-ID: From: "Fernando Cuervo" To: "'Zmolek, Andrew (Andrew)'" Cc: Bob Penfield , Christian Huitema , Melinda Shore , "Sanjoy Sen" , midcom Subject: RE: [midcom] requirements-01 status Date: Fri, 29 Jun 2001 14:34:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C100CA.1A8A9C90" X-Orig: 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_001_01C100CA.1A8A9C90 Content-Type: text/plain You could also add a policy data object that is opaque to Midcom, it could have a variety of applications within a "closed-preconfigured" system Fernando Cuervo > -----Original Message----- > From: Zmolek, Andrew (Andrew) [SMTP:zmolek@avaya.com] > Sent: Friday, June 29, 2001 12:45 PM > To: Bob Penfield; Christian Huitema; Melinda Shore; Sen, Sanjoy > [NGB:B602:EXCH]; midcom > Subject: RE: [midcom] requirements-01 status > > > The middleboxes that I am talking about have no routing tables or > routing > > capability. They sit on a pipe between two routers. Whatever comes in on > one > > end of the pipe is sent out the other end. The routers take care of > sending > > the packets down the right pipe. > > In this simplistic case, the routers can be reasonably expected to take > care of anti-spoofing as well, so it really won't matter if the middlebox > uses the same set of pinholes on all interfaces. But on the other hand, I > don't see a big problem with adding something like a 1-byte token to the > spec that could be given meaning outside of midcom. If you want to > implement it to mean "interface" then that could be fine as long as you > don't expect that byte to mean anything outside of your own closed, > preconfigured system. > > For the general case, I agree with Melinda that interface identification > doesn't belong in midcom, especially when it forces application agents > (assumed to be ignorant of the routing topology) to make interface > decisions. We don't want to force the tail to wag the dog. But adding a > 1-byte token might be useful for very simple toplogies with static routing > and simple agent configuration. Comments? > > --Andy Zmolek > Technology & Standards Engineer > CTO Standards > Avaya Inc. > > zmolek@avaya.com > +1 720 444 4001 > ------_=_NextPart_001_01C100CA.1A8A9C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] requirements-01 status

You could also add a = policy data object that is opaque to Midcom, it could have a variety of = applications within a "closed-preconfigured" = system

Fernando = Cuervo

    -----Original Message-----
    From:   Zmolek, Andrew (Andrew) = [SMTP:zmolek@avaya.com]
    Sent:   Friday, June 29, 2001 12:45 PM
    To:     Bob Penfield; Christian Huitema; Melinda Shore; Sen, = Sanjoy [NGB:B602:EXCH]; midcom
    Subject:       = RE: [midcom] requirements-01 = status

    > The middleboxes that I am talking = about have no routing tables or routing
    > capability. They sit on a = pipe between two routers. Whatever comes in on one
    > end of the pipe is sent out = the other end. The routers take care of sending
    > the packets down the right = pipe.

    In this simplistic case, the routers = can be reasonably expected to take care of anti-spoofing as well, so it = really won't matter if the middlebox uses the same set of pinholes on = all interfaces. But on the other hand, I don't see a big problem with = adding something like a 1-byte token to the spec that could be given = meaning outside of midcom. If you want to implement it to mean = "interface" then that could be fine as long as you don't = expect that byte to mean anything outside of your own closed, = preconfigured system.

    For the general case, I agree with = Melinda that interface identification doesn't belong in midcom, = especially when it forces application agents (assumed to be ignorant of = the routing topology) to make interface decisions. We don't want to = force the tail to wag the dog. But adding a 1-byte token might be = useful for very simple toplogies with static routing and simple agent = configuration. Comments?

    --Andy Zmolek
    =A0=A0=A0 Technology & = Standards Engineer
    =A0=A0=A0=A0=A0 CTO = Standards
    =A0=A0=A0=A0=A0=A0=A0 Avaya = Inc.

    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = zmolek@avaya.com
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +1 720 444 = 4001

------_=_NextPart_001_01C100CA.1A8A9C90-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 16:20: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 QAA24724 for ; Fri, 29 Jun 2001 16:20:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22734; Fri, 29 Jun 2001 15:07:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22703 for ; Fri, 29 Jun 2001 15:07:56 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23274 for ; Fri, 29 Jun 2001 15:07:13 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5TJ7A029000 for ; Fri, 29 Jun 2001 15:07:10 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 29 Jun 2001 15:07:04 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 15:07:06 -0400 Message-ID: From: "Fernando Cuervo" To: "'John LaCour'" Cc: "'Christian Huitema'" , "'midcom@ietf.org'" Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 15:07:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C100CE.AD80B1C0" X-Orig: 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_001_01C100CE.AD80B1C0 Content-Type: text/plain I agree with you, an agent may benefit from the Midcom protocol being able to explicitly signal QoS service requirements, in addition to f/w and NAT. Therefore, we must balance this against the undesirability of "charter-creep". Fernando Cuervo > -----Original Message----- > From: John LaCour [SMTP:jlacour@netscreen.com] > Sent: Friday, June 29, 2001 2:09 PM > To: 'Christian Huitema'; 'midcom@ietf.org' > Subject: RE: [midcom] Re: I-D > ACTION:draft-ietf-midcom-framework-02.txt > > > > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > > documentation of SDP streams in web pages, etc. Then, A/V is > > by no means > > the only application that has delay constraints; video games come to > > mind, and they definitely don't use SIP. There are at least three > > solutions to the marking problem: > > > > > > * another possibility is have a router analyze the traffic, recognize > > s/router/middlebox > > > some applications, and "promote" them. This is in fact the modus > > operandi in most corporate networks today, with priorities based on IP > > addresses and port ranges. > > > > Brian is right when it comes to charter creep. The primary > > task of this > > group is to enable the crossing of firewalls and NATs. The > > IETF already > > has defined standards for managing quality of service. There is no > > reason to sneak quality of service work into MIDCOM. > > I agree about charter creep, but lets not paint ourselves into a > corner that excludes it for future consideration. > > > -- Christian Huitema > > -John > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C100CE.AD80B1C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: I-D = ACTION:draft-ietf-midcom-framework-02.txt

I agree with you, an = agent may benefit from the Midcom protocol being able to explicitly = signal QoS service requirements, in addition to f/w and NAT. Therefore, = we must balance this against the undesirability of = "charter-creep".

Fernando = Cuervo


    -----Original Message-----
    From:   John LaCour [SMTP:jlacour@netscreen.com]
    Sent:   Friday, June 29, 2001 2:09 PM
    To:     'Christian Huitema'; 'midcom@ietf.org'
    Subject:       = RE: [midcom] Re: I-D = ACTION:draft-ietf-midcom-framework-02.txt



    > From: Christian Huitema = [mailto:huitema@windows.mic= rosoft.com]

    > documentation of SDP streams in = web pages, etc. Then, A/V is
    > by no means
    > the only application that has = delay constraints; video games come to
    > mind, and they definitely don't = use SIP. There are at least three
    > solutions to the marking = problem:
    >
    >
    > * another possibility is have a = router analyze the traffic, recognize

    s/router/middlebox

    > some applications, and = "promote" them. This is in fact the modus
    > operandi in most corporate = networks today, with priorities based on IP
    > addresses and port = ranges.
    >
    > Brian is right when it comes to = charter creep. The primary
    > task of this
    > group is to enable the crossing = of firewalls and NATs. The
    > IETF already
    > has defined standards for = managing quality of service. There is no
    > reason to sneak quality of = service work into MIDCOM.

    I agree about charter creep, but lets = not paint ourselves into a
    corner that excludes it for future = consideration.

    > -- Christian Huitema

    -John

    _______________________________________________
    midcom mailing list
    midcom@ietf.org
    http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C100CE.AD80B1C0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 17:00:18 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 RAA25180 for ; Fri, 29 Jun 2001 17:00:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25700; Fri, 29 Jun 2001 16:51:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25670 for ; Fri, 29 Jun 2001 16:51:03 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25040 for ; Fri, 29 Jun 2001 16:50:15 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N7A4NRTD; Fri, 29 Jun 2001 16:03:52 -0400 Message-Id: <3.0.5.32.20010629155927.007bc970@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 29 Jun 2001 15:59:27 -0400 To: Brian E Carpenter , Bob Penfield From: Mark Duffy Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Cc: midcom@ietf.org In-Reply-To: <3B3CA2B2.26E305E4@hursley.ibm.com> References: <200106141108.HAA24729@ietf.org> <3B3BA8A9.7ABCC46D@hursley.ibm.com> <004501c1008f$d194d580$2300000a@acmepacket.com> <3B3C8AF4.78EAA5B2@hursley.ibm.com> <006201c100ad$3e785420$2300000a@acmepacket.com> 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 >Diffserv doesn't have per-flow classifiers, so there is nothing a SIP >proxy can say for a single new flow. The policy system has to define a >classifier for each *type* of traffic, not for individual flows. This is >done globally per diffserv domain and is relatively static. > >The classifier will be given the appropriate classifier specifications >by the diffserv policy system. These are n-tuple specifications just >like any other. If you grok MIB they look like: > >DiffServSixTupleClfrEntry ::= SEQUENCE { > diffServSixTupleClfrId INTEGER, > diffServSixTupleClfrDstAddrType InetAddressType, > diffServSixTupleClfrDstAddr InetAddress, > diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength, > diffServSixTupleClfrSrcAddrType InetAddressType, > diffServSixTupleClfrSrcAddr InetAddress, > diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength, > diffServSixTupleClfrDscp DscpOrAny, > diffServSixTupleClfrProtocol Unsigned32, > diffServSixTupleClfrDstL4PortMin InetPortNumber, > diffServSixTupleClfrDstL4PortMax InetPortNumber, > diffServSixTupleClfrSrcL4PortMin InetPortNumber, > diffServSixTupleClfrSrcL4PortMax InetPortNumber, > diffServSixTupleClfrStatus RowStatus >} Yes, but since the flows of type 'SIP' come on dynamic ports, you can't readily match them using a classifier like that. However, a middlebox aka diffserv-domain-edge-traffic-conditioning-box that is aware of which flows are SIP could apply a *static* policy that says mark SIP packets (or perhaps, SIP packets to/from certain addresses) with a certain DSCP. And in the spirit of midcom, one would want the midcom agent to tell the middlebox about this flow (perhaps not what DSCP to use, but that it is SIP). -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 17:33: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 RAA25671 for ; Fri, 29 Jun 2001 17:33:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26561; Fri, 29 Jun 2001 17:20:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26531 for ; Fri, 29 Jun 2001 17:20:50 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25522 for ; Fri, 29 Jun 2001 17:20:07 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA27534; Fri, 29 Jun 2001 22:20:18 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA44602; Fri, 29 Jun 2001 22:20:17 +0100 Message-ID: <3B3CF017.68CD084F@hursley.ibm.com> Date: Fri, 29 Jun 2001 16:16:07 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mark Duffy CC: Bob Penfield , midcom@ietf.org Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt References: <200106141108.HAA24729@ietf.org> <3B3BA8A9.7ABCC46D@hursley.ibm.com> <004501c1008f$d194d580$2300000a@acmepacket.com> <3B3C8AF4.78EAA5B2@hursley.ibm.com> <006201c100ad$3e785420$2300000a@acmepacket.com> <3.0.5.32.20010629155927.007bc970@10.1.1.249> 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 Mark Duffy wrote: > > >Diffserv doesn't have per-flow classifiers, so there is nothing a SIP > >proxy can say for a single new flow. The policy system has to define a > >classifier for each *type* of traffic, not for individual flows. This is > >done globally per diffserv domain and is relatively static. > > > >The classifier will be given the appropriate classifier specifications > >by the diffserv policy system. These are n-tuple specifications just > >like any other. If you grok MIB they look like: > > > >DiffServSixTupleClfrEntry ::= SEQUENCE { > > diffServSixTupleClfrId INTEGER, > > diffServSixTupleClfrDstAddrType InetAddressType, > > diffServSixTupleClfrDstAddr InetAddress, > > diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength, > > diffServSixTupleClfrSrcAddrType InetAddressType, > > diffServSixTupleClfrSrcAddr InetAddress, > > diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength, > > diffServSixTupleClfrDscp DscpOrAny, > > diffServSixTupleClfrProtocol Unsigned32, > > diffServSixTupleClfrDstL4PortMin InetPortNumber, > > diffServSixTupleClfrDstL4PortMax InetPortNumber, > > diffServSixTupleClfrSrcL4PortMin InetPortNumber, > > diffServSixTupleClfrSrcL4PortMax InetPortNumber, > > diffServSixTupleClfrStatus RowStatus > >} > > Yes, but since the flows of type 'SIP' come on dynamic ports, you can't > readily match them using a classifier like that. There's nothing to prevent you defining a classifier that uses some other n-tuple that does identify media traffic. > However, a middlebox aka > diffserv-domain-edge-traffic-conditioning-box that is aware of which flows > are SIP could apply a *static* policy that says mark SIP packets (or > perhaps, SIP packets to/from certain addresses) with a certain DSCP. And > in the spirit of midcom, one would want the midcom agent to tell the > middlebox about this flow (perhaps not what DSCP to use, but that it is SIP). It would all be much simpler if the source of the media stream marked its own packets; then neither the proxy nor the middlebox need to worry about it. That is in fact the simplest realisation of diffserv. All this goes to show that it's a complex topic, beyond what I thought midcom was intended for. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 17:46:44 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 RAA25898 for ; Fri, 29 Jun 2001 17:46:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27039; Fri, 29 Jun 2001 17:34:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27010 for ; Fri, 29 Jun 2001 17:34:49 -0400 (EDT) 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 RAA25684 for ; Fri, 29 Jun 2001 17:34:05 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5TLYMh04678; Fri, 29 Jun 2001 14:34:22 -0700 (PDT) Received: from spandex (rtp-vpn-14.cisco.com [10.82.192.14]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ALU03369; Fri, 29 Jun 2001 14:34:10 -0700 (PDT) Message-ID: <001401c100e3$60a84060$d45904d1@cisco.com> From: "Melinda Shore" To: "Brian E Carpenter" Cc: References: <200106141108.HAA24729@ietf.org> <3B3BA8A9.7ABCC46D@hursley.ibm.com> <004501c1008f$d194d580$2300000a@acmepacket.com> <3B3C8AF4.78EAA5B2@hursley.ibm.com> <006201c100ad$3e785420$2300000a@acmepacket.com> <3.0.5.32.20010629155927.007bc970@10.1.1.249> <3B3CF017.68CD084F@hursley.ibm.com> Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 17:35:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > From: Brian E Carpenter > To: Mark Duffy > Cc: Bob Penfield ; > Sent: Friday, June 29, 2001 5:16 PM > Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > All this goes to show that it's a complex topic, beyond what I thought midcom > was intended for. Indeed, and I think we received a pretty clear message to take the scope outlined in the charter very seriously. If someone wants to write a draft on the use of midcom for pushing packet markings out to routers they're certainly free to do that, but it is out of scope for midcom deliverables and the material would not be incorporated into the framework or requirements document. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 17:48: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 RAA25956 for ; Fri, 29 Jun 2001 17:48:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27257; Fri, 29 Jun 2001 17:42:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27186 for ; Fri, 29 Jun 2001 17:42:21 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25846 for ; Fri, 29 Jun 2001 17:41:38 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A5BC66450144; Fri, 29 Jun 2001 17:40:12 -0400 Message-ID: <009401c100e4$68b943c0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Brian E Carpenter" , "Mark Duffy" Cc: References: <200106141108.HAA24729@ietf.org> <3B3BA8A9.7ABCC46D@hursley.ibm.com> <004501c1008f$d194d580$2300000a@acmepacket.com> <3B3C8AF4.78EAA5B2@hursley.ibm.com> <006201c100ad$3e785420$2300000a@acmepacket.com> <3.0.5.32.20010629155927.007bc970@10.1.1.249> <3B3CF017.68CD084F@hursley.ibm.com> Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 17:42:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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: "Brian E Carpenter" To: "Mark Duffy" Cc: "Bob Penfield" ; Sent: Friday, June 29, 2001 5:16 PM Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > Mark Duffy wrote: > > > > >Diffserv doesn't have per-flow classifiers, so there is nothing a SIP > > >proxy can say for a single new flow. The policy system has to define a > > >classifier for each *type* of traffic, not for individual flows. This is > > >done globally per diffserv domain and is relatively static. > > > > > >The classifier will be given the appropriate classifier specifications > > >by the diffserv policy system. These are n-tuple specifications just > > >like any other. If you grok MIB they look like: > > > > > >DiffServSixTupleClfrEntry ::= SEQUENCE { > > > diffServSixTupleClfrId INTEGER, > > > diffServSixTupleClfrDstAddrType InetAddressType, > > > diffServSixTupleClfrDstAddr InetAddress, > > > diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength, > > > diffServSixTupleClfrSrcAddrType InetAddressType, > > > diffServSixTupleClfrSrcAddr InetAddress, > > > diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength, > > > diffServSixTupleClfrDscp DscpOrAny, > > > diffServSixTupleClfrProtocol Unsigned32, > > > diffServSixTupleClfrDstL4PortMin InetPortNumber, > > > diffServSixTupleClfrDstL4PortMax InetPortNumber, > > > diffServSixTupleClfrSrcL4PortMin InetPortNumber, > > > diffServSixTupleClfrSrcL4PortMax InetPortNumber, > > > diffServSixTupleClfrStatus RowStatus > > >} > > > > Yes, but since the flows of type 'SIP' come on dynamic ports, you can't > > readily match them using a classifier like that. > > There's nothing to prevent you defining a classifier that uses > some other n-tuple that does identify media traffic. > > > However, a middlebox aka > > diffserv-domain-edge-traffic-conditioning-box that is aware of which flows > > are SIP could apply a *static* policy that says mark SIP packets (or > > perhaps, SIP packets to/from certain addresses) with a certain DSCP. And > > in the spirit of midcom, one would want the midcom agent to tell the > > middlebox about this flow (perhaps not what DSCP to use, but that it is SIP). > > It would all be much simpler if the source of the media stream marked its > own packets; then neither the proxy nor the middlebox need to worry about it. > That is in fact the simplest realisation of diffserv. But diffserv is not end-to-end, right? If the flow is traversing several Autonomous Systems, won't each AS apply different QOS measures? The combination of a SIP proxy and a middlebox can constitute an ALG which is often implemented as what SIP calls a back-to-back user agent which terminates and re-generates the flow. In this case, the middlebox becomes the source of the media flow within the local AS. > > All this goes to show that it's a complex topic, beyond what I thought midcom > was intended for. > > Brian > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 17:57: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 RAA26061 for ; Fri, 29 Jun 2001 17:57:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27320; Fri, 29 Jun 2001 17:42:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27283 for ; Fri, 29 Jun 2001 17:42:55 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25857 for ; Fri, 29 Jun 2001 17:42:12 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N7A4NRY7; Fri, 29 Jun 2001 17:42:24 -0400 Message-Id: <3.0.5.32.20010629173801.009096d0@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 29 Jun 2001 17:38:01 -0400 To: Brian E Carpenter , Mark Duffy From: Mark Duffy Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Cc: Bob Penfield , midcom@ietf.org In-Reply-To: <3B3CF017.68CD084F@hursley.ibm.com> References: <200106141108.HAA24729@ietf.org> <3B3BA8A9.7ABCC46D@hursley.ibm.com> <004501c1008f$d194d580$2300000a@acmepacket.com> <3B3C8AF4.78EAA5B2@hursley.ibm.com> <006201c100ad$3e785420$2300000a@acmepacket.com> <3.0.5.32.20010629155927.007bc970@10.1.1.249> 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 At 04:16 PM 6/29/01 -0500, Brian E Carpenter wrote: >Mark Duffy wrote: >> >> >Diffserv doesn't have per-flow classifiers, so there is nothing a SIP >> >proxy can say for a single new flow. The policy system has to define a >> >classifier for each *type* of traffic, not for individual flows. This is >> >done globally per diffserv domain and is relatively static. >> > >> >The classifier will be given the appropriate classifier specifications >> >by the diffserv policy system. These are n-tuple specifications just >> >like any other. If you grok MIB they look like: >> > >> >DiffServSixTupleClfrEntry ::= SEQUENCE { >> > diffServSixTupleClfrId INTEGER, >> > diffServSixTupleClfrDstAddrType InetAddressType, >> > diffServSixTupleClfrDstAddr InetAddress, >> > diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength, >> > diffServSixTupleClfrSrcAddrType InetAddressType, >> > diffServSixTupleClfrSrcAddr InetAddress, >> > diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength, >> > diffServSixTupleClfrDscp DscpOrAny, >> > diffServSixTupleClfrProtocol Unsigned32, >> > diffServSixTupleClfrDstL4PortMin InetPortNumber, >> > diffServSixTupleClfrDstL4PortMax InetPortNumber, >> > diffServSixTupleClfrSrcL4PortMin InetPortNumber, >> > diffServSixTupleClfrSrcL4PortMax InetPortNumber, >> > diffServSixTupleClfrStatus RowStatus >> >} >> >> Yes, but since the flows of type 'SIP' come on dynamic ports, you can't >> readily match them using a classifier like that. > >There's nothing to prevent you defining a classifier that uses >some other n-tuple that does identify media traffic. What n-tuple would that be? In some cases local knowledge might allow the source or dest addresses to be used but in other scenarios it wouldn't. > >> However, a middlebox aka >> diffserv-domain-edge-traffic-conditioning-box that is aware of which flows >> are SIP could apply a *static* policy that says mark SIP packets (or >> perhaps, SIP packets to/from certain addresses) with a certain DSCP. And >> in the spirit of midcom, one would want the midcom agent to tell the >> middlebox about this flow (perhaps not what DSCP to use, but that it is SIP). > >It would all be much simpler if the source of the media stream marked its >own packets; then neither the proxy nor the middlebox need to worry about it. >That is in fact the simplest realisation of diffserv. I certainly agree with that. However, in cases where the source does not so mark, a carrier might like to identify the traffic and appropriately mark it on their subscriber's behalf, as a value-added service. This of course requires the carrier to somehow identify the appropriate flows. > >All this goes to show that it's a complex topic, beyond what I thought midcom >was intended for. > > Brian I don't really have the perspective to comment on what midcom was "intended for". Obviously, the charter is focused on firewall and NAT middleboxes. However the promise of midcom seems to be to allow middleboxes of many sorts to do whatever their particular purpose in life is, while offloading from them the need to understand every application in order to be aware of which flows are for which apps. This is certainly attractive from the perspective of classifying packets by *application* (and not just by protocol and port numbers). -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 18:14: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 SAA26250 for ; Fri, 29 Jun 2001 18:14:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28095; Fri, 29 Jun 2001 18:07:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28067 for ; Fri, 29 Jun 2001 18:07:18 -0400 (EDT) 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 SAA26155 for ; Fri, 29 Jun 2001 18:06:34 -0400 (EDT) Received: by exchange.2wire.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Jun 2001 15:10:02 -0700 Message-ID: <91CDB24C5FCDD31198A2009027E79021011BDB6F@exchange.2wire.com> From: Randy Turner To: "'Bob Penfield '" , "'Brian E Carpenter '" , "'Mark Duffy '" Cc: "'midcom@ietf.org '" Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 15:09:57 -0700 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 DiffServ *can* be end-to-end if endpoints and intermediaries follow the guidelines for the standard set of codepoints, as the relate to EF or AF forwarding. Randy -----Original Message----- From: Bob Penfield To: Brian E Carpenter; Mark Duffy Cc: midcom@ietf.org Sent: 6/29/01 2:42 PM Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt ----- Original Message ----- From: "Brian E Carpenter" To: "Mark Duffy" Cc: "Bob Penfield" ; Sent: Friday, June 29, 2001 5:16 PM Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > Mark Duffy wrote: > > > > >Diffserv doesn't have per-flow classifiers, so there is nothing a SIP > > >proxy can say for a single new flow. The policy system has to define a > > >classifier for each *type* of traffic, not for individual flows. This is > > >done globally per diffserv domain and is relatively static. > > > > > >The classifier will be given the appropriate classifier specifications > > >by the diffserv policy system. These are n-tuple specifications just > > >like any other. If you grok MIB they look like: > > > > > >DiffServSixTupleClfrEntry ::= SEQUENCE { > > > diffServSixTupleClfrId INTEGER, > > > diffServSixTupleClfrDstAddrType InetAddressType, > > > diffServSixTupleClfrDstAddr InetAddress, > > > diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength, > > > diffServSixTupleClfrSrcAddrType InetAddressType, > > > diffServSixTupleClfrSrcAddr InetAddress, > > > diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength, > > > diffServSixTupleClfrDscp DscpOrAny, > > > diffServSixTupleClfrProtocol Unsigned32, > > > diffServSixTupleClfrDstL4PortMin InetPortNumber, > > > diffServSixTupleClfrDstL4PortMax InetPortNumber, > > > diffServSixTupleClfrSrcL4PortMin InetPortNumber, > > > diffServSixTupleClfrSrcL4PortMax InetPortNumber, > > > diffServSixTupleClfrStatus RowStatus > > >} > > > > Yes, but since the flows of type 'SIP' come on dynamic ports, you can't > > readily match them using a classifier like that. > > There's nothing to prevent you defining a classifier that uses > some other n-tuple that does identify media traffic. > > > However, a middlebox aka > > diffserv-domain-edge-traffic-conditioning-box that is aware of which flows > > are SIP could apply a *static* policy that says mark SIP packets (or > > perhaps, SIP packets to/from certain addresses) with a certain DSCP. And > > in the spirit of midcom, one would want the midcom agent to tell the > > middlebox about this flow (perhaps not what DSCP to use, but that it is SIP). > > It would all be much simpler if the source of the media stream marked its > own packets; then neither the proxy nor the middlebox need to worry about it. > That is in fact the simplest realisation of diffserv. But diffserv is not end-to-end, right? If the flow is traversing several Autonomous Systems, won't each AS apply different QOS measures? The combination of a SIP proxy and a middlebox can constitute an ALG which is often implemented as what SIP calls a back-to-back user agent which terminates and re-generates the flow. In this case, the middlebox becomes the source of the media flow within the local AS. > > All this goes to show that it's a complex topic, beyond what I thought midcom > was intended for. > > Brian > _______________________________________________ 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 Jun 29 18:17: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 SAA26375 for ; Fri, 29 Jun 2001 18:17:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28367; Fri, 29 Jun 2001 18:14:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28338 for ; Fri, 29 Jun 2001 18:14:19 -0400 (EDT) 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 SAA26235 for ; Fri, 29 Jun 2001 18:13:36 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 1A3CB811B for ; Fri, 29 Jun 2001 16:27:45 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA18289 for ; Fri, 29 Jun 2001 17:14:18 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 29 Jun 2001 17:14:18 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] requirements-01 status 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, 29 Jun 2001, Christian Huitema wrote: > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > The middleboxes that I am talking about have no routing tables or > > routing capability. They sit on a pipe between two routers. Whatever > > comes in on one end of the pipe is sent out the other end. The routers > > take care of sending the packets down the right pipe. > > Uh? The thing that you describe has essentially no place in the Internet > architecture, and is probably out of scope for this WG. It may not have a place in the Internet architecture, and yet it exists, in many places. Wires, for example, have these properties. I suppose an approach to dealing with them would be to deny their existence, and if that failed, to deny their relevance. None of these approaches is useful. Clearly these devices exist, more will exist in the future, delivering more capabilities. Clearly it is desirable to standardise the way in which these devices are controlled, specifically to make IP telephony work in the real world on a large scale. If the IETF has no time, collectively, for these devices, perhaps you could direct me to a standards body which does, since I'd just like to get the work done without worrying about the purity of our architectures. By the way, when did the whole "rough consensus and running code" thing get replaced by "purity of blood above all, no goddamn wogs and their bloody stupid ideas" thing, anyways? > -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 18:25: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 SAA26473 for ; Fri, 29 Jun 2001 18:25:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28550; Fri, 29 Jun 2001 18:20:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28518 for ; Fri, 29 Jun 2001 18:20:28 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26404 for ; Fri, 29 Jun 2001 18:19:44 -0400 (EDT) Received: from 157.54.7.67 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 29 Jun 2001 14:47:53 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 29 Jun 2001 14:50:27 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 29 Jun 2001 14:50:24 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Jun 2001 14:49:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 14:49:41 -0700 Message-ID: Thread-Topic: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Thread-Index: AcEA5LebzfvPK1hZSHi7tbA+BFdTJgAAEi1A From: "Christian Huitema" To: "Mark Duffy" , "Brian E Carpenter" Cc: "Bob Penfield" , X-OriginalArrivalTime: 29 Jun 2001 21:49:41.0453 (UTC) FILETIME=[66C127D0:01C100E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA28519 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: 8bit > I don't really have the perspective to comment on what midcom was > "intended > for". Obviously, the charter is focused on firewall and NAT middleboxes. > However the promise of midcom seems to be to allow middleboxes of many > sorts to do whatever their particular purpose in life is, while offloading > from them the need to understand every application in order to be aware of > which flows are for which apps. This is certainly attractive from the > perspective of classifying packets by *application* (and not just by > protocol and port numbers). Please register a violent disagreement. Many of us see allowing "middleboxes of any sort" as a license to break the Internet in whatever ways may fit someone's business model. While the IETF has no business validating business models, its goal is certainly to develop a better Internet, not to break it. If the group had proposed a charter to "develop any kind of transparency breaking box in the middle of the network", then the charter would most probably not have been approved. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 18:35:26 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 SAA26594 for ; Fri, 29 Jun 2001 18:35:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29049; Fri, 29 Jun 2001 18:31:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29020 for ; Fri, 29 Jun 2001 18:31:04 -0400 (EDT) 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 SAA26534 for ; Fri, 29 Jun 2001 18:30:21 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 67D98811B for ; Fri, 29 Jun 2001 16:44:30 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA18889 for ; Fri, 29 Jun 2001 17:31:03 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 29 Jun 2001 17:31:03 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] requirements-01 status 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, 29 Jun 2001, Zmolek, Andrew (Andrew) wrote: > For the general case, I agree with Melinda that interface identification > doesn't belong in midcom, especially when it forces application agents > (assumed to be ignorant of the routing topology) to make interface > decisions. We don't want to force the tail to wag the dog. But adding a > 1-byte token might be useful for very simple toplogies with static > routing and simple agent configuration. Comments? On the one hand, adding 'interpreted any way you like' elements to a protocol sounds very spooky, on the other hand it seems useful. I'd like to see it, when the time comes to define it, wrapped up in language to the effect that: - the middlebox may define specific semantics for such and such an imeplentation defined cookie - the MIDCOM agent should not by design assume any specific semantics for that cookie - the MIDCOM agent may allow user specification of cookies (in some undefined way). The point being that the engineer who *builds* the MIDCOM Agent isn't allowed to assume anything about what such cookies do, but the user who *deploys* and Agent (presumably in concert with a specific middlebox) is allowed to assume semantics (presumably since the Brand X Middlebox implements them, and says so right in the manual). In short, I support the idea, and might well support other uses of it in other places, but with the caveat that it needs to be well fenced-in to prevent weird vendor lock-in scenarios. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 18:44: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 SAA26685 for ; Fri, 29 Jun 2001 18:44:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29249; Fri, 29 Jun 2001 18:40:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29222 for ; Fri, 29 Jun 2001 18:40:49 -0400 (EDT) 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 SAA26630 for ; Fri, 29 Jun 2001 18:40:06 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 73A1C81B9 for ; Fri, 29 Jun 2001 17:36:45 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA19058 for ; Fri, 29 Jun 2001 17:36:45 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 29 Jun 2001 17:36:45 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt 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, 29 Jun 2001, Christian Huitema wrote: > While the IETF has no business > validating business models, its goal is certainly to develop a better > Internet, not to break it. If the group had proposed a charter to > "develop any kind of transparency breaking box in the middle of the > network", then the charter would most probably not have been approved. Isn't "fits a lot of business models really well" at least one measure of "a better Internet?" Or did you mean specifically the business models of equipment vendors? I'm certainly not in favor of wiring standards to sell weird networking boxes. I am in favor of wiring standards to make the Internet more useful, regardless of the personal feelings and design dogma of any particular individual (and no, I refer to nobody in particular -- I too possess personal feelings and design dogma which I expect to be trampled in the pragmatic interests of the greater good from time to time.) Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 18:46: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 SAA26716 for ; Fri, 29 Jun 2001 18:46:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29364; Fri, 29 Jun 2001 18:42:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29333 for ; Fri, 29 Jun 2001 18:42:25 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26654 for ; Fri, 29 Jun 2001 18:41:41 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N7A4NR7N; Fri, 29 Jun 2001 18:41:51 -0400 Message-Id: <3.0.5.32.20010629183709.007b4d50@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 29 Jun 2001 18:37:09 -0400 To: "Christian Huitema" , "Mark Duffy" , "Brian E Carpenter" From: Mark Duffy Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Cc: "Bob Penfield" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:49 PM 6/29/01 -0700, Christian Huitema wrote: >> I don't really have the perspective to comment on what midcom was >> "intended >> for". Obviously, the charter is focused on firewall and NAT >middleboxes. >> However the promise of midcom seems to be to allow middleboxes of many >> sorts to do whatever their particular purpose in life is, while >offloading >> from them the need to understand every application in order to be >aware of >> which flows are for which apps. This is certainly attractive from the >> perspective of classifying packets by *application* (and not just by >> protocol and port numbers). > >Please register a violent disagreement. Many of us see allowing >"middleboxes of any sort" as a license to break the Internet in whatever >ways may fit someone's business model. While the IETF has no business >validating business models, its goal is certainly to develop a better >Internet, not to break it. If the group had proposed a charter to >"develop any kind of transparency breaking box in the middle of the >network", then the charter would most probably not have been approved. > >-- Christian Huitema Christian, Although you have placed the words in quotes, you will notice above that I didn't say middleboxes of *any* sort but rather middleboxes of *many* sorts. And the larger context of my message was about a middlebox function that would be entirely transparent except to the Diffserv codepoint, which it might mark. In fact, it is a central principle of Diffserv for DSCPs to be remarked in the network, not passed transparently end to end. If you'd like to disagree with that, fine. But please do not manufacture positions I have not expressed and then disagree with them. :-) Regards, Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 18:48:21 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 SAA26738 for ; Fri, 29 Jun 2001 18:48:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29312; Fri, 29 Jun 2001 18:41:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29281 for ; Fri, 29 Jun 2001 18:41:57 -0400 (EDT) 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 SAA26651 for ; Fri, 29 Jun 2001 18:41:14 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 0CB608107 for ; Fri, 29 Jun 2001 16:55:23 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA19186 for ; Fri, 29 Jun 2001 17:41:56 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 29 Jun 2001 17:41:56 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt In-Reply-To: <3B3CF017.68CD084F@hursley.ibm.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, 29 Jun 2001, Brian E Carpenter wrote: > [ re: diffserv Stuff ] > There's nothing to prevent you defining a classifier that uses > some other n-tuple that does identify media traffic. I could be wrong on this, but I am pretty sure that it is impossible to identify a UDP packet as RTP, if all you have is the packet. There are probably some heuristics you could apply ("pretty small, big port numbers, destination even, a couple of magic numbers at this offset and that") which might be enough, but isn't certain. I personally am happy to allow QoS features to fall under the aegis of "future extensions of the extensible MIDCOM protocol" and worry about them later. Of course, if MIDCOM is accidentally designed to make THAT extension impossible, that would be bad. I think we have enough eyes on the ball to prevent that. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jun 29 19:19: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 TAA27090 for ; Fri, 29 Jun 2001 19:19:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00425; Fri, 29 Jun 2001 19:15:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00397 for ; Fri, 29 Jun 2001 19:15:08 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26989 for ; Fri, 29 Jun 2001 19:14:25 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5TFfs003555 for ; Fri, 29 Jun 2001 11:41:54 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 29 Jun 2001 11:41:47 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 11:41:50 -0400 Message-ID: From: "Fernando Cuervo" To: "'Brian E Carpenter'" , Bob Penfield Cc: midcom@ietf.org Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Fri, 29 Jun 2001 11:41:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C100B2.01523CF0" X-Orig: 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_001_01C100B2.01523CF0 Content-Type: text/plain What is important to keep in mind is that it is possible that a border device may provide QoS marking, NAT and pin-hole "services" and that this combination is actually a useful one. Therefore, if a single protocol can realise this service behaviour between the agent and the middlebox then that would simplify the interface. The protocol would then be COPS or something like RSVP where a service requirement is specified in conjunction with policy objects. Fernando Cuervo > -----Original Message----- > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > Sent: Friday, June 29, 2001 10:05 AM > To: Bob Penfield > Cc: midcom@ietf.org > Subject: Re: [midcom] Re: I-D > ACTION:draft-ietf-midcom-framework-02.txt > > Bob Penfield wrote: > > > > ----- Original Message ----- > > From: "Brian E Carpenter" > > To: > > Sent: Thursday, June 28, 2001 5:59 PM > > Subject: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > > > > > I'm a bit puzzled by the isolated reference to Diffserv > > > sitting in the middle of Figure 1, and the very brief mention > > > at the beginning of the Introduction. While it is true that > > > one possible location for diffserv classification and shaping > > > is in a border router which is also a NAT and/or firewall, > > > it can be done in any router or in hosts. And it has its > > > own policy distribution mechanisms (COPS, SNMPCONF). > > > So I would recommend removing the two brief references. > > > I don't see why diffserv would be a midcom issue. > > > > Being able to set the DS code point is definitely something that > > applications are going to want to do. For example, a SIP proxy acting as > a > > midcom agent talking to a middlebox at the border between networks will > need > > to instruct the middlebox to set the DSCP in the RTP packets that will > flow > > thru the middlebox. The RTP packets will not flow thru the SIP > proxy/midcom > > agent. The middlebox is the only place the application will be able to > > affect QoS for the data flows. > > No, wrong model. The border device (whether it is the midcom version of > a middlebox, or any old router) will apply diffserv classification and > marking according to policy delivered from the diffserv policy server > (a.k.a. PDP) by COPS or SNMPCONF. That is the diffserv management > model; there is no need for the SIP proxy to enter the picture. > > Brian > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C100B2.01523CF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: I-D = ACTION:draft-ietf-midcom-framework-02.txt

What is important to = keep in mind is that it is possible that a border
device may provide = QoS marking, NAT and pin-hole "services" and
that this = combination is actually a useful one. Therefore, if a single = protocol
can realise this = service behaviour between the agent and the middlebox
then that would = simplify the interface. The protocol would then be COPS or
something like RSVP = where a service requirement is specified in conjunction
with  policy = objects.

Fernando = Cuervo

    -----Original Message-----
    From:   Brian E Carpenter = [SMTP:brian@hursley.ibm.com]
    Sent:   Friday, June 29, 2001 10:05 AM
    To:     Bob Penfield
    Cc:     midcom@ietf.org
    Subject:       = Re: [midcom] Re: I-D = ACTION:draft-ietf-midcom-framework-02.txt

    Bob Penfield wrote:
    >
    > ----- Original Message = -----
    > From: "Brian E = Carpenter" <brian@hursley.ibm.com>
    > To: = <midcom@ietf.org>
    > Sent: Thursday, June 28, 2001 = 5:59 PM
    > Subject: [midcom] Re: I-D = ACTION:draft-ietf-midcom-framework-02.txt
    >
    > > I'm a bit puzzled by the = isolated reference to Diffserv
    > > sitting in the middle of = Figure 1, and the very brief mention
    > > at the beginning of the = Introduction. While it is true that
    > > one possible location for = diffserv classification and shaping
    > > is in a border router which = is also a NAT and/or firewall,
    > > it can be done in any = router or in hosts. And it has its
    > > own policy distribution = mechanisms (COPS, SNMPCONF).
    > > So I would recommend = removing the two brief references.
    > > I don't see why diffserv = would be a midcom issue.
    >
    > Being able to set the DS code = point is definitely something that
    > applications are going to want = to do. For example, a SIP proxy acting as a
    > midcom agent talking to a = middlebox at the border between networks will need
    > to instruct the middlebox to set = the DSCP in the RTP packets that will flow
    > thru the middlebox. The RTP = packets will not flow thru the SIP proxy/midcom
    > agent. The middlebox is the only = place the application will be able to
    > affect QoS for the data = flows.

    No, wrong model. The border device = (whether it is the midcom version of
    a middlebox, or any old router) will = apply diffserv classification and
    marking according to policy delivered = from the diffserv policy server
    (a.k.a. PDP) by COPS or SNMPCONF. = That is the diffserv management
    model; there is no need for the SIP = proxy to enter the picture.

      Brian

    _______________________________________________
    midcom mailing list
    midcom@ietf.org
    http://www.ietf.org/mailman/listinfo/midcom=

------_=_NextPart_001_01C100B2.01523CF0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jun 30 08:18: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 IAA21919 for ; Sat, 30 Jun 2001 08:18:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28099; Sat, 30 Jun 2001 08:10:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28071 for ; Sat, 30 Jun 2001 08:10:38 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21773 for ; Sat, 30 Jun 2001 08:09:50 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5UCA9x01658; Sat, 30 Jun 2001 05:10:09 -0700 (PDT) Received: from spandex (rtp-vpn-121.cisco.com [10.82.192.121]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AMC01506; Sat, 30 Jun 2001 05:10:00 -0700 (PDT) Message-ID: <004301c1015d$bac762e0$d45904d1@cisco.com> From: "Melinda Shore" To: "Andrew Molitor" , References: Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Sat, 30 Jun 2001 08:11:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > From: Andrew Molitor > To: > Sent: Friday, June 29, 2001 6:36 PM > Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > Isn't "fits a lot of business models really well" at least > one measure of "a better Internet?" No, actually (unless your definition of "better Internet" diverges from existing architecture). A lot of business models assume (or require) that the edge of the network is visible. Midcom is premised on the assumption that the means to make the edge visible will continue to be used but that we can restore some end-to-end function by allowing applications to explicitly influence the behavior of the middlebox. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom