From midcom-admin@ietf.org Sun Apr 1 15:45: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 PAA23912 for ; Sun, 1 Apr 2001 15:45: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 PAA26991; Sun, 1 Apr 2001 15:39: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 PAA26960 for ; Sun, 1 Apr 2001 15:39:04 -0400 (EDT) Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23200 for ; Sun, 1 Apr 2001 15:39:02 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id MAA05992; Sun, 1 Apr 2001 12:37:16 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn-303.cisco.com [10.21.65.47]) by airborne.cisco.com (Mirapoint) with ESMTP id AAA02281; Sun, 1 Apr 2001 12:38:30 -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: <15047.33715.405000.200659@gargle.gargle.HOWL> Date: Sun, 1 Apr 2001 14:38:27 -0500 To: Andrew Molitor Cc: midcom@ietf.org Subject: Streaming (was [midcom] Protocol Requirements -) In-Reply-To: References: <15044.60280.832000.612953@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 30 Mar 2001 at 15:18 -0600, Andrew Molitor apparently wrote: > > What are you expecting to carry in this protocol that you would want > > message streaming? I think of it as a small-message control protocol. > > I am thinking of cases in which a SIP proxy wants to control > a middlebox that is many many milliseconds away. If the middlebox is > N milliseconds away, and you want to do NAT and firewalling, you are > optimistically limited to 1000 / (8 * N) calls per second in the > absence of streaming > > (4 messages at 2*N millseconds round trip = 8*N milliseconds/call) > > which is really low for N bigger than about 4 or 5. If the control protocol is simple and UDP-based, then you won't have to wait for acknowledgements either. I like just saying that you want to execute many control transactions per second at a distance. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 02:51: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 CAA26891 for ; Mon, 2 Apr 2001 02:51: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 CAA10799; Mon, 2 Apr 2001 02:42: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 CAA10770 for ; Mon, 2 Apr 2001 02:42:48 -0400 (EDT) Received: from redball.dynamicsoft.com ([216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25695 for ; Mon, 2 Apr 2001 02:42:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA11000; Mon, 2 Apr 2001 02:46:12 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 02:42:46 -0400 Message-ID: From: Jonathan Rosenberg To: "'Andrew Molitor'" , midcom@ietf.org Subject: RE: [midcom] SIP MIDCOM flow... Date: Mon, 2 Apr 2001 02:42:42 -0400 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 > -----Original Message----- > From: Andrew Molitor [mailto:amolitor@visi.com] > Sent: Friday, March 30, 2001 5:53 PM > To: midcom@ietf.org > Subject: RE: [midcom] SIP MIDCOM flow... > > > > > On Fri, 30 Mar 2001, Christopher A. Martin wrote: > > > I am actually performing two functions above. I am > considering intiate and > > terminate to be the process for opening and closing > communications between > > controller and middlebox (with authentication, and perhaps > > intiating/terminating an encrypted path), and open/close > hole as the action > > request and verification. > > > > I probably need to tie midcom terminology into this call flow. > > Goodness! With this definition of Initiate and Terminate, I > cannot imagine why they're tied in to a call flow. Surely these are > separate operations which happen entirely outside the call processing > path? I suppose you COULD re-authenticate for every call, but why on > earth would you want to? To be honest, this whole discussion is entirely futile without having definitions of what midcom operations are needed, at what points in time, BEFORE assinging names to the messages. It would also be helpful to consider separately the cases of NAT and firewall, and of calls from inside to outside and outside to inside. Without that, we end up having more debates on what INITIATE or TERMINATE mean. I think we have enough debates about names in this group. So, in the case of NAT only, and a call from the outside to inside: Once the INVITE arrives at the proxy from the outside, the proxy needs to talk to the midcom box. Lets say the SDP in the INVITE are for IP address X, port Y. The proxy needs to request a binding, say address A, port B, such that UDP packets that arrive from the INSIDE at the middlebox destined for {A,B} have their destination address translated to {X,Y} and are then forwarded OUTSIDE. We can call this "initiate" or "bind request", or whatever. However, the requirement is that the protocol have such an operation as a primitive. The input to the operation is X and Y, and the output is success or fail, along with the resulting binding, A,B. We need to invoke this operation upon receipt of the INVITE at the proxy. Now, when the 200 OK arrives at the proxy, the proxy needs to translate the IP address in the SDP, since its wrong. So, it needs to do another bind request. In this case, it needs to present the middlebox with an internal address and port {C,D}, and request a public address on the outside of the NAT, {U,V}, so that packets that arrive on the outside destined for {U,V} have their IP address/port rewritten to {C,D}, and are forwarded towards the inside. The proxy updates the SDP with {U,V}, and forwards the 200 OK upstream. I think we need to get to this level of detail, or we are going to continue to talk past each other. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 02: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 CAA28037 for ; Mon, 2 Apr 2001 02: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 CAA10891; Mon, 2 Apr 2001 02:52: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 CAA10860 for ; Mon, 2 Apr 2001 02:51:58 -0400 (EDT) Received: from redball.dynamicsoft.com ([216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27053 for ; Mon, 2 Apr 2001 02:51:58 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA11031; Mon, 2 Apr 2001 02:55:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 02:51:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'Shai Mohaban'" , Andrew Molitor , midcom@ietf.org Subject: RE: [midcom] Protocol Requirements Bullet List v2.0 Date: Mon, 2 Apr 2001 02:51:49 -0400 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 > -----Original Message----- > From: Shai Mohaban [mailto:shai@kagoor.com] > Sent: Friday, March 30, 2001 5:08 PM > To: Andrew Molitor; midcom@ietf.org > Subject: RE: [midcom] Protocol Requirements Bullet List v2.0 > > - Besides packet/flow dropping and network address > translation few examples > of other MidBox primitives include transcoding, encryption > and IPv4-IPv6 > translations. I am sure there are many others. Definitely. However, we need to focus on NAT and firewall. Anything else is covered by the "protocol should be extensible to other middlebox functions" requirement. > - According to section 3.4 the default behavior of the MidBox > is not to let > packets pass through it. I think this default behavior should be > configurable (and policy driven) as the requirement may be > different for > different applications. E.g. in case of a QoS MidBox I think > this will not > be the default behavior. There are monsters lurking in this requirement. Big, scary, monsters. They have to do with the very important requirement, IMHO, that multiple midcom controllers (aka clients, agents, whatever. Client is simplest for me) be able to make use of the same middlebox. If you want to ever have load balancing across proxies, this is an absolute requirement. Once you do this, you run into the interesting problem of resolving overlapping or conflicting requests. It so happens, that if the default operation of the firewall is "deny", and the only firewall operation possible is "open", then there are no conflicts, in fact. You can construct a global set of rules for the firewall which meet the requests made by all midcom clients. However, as soon as the default operation is no longer "deny", but rather, "pass everything", this means you need midcom operations like "disallow packets from A to B". Now, you can no longer construct a set of rules for the firewall which meet requests made by all midcom clients. This leads you to prioritization, confict management, rule merging, and all kinds of assorted headaches that we may not want to have. I believe that the task before us is quite formidable even in its simplest formulation. Clear evidence of this is that, even after nearly a year of discussion, we are still not in agreement on framework and terminology. So, to finish this side of 2010, I would propose we keep things simple. Lets first solve the problem of default-deny firewalls, and nats, and thats it. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 08:49: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 IAA05842 for ; Mon, 2 Apr 2001 08:49: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 IAA15799; Mon, 2 Apr 2001 08:41: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 IAA15770 for ; Mon, 2 Apr 2001 08:41:31 -0400 (EDT) Received: from acmepacket.com ([63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05405 for ; Mon, 2 Apr 2001 08:41:28 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A331BE00F2; Mon, 02 Apr 2001 08:40:17 -0400 Message-ID: <004c01c0bb72$9148b120$3700000a@acmepacket.com> From: "Bob Penfield" To: "Andrew Molitor" , "midcom mail-list" References: Subject: Re: [midcom] SIP MIDCOM flow... Date: Mon, 2 Apr 2001 08:43:50 -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 that initiation and termination of communication between the middlebox controller (SIP Proxy in this case) and the Middlebox should not be in a call flow. Some SIP Proxies be requesting NATs or FW holes for hundreds of calls per second. However, for SIP requesting a NAT, the proxy will need to obtain the NAT binding before forwarding the INVITE because the IP address and port in the SDP must be modified. ----- Original Message ----- From: "Andrew Molitor" To: Sent: Friday, March 30, 2001 5:53 PM Subject: RE: [midcom] SIP MIDCOM flow... > > > On Fri, 30 Mar 2001, Christopher A. Martin wrote: > > > I am actually performing two functions above. I am considering intiate and > > terminate to be the process for opening and closing communications between > > controller and middlebox (with authentication, and perhaps > > intiating/terminating an encrypted path), and open/close hole as the action > > request and verification. > > > > I probably need to tie midcom terminology into this call flow. > > Goodness! With this definition of Initiate and Terminate, I > cannot imagine why they're tied in to a call flow. Surely these are > separate operations which happen entirely outside the call processing > path? I suppose you COULD re-authenticate for every call, but why on > earth would you want to? > > I think the authentication transaction, and the corresponding > "log out" transaction should be completely decoupled from pinholes and > stuff. Obviously a Client (or Controller) may elect to do them as > indicated, but anything wishing to Go Fast will surely tend to > authenticate fairly infrequently. > > I realize that these call flows are just intended as sort of > typical applications, but I think it's unrealistic to indicate > the Initiate and Terminate transactions this closely. If I were > drawing the flows, I'd have an Initiate transaction first, and then > an indication of 'some amount of time passes' and then the call setup > and the call teardown and then another 'some amount of time passes' > followed by the Terminate. > > Somewhat related, are there standard words for this? Surely the > IPSEC people invented some words for this sort of thing? In the > absence of other words, I would suggest Authenticate and Logout, or > Connect and Disconnect, or something. These words are probably as > meaningless to others as Initiate and Terminate are to me, though. > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 10:44: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 KAA12627 for ; Mon, 2 Apr 2001 10:44: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 KAA18215; Mon, 2 Apr 2001 10:35: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 KAA18184 for ; Mon, 2 Apr 2001 10:35:11 -0400 (EDT) Received: from kachifo.cc.columbia.edu (kachifo.cc.columbia.edu [128.59.59.172]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12168 for ; Mon, 2 Apr 2001 10:35:12 -0400 (EDT) Received: from fokus.gmd.de (dynamic-86-233.dyn.columbia.edu [128.59.86.233]) by kachifo.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA21319 for ; Mon, 2 Apr 2001 10:35:13 -0400 (EDT) Message-ID: <3AC85F32.6C4489EC@fokus.gmd.de> Date: Mon, 02 Apr 2001 13:14:58 +0200 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] [Fwd: RFC 3093 on Firewall Enhancement Protocol] Sender: 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 attached RFC seems to be of tremendous relevance to midcom. Jiri RFC Editor wrote: > > A new Request for Comments is now available in online RFC libraries. > > RFC 3093 > > Title: Firewall Enhancement Protocol (FEP) > Author(s): M. Gaynor, S. Bradner > Status: Informational > Date: 1 April 2001 > Mailbox: gaynor@eecs.harvard.edu, sob@harvard.edu > Pages: 11 > Characters: 22405 > Updates/Obsoletes/SeeAlso: None > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3093.txt > > Internet Transparency via the end-to-end architecture of the Internet > has allowed vast innovation of new technologies and services [1]. > However, recent developments in Firewall technology have altered this > model and have been shown to inhibit innovation. We propose the > Firewall Enhancement Protocol (FEP) to allow innovation, without > violating the security model of a Firewall. With no cooperation from > a firewall operator, the FEP allows ANY application to traverse a > Firewall. Our methodology is to layer any application layer > Transmission Control Protocol/User Datagram Protocol (TCP/UDP) packets > over the HyperText Transfer Protocol (HTTP) protocol, since HTTP > packets are typically able to transit Firewalls. This scheme does not > violate the actual security usefulness of a Firewall, since Firewalls > are designed to thwart attacks from the outside and to ignore threats > from within. The use of FEP is compatible with the current Firewall > security model because it requires cooperation from a host inside the > Firewall. FEP allows the best of both worlds: the security of a > firewall, and transparent tunneling thought the firewall. > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 13:44: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 NAA22899 for ; Mon, 2 Apr 2001 13:44: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 NAA21454; Mon, 2 Apr 2001 13:35: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 NAA21423 for ; Mon, 2 Apr 2001 13:35:26 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22549 for ; Mon, 2 Apr 2001 13:35:27 -0400 (EDT) Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 2 Apr 2001 13:09:21 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2AWW3QNY; Mon, 2 Apr 2001 13:09:22 -0400 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2A9368QD; Mon, 2 Apr 2001 13:09:21 -0400 Message-ID: <3AC8B31F.CBDCB7AC@americasm01.nt.com> Date: Mon, 02 Apr 2001 13:13:03 -0400 From: "Abdallah Rayhan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Molitor CC: midcom@ietf.org Subject: Re: [midcom] Protocol Requirements Bullet List v2.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit See comments below. Andrew Molitor wrote: > Throughout, I use this terminology: > > Client - something that requests pinholes and NAT bindings. For > example, a MIDCOM aware ALG or SIP proxy. > > Server - something which is spoken to by a client. By implication, > a Server resides in (logically, if not literally) a > Middlebox, and exposes the services of that Middlebox > to Clients. > > Middlebox - a firewall or NAT device which is coupled to a > MIDCOM server, which offers the firewall/NAT services > to Clients. I dont understand the need for the distinction between the server and the middlebox in view of the functionality described above. If the middlebox is considered to be a policy enforcement point (PEP) and the it is usually controlled by a policy server which is the policy decision point (PDP). The middlebox may require to outsource decisions to its policy server which is in alignment with the policy framework. However, introducing a new server will add no value and crumble the PEP-PDP relationship. Furthermore, the server-middlebox will require defining a new interface between them which is something already being done in the policy framework. I believe that the client should talk to the middlebox and the middlebox talks to the policy server when it needs to. If the objective of the above terminology is to utilize the client-server concepts into the midcom architecture then it might be better to say that the middlebox implements the server side of the midcom protocol rather than introducing a new logical/physical device. > Do we want to require a 1-to-1 relationship between Servers > and Middleboxes? In view of what I said before, outside the scope of the WG. > Protocol requirements in no particular order: > > General Stuff > ============= > * - must support low-latency, high-throughput operation, with > * best effort to maintain low latency in the face of a lossy network. > * This is necessary for telecom grade operations -- backoff > * policies in retransmit timers are not necessarily a good idea > * on controlled channels controlling equipment. (This boils > * down to: TCP Considered Harmful -- in rather specific > * environments.) I believe that the kind of protocol we are looking at is an application protocol as we are not to solve a transport problem here. So, I recommend separating the requirements into the protocol requirements describing the functionality and transport requirements for the transport performance issues. There are protocols like SCTP which is designed for performance in telecom like scenarios but that should not mean rolling out TCP. > * > * - must also support more ordinary network traffic models for > * use on standard networks where backoff policies for retransmit > * timers, and the like, are a good ideas. (This boils down to: > * TCP is a hell of a good idea most of the time.) > * > * [ I think the first bullet above pretty much requires UDP > * transport with wicked timers, but if there's another option > * I'd be pleased to hear about it. The situation I am thinking > * of is: some goober in a POP unplugs the wrong cable for > * a moment, or there is some other glitch in connectivity. > * It would Be Bad if this glitch made TCP back off and make > * the POP unable to complete calls for, say, 2 or 3 seconds > * AFTER connectivity is restored. This could readily create > * irritating post-dial delays for several hundred customers > * over the next 10 seconds while the queue clears. This is the > * sort of thing that gives telecom geeks nightmares. ] > > - should be transport independent, a la SIP. > > - must support high transaction throughput over highish > latency networks (read: must support message streaming.) High transaction of the middlebox, the transport, the client, or the protocol itself. Remove high. > - must support one or more strong authentication models. Most firewall if not all implement IPSec. What is the meaning of requiring more? > > * - must support one or more privacy models. See the above comment. > - must support client-to-server request/response transactions. > * - must support server-to-client "alerts" (unacknowledged messages) > * > * - should support an acknowledged server-to-client messaging > * model as well? > > - must support models in which multiple clients talk to > multiple servers. Is this an architectural or protocol issue? > Specific Operations/Scenarios > > Note that these are protocol requirements, not box > requirements. So, while the protocol must support the ability > of a client to ask for a pinhole, the protocol also allows > for a middlebox to return 'NO - I am a NAT, dummy.' > > * - must support a client-to-server transaction which returns > * the middlebox capabilities to the client. These capabilities > * must include, but not be restricted to: > * - firewalling > * - NAT > * - NAT capabilities (ports and stuff) > * - Plumbing information (where does NAT fit > * relative to other elements, specifically, > * THIS MATTERS!) I dont believe that it should be the case. The capabilities your refer to are provisioning issues which are outside the scope. The client should be able to know ahead of time what services a middlebox supports and if makes a wrong request, then the result should be service not supported and not this is what I support. Pluming information! What is that? > * > * and should include: > * - QoS > * - QoS flavor(s) > * [ can someone help out with what one might want to say > * if one WERE a QoS capable middlebox? Is this far enough > * out of scope to just leave QoS out entirely, burying it > * in the 'but not be restricted to' part above? ] There are other means of doing QoS and the middlebox protocol is and should not be one of them. > - must support a client-to-server transaction to open a > "pinhole" in the middlebox's traffic policy. > > - must support a client-to-server transaction to request > a NAT binding, associating an IP address/port pair on > one interface with an IP address/port pair on another. > > - it would sure be nice if these binding requests could > specify information about the expected source of the > flow initiator. E.G. 'I have a server on the inside > at 192.168.1.99 port 5000, and I think someone on the > outside at address 209.46.41.61, I don't know the port' > will be connecting to my server -- please give me an > address/port I can advertise to the remote as the phone's > address/port' You might want to call it late port binding feature and along the same thought late ip binding. A mechanism might be needed in this case to ensure the authenticity of the binding like a token sent to the target and returned to the source to authenticate the binding accordingly. > * - must support means for clients to manage redundant middlebox > * configurations. This means that it must be possible for a > * client or clients to: > * - apply the same NAT binding across multiple (NAT capable) > * middleboxes. > * - apply the same pinhole across multiple (pinhole capable) > * middleboxes (this is actually trivial and impossible > * to NOT get right -- included for completeness) > * > * [ these two boil down to: client can keep a primary > * and a spare middlebox in synch ] Middlebox synchronization is a client issue and not a protocol nor a middlebox requirement. Leave it out. > * > * - bring a new middlebox into synch with a set of > * synchronized redundant middleboxes. > * > * [ this boils down to: a client can bring a formerly > * dead primary middlebox back into service after repairs, > * without bringing the network down.] Out. > > - must support a client-to-server transaction to release an > individual NAT binding. > > - must support a client-to-server transaction to release an > individual pinhole. > > - should support a way to identify bundles of state (pinholes > and NAT) as belonging to the same group (a "session ID" > specified by the client in a set of requests) I propose using the concept of service which could encompass a number of functions like pinhole and NAT rather than session ID which could be confused with transport and registration. > - should support a client-to-server transaction to delete all > the state bundled under a given session ID. > > * - should support a way to re-session-ID a bundle. That is, > * there should be a client-to-server transaction in which > * the client asks the middlebox to take all the stuff with > * session ID "A" and re-file it under session ID "B" > * > * [ this is a surprisingly useful operation but the uses of it > * that I know of might be proprietary so I shan't describe them. > * There are people reading who know whether they are or are not > * proprietary, so if there is curiosity, hopefully explanations > * will be forthcoming. Sorry to be so mysterious. ] MEGACO utilizes a nice connection model which allows such operations to take a place. It is very useful and I believe that it would be more productive if we apply the same concepts here. > > - must support a way to specify a desired timeout value for > and piece of state created by a client-to-server transaction. > > - should support both activity based timeouts as well as > absolute timeouts (i.e. support both 'if you don't see any > packets for 60 seconds, please make this NAT binding go > away by itself' AND 'make this NAT binding go away in 60 > seconds') > > - must support client-to-server transactions to query middlebox > state, including but not restricted to: > > - currently installed pinholes > - currently installed NAT bindings > - statistics of various sorts MEGACO provides a complete set of queries. I recommend borrowing from its requirements draft. > - should support a client-to-server transaction allowing the > client to register to receive notifications of various > sorts from the server. > > - should support some server-to-client transactions to inform > the client of events such as: > > - timeouts of pinholes and NATs > - violations of policy > - other? > regards Abdallah _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 13:46: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 NAA22974 for ; Mon, 2 Apr 2001 13:46: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 NAA21494; Mon, 2 Apr 2001 13:35: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 NAA21466 for ; Mon, 2 Apr 2001 13:35:48 -0400 (EDT) Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22558 for ; Mon, 2 Apr 2001 13:35:50 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id E24CF811F for ; Mon, 2 Apr 2001 12:33:52 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id MAA02081 for ; Mon, 2 Apr 2001 12:36:02 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 2 Apr 2001 12:36:02 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] [Fwd: RFC 3093 on Firewall Enhancement Protocol] In-Reply-To: <3AC85F32.6C4489EC@fokus.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Mon, 2 Apr 2001, Jiri Kuthan wrote: > The attached RFC seems to be of tremendous relevance to midcom. > > Jiri > > RFC Editor wrote: > > > > A new Request for Comments is now available in online RFC libraries. > > > > RFC 3093 This would be a lot funnier if IP over SMTP hadn't actually been implemented, for essentially the reasons indicated, albeit in a much simpler way. As biting satire, it's pretty effective, if slightly spooky ;) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 14:26: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 OAA24748 for ; Mon, 2 Apr 2001 14:26: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 OAA22054; Mon, 2 Apr 2001 14:21:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22025 for ; Mon, 2 Apr 2001 14:21:28 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24436 for ; Mon, 2 Apr 2001 14:21:29 -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 LAA71606; Mon, 2 Apr 2001 11:20:51 -0700 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA25234; Mon, 2 Apr 2001 11:20:58 -0700 Message-ID: <3AC8C224.BF06D388@hursley.ibm.com> Date: Mon, 02 Apr 2001 13:17:08 -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: Andrew Molitor CC: midcom@ietf.org Subject: Re: [midcom] [Fwd: RFC 3093 on Firewall Enhancement Protocol] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Andrew Molitor wrote: > > On Mon, 2 Apr 2001, Jiri Kuthan wrote: > > > The attached RFC seems to be of tremendous relevance to midcom. > > > > Jiri > > > > RFC Editor wrote: > > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 3093 > > This would be a lot funnier if IP over SMTP hadn't actually > been implemented, for essentially the reasons indicated, albeit in a > much simpler way. As biting satire, it's pretty effective, if slightly > spooky ;) So has IP over HTTP. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 14:35: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 OAA25235 for ; Mon, 2 Apr 2001 14:35: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 OAA22137; Mon, 2 Apr 2001 14:28: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 OAA22104 for ; Mon, 2 Apr 2001 14:28:00 -0400 (EDT) Received: from df-inet1.exchange.microsoft.com ([131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24815 for ; Mon, 2 Apr 2001 14:28:00 -0400 (EDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 2 Apr 2001 11:24:20 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Apr 2001 10:24:35 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 2 Apr 2001 11:24:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4678.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] [Fwd: RFC 3093 on Firewall Enhancement Protocol] Date: Mon, 2 Apr 2001 11:24:34 -0700 Message-ID: Thread-Topic: [midcom] [Fwd: RFC 3093 on Firewall Enhancement Protocol] Thread-Index: AcC7oFgAA+l+HLPfT/m8Vbq3WHm6HgAAJyaA From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 02 Apr 2001 18:24:35.0546 (UTC) FILETIME=[2B82C3A0:01C0BBA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA22105 Sender: 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: Andrew Molitor [mailto:amolitor@visi.com] > > On Mon, 2 Apr 2001, Jiri Kuthan wrote: > > > The attached RFC seems to be of tremendous relevance to midcom. > > > > Jiri > > > > RFC Editor wrote: > > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 3093 > > This would be a lot funnier if IP over SMTP hadn't actually > been implemented, for essentially the reasons indicated, albeit in a > much simpler way. As biting satire, it's pretty effective, if slightly > spooky ;) There are quite a few solutions for the enterprising hacker: * PPP over telnet, which is low-tech but solid, * IP over SSL, which makes a sturdier VPN than IP over IPSEC, * IP over DNS, which gains a lot of points for creativity. In fact, the real firewall killer will probably be the wideband wireless modem; phone sweeps are going to be very interesting if the phone numbers are picked out of the general number space. This should drive home a point about firewall: they only work if the protected users cooperate. And users would be much more likely to cooperate if there was an organized way to cross the wall when needed... -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 14:54: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 OAA26107 for ; Mon, 2 Apr 2001 14:54: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 OAA22507; Mon, 2 Apr 2001 14:46: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 OAA22478 for ; Mon, 2 Apr 2001 14:46:27 -0400 (EDT) Received: from corb.mc.mpls.visi.com ([208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25797 for ; Mon, 2 Apr 2001 14:46:28 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id A43808112 for ; Mon, 2 Apr 2001 13:44:24 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id NAA06796 for ; Mon, 2 Apr 2001 13:46:41 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 2 Apr 2001 13:46:41 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Protocol Requirements Bullet List v2.0 In-Reply-To: <3AC8B31F.CBDCB7AC@americasm01.nt.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, 2 Apr 2001, Abdallah Rayhan wrote: > See comments below. > > Andrew Molitor wrote: > [ regarding Andrew's fondness for splitting the notion of a Server > off from the notion of a Middlebox ] > I addressed this very worthy criticism in another note to someone else earlier. In summary, I agree that a middlebox is essentially a monolithic Thing, but I felt it useful to separate its 'talking to Clients' aspect from its 'doing NAT to packets' aspect. Since I seem to be the only person who likes this distinction, I will have a bash at re-writing things with a more monolithic view, to see if it works. If it does not, I will report to the list, and if it does, I will leave it monolithic. > > [ transport must support high telecom performance requirements ] > > I believe that the kind of protocol we are looking at is an application > protocol as we are not to solve a transport problem here. So, I recommend > separating the requirements into the protocol requirements describing > the functionality and transport requirements for the transport performance > issues. There are protocols like SCTP which is designed for performance > in telecom like scenarios but that should not mean rolling out TCP. Are you happy with my transport requirements, but unhappy with the organisation of them? I'd be happy to stipulate that transport requirements and protocol requirements should be split. Right now I am just hashing a randomly ordered bullet list. If you meant something else, please clarify! > > - must support high transaction throughput over highish > > latency networks (read: must support message streaming.) > > High transaction of the middlebox, the transport, the client, or the > protocol itself. Remove high. I don't understand this. If I have an excess 'high' in there, my brain refuses to see it (which in no way implies that there isn't one -- we all know how our brain locks up on these things sometimes!) > > - must support one or more strong authentication models. > > Most firewall if not all implement IPSec. What is the meaning of > requiring more? > > > > > * - must support one or more privacy models. > > See the above comment. IPSec is a wonderful thing, but it's unfair to assume that all clients will speak it, or that all clients will speak it in a manner that is currently interoperable with the middleboxes. I confess that I haven't followed IPSec that closely, recently. Does it really solve the application-to-application problem? I thought it focuses more on host-to-host and net-to-net. Anyways, it would be fine with me if MIDCOM wound up stating that IPSec or TLS or something was a requirement to meet these needs of the protocol. The point is, the protocol needs authentication and privacy -- where they come from is a problem to be solved soon, but not right now! > > - must support client-to-server request/response transactions. > > > * - must support server-to-client "alerts" (unacknowledged messages) > > * > > * - should support an acknowledged server-to-client messaging > > * model as well? > > > > - must support models in which multiple clients talk to > > multiple servers. > > Is this an architectural or protocol issue? Mostly architectural. It's still reflected in the protocol. It would be possible, though I admit very difficult, to devise a protocol which did not support the (quite correctly observed) _Architectural_ requirement of many clients/many servers. I would be happy to drop this many-to-many requirement as Too Damn Obvious to Mention. > > Specific Operations/Scenarios > > > > Note that these are protocol requirements, not box > > requirements. So, while the protocol must support the ability > > of a client to ask for a pinhole, the protocol also allows > > for a middlebox to return 'NO - I am a NAT, dummy.' > > > > * - must support a client-to-server transaction which returns > > * the middlebox capabilities to the client. These capabilities > > * must include, but not be restricted to: > > * - firewalling > > * - NAT > > * - NAT capabilities (ports and stuff) > > * - Plumbing information (where does NAT fit > > * relative to other elements, specifically, > > * THIS MATTERS!) > > I dont believe that it should be the case. The capabilities your > refer to are provisioning issues which are outside the scope. The > client should be able to know ahead of time what services a middlebox > supports and if makes a wrong request, then the result should be > service not supported and not this is what I support. So far I seem to be the only member of the 'Client should be able to figure out what the Middlebox can do' camp. If anyone else agrees with me, let me know! Otherwise, I will assume that the WG collectively thinks Andrew is a doofus, and I will cheerfully drop this from my little list. > Pluming information! What is that? Plumbing, as in the way pipes are connected to one another to supply water to sinks and whatnot, and to carry waste water away from same? This word is also used in STREAMS based IP stacks to indicate how various functional pieces are connected to one another. I use it, basically, to talk about whether NAT comes before or after pinholes. That is, do you describe pinholes in terms of: Inside addresses Outside addresses Pre-NAT addresses Post-NAT addresses If this pushed out to a Client Provisioning problem, then it all becomes moot. > There are other means of doing QoS and the middlebox protocol is and > should not be one of them. There seems to be some debate on this as well. I think that solving the problem of QoS is Out Of Scope, but the problem of Making The Protocol Extensible is In Scope. I am happy to drop mentions of QoS -- except that I think I stuck them in in response to some other comments. I'd appreciate feedback on this issue -- drop all mention of QoS in favor of a vague 'extensibility' or keep QoS as the canonical extension? > > - it would sure be nice if these binding requests could > > specify information about the expected source of the > > flow initiator. E.G. 'I have a server on the inside > > at 192.168.1.99 port 5000, and I think someone on the > > outside at address 209.46.41.61, I don't know the port' > > will be connecting to my server -- please give me an > > address/port I can advertise to the remote as the phone's > > address/port' > > You might want to call it late port binding feature and along > the same thought late ip binding. A mechanism might be needed > in this case to ensure the authenticity of the binding like > a token sent to the target and returned to the source to > authenticate the binding accordingly. That is an interesting idea. How compatible with current practice is it? Also, is it in-scope? > > * - must support means for clients to manage redundant middlebox > > * configurations. This means that it must be possible for a > > * client or clients to: > > * - apply the same NAT binding across multiple (NAT capable) > > * middleboxes. > > * - apply the same pinhole across multiple (pinhole capable) > > * middleboxes (this is actually trivial and impossible > > * to NOT get right -- included for completeness) > > * > > * [ these two boil down to: client can keep a primary > > * and a spare middlebox in synch ] > > Middlebox synchronization is a client issue and not > a protocol nor a middlebox requirement. Leave it out. Again, my intention is not solve the problem, but to require that the protocol not make it impossible to solve. It's a real problem, and if MIDCOM devices make it impossible to solve by not giving clients enough information to synch middleboxes, then MIDCOM is essentially pointless. You are perfectly correct that it is a Client problem, and I in no way intend to suggest anything else. Basically, this requirement comes from having actually built a protocol that wasn't expressive enough solve the synchronization problem, and having to go back and do work to fix it. Thus, I know it's a real problem, and I know it's relatively easy to accidentally Not Solve It. > > - must support a client-to-server transaction to release an > > individual NAT binding. > > > > - must support a client-to-server transaction to release an > > individual pinhole. > > > > - should support a way to identify bundles of state (pinholes > > and NAT) as belonging to the same group (a "session ID" > > specified by the client in a set of requests) > > I propose using the concept of service which could encompass a number > of functions like pinhole and NAT rather than session ID which > could be confused with transport and registration. I'm happy to take suggestions for the right word here. I think 'service' gets confused with port numbers? Perhaps something like 'sheaf ID' or 'bundle ID,' since session ID apparently has undesirable connotations. > > - should support a client-to-server transaction to delete all > > the state bundled under a given session ID. > > > > * - should support a way to re-session-ID a bundle. That is, > > * there should be a client-to-server transaction in which > > * the client asks the middlebox to take all the stuff with > > * session ID "A" and re-file it under session ID "B" > > * > > * [ this is a surprisingly useful operation but the uses of it > > * that I know of might be proprietary so I shan't describe them. > > * There are people reading who know whether they are or are not > > * proprietary, so if there is curiosity, hopefully explanations > > * will be forthcoming. Sorry to be so mysterious. ] > > MEGACO utilizes a nice connection model which allows such operations > to take a place. It is very useful and I believe that it would be > more productive if we apply the same concepts here. I will try to get a chance to go look at MEGACO in more detail soon. Thanks for the pointer! > regards > > Abdallah Thank you for your comments and criticism. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 15:03: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 PAA26351 for ; Mon, 2 Apr 2001 15:03: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 OAA22629; Mon, 2 Apr 2001 14:56: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 OAA22601 for ; Mon, 2 Apr 2001 14:56:17 -0400 (EDT) Received: from corb.mc.mpls.visi.com ([208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26146 for ; Mon, 2 Apr 2001 14:56:17 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id DCD8B8118; Mon, 2 Apr 2001 13:53:49 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id NAA07538; Mon, 2 Apr 2001 13:56:07 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 2 Apr 2001 13:56:07 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] [Fwd: RFC 3093 on Firewall Enhancement Protocol] In-Reply-To: <20010402184151.7D0B835C42@berkshire.research.att.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, 2 Apr 2001, Steven M. Bellovin wrote: > In message , "Christian > Huitema" writes: > > > > >This should drive home a point about firewall: they only work if the > >protected users cooperate. And users would be much more likely to > >cooperate if there was an organized way to cross the wall when needed... > > Absolutely. You have to make it easy for peole to do the right thing. Well, making the consequences of doing the wrong thing sufficiently horrifying accomplishes much the same goal -- nearly but not quite universal compliance. I feel like writing an RFC on the use of terror to establish secure networks. This would, unfortunately, be mostly a record of current practices, with some suggestions for making things more horrible. > --Steve Bellovin, http://www.research.att.com/~smb _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 16:54: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 QAA00790 for ; Mon, 2 Apr 2001 16:54: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 QAA24671; Mon, 2 Apr 2001 16:44: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 QAA24633 for ; Mon, 2 Apr 2001 16:44:41 -0400 (EDT) Received: from mail-green.research.att.com ([135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00159 for ; Mon, 2 Apr 2001 16:44:43 -0400 (EDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 68D121E006; Mon, 2 Apr 2001 14:41:56 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA28466; Mon, 2 Apr 2001 14:41:52 -0400 (EDT) Received: from berkshire.research.att.com (localhost.research.att.com [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 7D0B835C42; Mon, 2 Apr 2001 14:41:51 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Christian Huitema" Cc: "Andrew Molitor" , midcom@ietf.org Subject: Re: [midcom] [Fwd: RFC 3093 on Firewall Enhancement Protocol] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Apr 2001 14:41:51 -0400 Message-Id: <20010402184151.7D0B835C42@berkshire.research.att.com> Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org In message , "Christian Huitema" writes: > >This should drive home a point about firewall: they only work if the >protected users cooperate. And users would be much more likely to >cooperate if there was an organized way to cross the wall when needed... Absolutely. You have to make it easy for peole to do the right thing. --Steve Bellovin, http://www.research.att.com/~smb _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 18:27: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 SAA02984 for ; Mon, 2 Apr 2001 18:27: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 SAA26259; Mon, 2 Apr 2001 18:10: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 SAA26198 for ; Mon, 2 Apr 2001 18:10:12 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02703 for ; Mon, 2 Apr 2001 18:10:12 -0400 (EDT) Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 2 Apr 2001 16:58:16 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2AWWPNWS; Mon, 2 Apr 2001 16:58:18 -0400 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2A9369R8; Mon, 2 Apr 2001 16:58:17 -0400 Message-ID: <3AC8E8C7.6AAAC341@americasm01.nt.com> Date: Mon, 02 Apr 2001 17:01:59 -0400 From: "Abdallah Rayhan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Molitor CC: midcom@ietf.org Subject: Re: [midcom] SIP MIDCOM flow... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Your example shows NAT/pinhole opening as two separate actions. It does make sense in certain scenarios. However, the protocol should be capable of coupling the two if necessary. For example give me NAT'ed address and open the whole at same time. If one action fails, the other fails too. To make such a thing possible, it might be needed to define the latter in terms of the former. That is to say, the subject of the latter is a variable referencing the ip to be from the NAT. regards Abdallah Andrew Molitor wrote: > All Singing All Dancing Firewall+NAT Across Two Networks > -------------------------------------------------------- > > Application A MidBox A MidBox B Application B > | | | | > Call Initiate | | | > from X | | | | > -------->| NAT REQ | | | > |------------->| | | > | Target: X | | | > | Source: * | | | > | | | | > | NAT RESP | | | > | Map: X->X1 | | | > |<-------------| | | > | | | | > | Call Initiate From X1| | > |-------------------------------------------------->| (locate dest > | | | | at Y and fwd > | | | | initiate) > | | | | > | | | | ACK from Y > | | | |<----------- > | | | NAT REQ | > | | | Target: Y | > | | | Source: * | > | | |<---------------| > | | | | > | | | NAT RESP | > | | | Map: Y->Y1 | > | | |--------------->| > | | | | > | | | Open Pinhole | > | | | X1 --> Y1 | > | | |(or * --> Y1?) | > | | |<---------------| > | | | ACK Pinhole | > | | |--------------->| > | | | | > | | | Open Pinhole | > | | | X1 <-- Y1 | > | | |(or X1 <-- * ?) | > | | |<---------------| > | | | ACK Pinhole | > | | |--------------->| > | | ACK From Y1 | | > |<--------------------------------------------------| > | | | | > | Open Pinhole | | | > | X1 --> Y1 | | | > |(or * --> Y1?)| | | > |------------->| | | > | ACK Pinhole | | | > |<-------------| | | > | | | | > | Open Pinhole | | | > | X1 <-- Y1 | | | > |(or X1 <-- *?)| | | > |------------->| | | > | ACK Pinhole | | | > |<-------------| | | > | | | | > | | | | > ACK From | | | | > Y1 | | | | > <--------| | | | > > Note that there is an issue of whether pinholes are opened > for pre-NAT addresses, post-NAT addresses, Internal addresses or > External Addresses (there are indeed 4 cases). Indicated above, pinholes > are indicated for External addresses. > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 18:31: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 SAA03029 for ; Mon, 2 Apr 2001 18:30: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 SAA26495; Mon, 2 Apr 2001 18:29: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 SAA26466 for ; Mon, 2 Apr 2001 18:29:06 -0400 (EDT) Received: from redball.dynamicsoft.com ([216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03011 for ; Mon, 2 Apr 2001 18:29:06 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA23110; Mon, 2 Apr 2001 18:31:09 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 18:27:43 -0400 Message-ID: From: Tim Rang To: "'Abdallah Rayhan'" , Andrew Molitor Cc: midcom@ietf.org Subject: RE: [midcom] SIP MIDCOM flow... Date: Mon, 2 Apr 2001 18:27:43 -0400 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 That makes sense, but I think the answer may be for the vendor to use the abstract primitive type to couple them internally(a NAT that controls policy as well). Tim Rang > -----Original Message----- > From: Abdallah Rayhan [mailto:arayhan@nortelnetworks.com] > Sent: Monday, April 02, 2001 5:02 PM > To: Andrew Molitor > Cc: midcom@ietf.org > Subject: Re: [midcom] SIP MIDCOM flow... > > > > Your example shows NAT/pinhole opening as two separate actions. > It does make sense in certain scenarios. However, the protocol > should be capable of coupling the two if necessary. For example > give me NAT'ed address and open the whole at same time. If one > action fails, the other fails too. To make such a thing possible, > it might be needed to define the latter in terms of the former. > That is to say, the subject of the latter is a variable referencing > the ip to be from the NAT. > > regards > Abdallah > > > Andrew Molitor wrote: > > > All Singing All Dancing Firewall+NAT Across Two Networks > > -------------------------------------------------------- > > > > Application A MidBox A MidBox B > Application B > > | | | | > > Call Initiate | | | > > from X | | | | > > -------->| NAT REQ | | | > > |------------->| | | > > | Target: X | | | > > | Source: * | | | > > | | | | > > | NAT RESP | | | > > | Map: X->X1 | | | > > |<-------------| | | > > | | | | > > | Call Initiate From X1| | > > > |-------------------------------------------------->| (locate dest > > | | | > | at Y and fwd > > | | | > | initiate) > > | | | | > > | | | > | ACK from Y > > | | | > |<----------- > > | | | NAT REQ | > > | | | Target: Y | > > | | | Source: * | > > | | |<---------------| > > | | | | > > | | | NAT RESP | > > | | | Map: Y->Y1 | > > | | |--------------->| > > | | | | > > | | | Open Pinhole | > > | | | X1 --> Y1 | > > | | |(or * --> Y1?) | > > | | |<---------------| > > | | | ACK Pinhole | > > | | |--------------->| > > | | | | > > | | | Open Pinhole | > > | | | X1 <-- Y1 | > > | | |(or X1 <-- * ?) | > > | | |<---------------| > > | | | ACK Pinhole | > > | | |--------------->| > > | | ACK From Y1 | | > > |<--------------------------------------------------| > > | | | | > > | Open Pinhole | | | > > | X1 --> Y1 | | | > > |(or * --> Y1?)| | | > > |------------->| | | > > | ACK Pinhole | | | > > |<-------------| | | > > | | | | > > | Open Pinhole | | | > > | X1 <-- Y1 | | | > > |(or X1 <-- *?)| | | > > |------------->| | | > > | ACK Pinhole | | | > > |<-------------| | | > > | | | | > > | | | | > > ACK From | | | | > > Y1 | | | | > > <--------| | | | > > > > Note that there is an issue of whether pinholes are opened > > for pre-NAT addresses, post-NAT addresses, Internal addresses or > > External Addresses (there are indeed 4 cases). Indicated > above, pinholes > > are indicated for External addresses. > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 2 18:46: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 SAA03202 for ; Mon, 2 Apr 2001 18:46: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 SAA26784; Mon, 2 Apr 2001 18:37: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 SAA26759 for ; Mon, 2 Apr 2001 18:37:54 -0400 (EDT) Received: from corb.mc.mpls.visi.com ([208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03113 for ; Mon, 2 Apr 2001 18:37:54 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 545E18116 for ; Mon, 2 Apr 2001 17:35:47 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA22627 for ; Mon, 2 Apr 2001 17:38:09 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 2 Apr 2001 17:38:09 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] SIP MIDCOM flow... In-Reply-To: <3AC8E8C7.6AAAC341@americasm01.nt.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, 2 Apr 2001, Abdallah Rayhan wrote: > > Your example shows NAT/pinhole opening as two separate actions. > It does make sense in certain scenarios. However, the protocol > should be capable of coupling the two if necessary. For example > give me NAT'ed address and open the whole at same time. If one > action fails, the other fails too. To make such a thing possible, > it might be needed to define the latter in terms of the former. > That is to say, the subject of the latter is a variable referencing > the ip to be from the NAT. As an architect, I say 'what a good idea!' and as an implementor with an existing framework, it makes me turn white as a sheet and break out in a cold sweat. I suspect that it is useful somewhat less frequently than you might imagine. Since the WG is to deal with existing middlebox class devices, would it be ok to allow this as an optional transaction which might fail, and cause the client to fall back on the two step version? The alternative is to force everyone in the middlebox business to build a more complex MIDCOM adaptation layer which can handle the two steps internally. This raises a more general question: - do we prefer to develop the smallest possible set of primitives which still manage, perhaps with some effort, to express everything necessary or: - do we prefer to devise more complex primitives which most easily express everything needed. This really comes down to: - make MIDCOM servers easy to write atop existing middleboxes at the expense of more complex client software - make MIDCOM servers hard to write atop existing middleboxes in order to make client software easier to write Obviously this isn't really two choices, but a spectrum of them. Note also the usefulness of 'MIDCOM server' as a separate element to middlebox ;) > regards > Abdallah Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Apr 3 08: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 IAA27686 for ; Tue, 3 Apr 2001 08:02: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 HAA12390; Tue, 3 Apr 2001 07:53: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 HAA12359 for ; Tue, 3 Apr 2001 07:53:01 -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 HAA27262; Tue, 3 Apr 2001 07:53:00 -0400 (EDT) Message-Id: <200104031153.HAA27262@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Apr 2001 07:53:00 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-scenarios-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. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Scenarios Author(s) : C. Huitema Filename : draft-ietf-midcom-scenarios-00.txt Pages : 14 Date : 02-Apr-01 As trusted third parties are increasingly being asked to make policy decisions on behalf of the various entities participating in an application's operation, a need has developed for applications to be able to communicate their needs to the devices in the network that provide transport policy enforcement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-scenarios-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-scenarios-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: <20010402124807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124807.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Apr 3 09:43: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 JAA00460 for ; Tue, 3 Apr 2001 09:43: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 JAA13737; Tue, 3 Apr 2001 09:04: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 JAA13706 for ; Tue, 3 Apr 2001 09:03:59 -0400 (EDT) Received: from acmepacket.com ([63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29334 for ; Tue, 3 Apr 2001 09:03:58 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A9F6846013E; Tue, 03 Apr 2001 09:02:46 -0400 Message-ID: <002c01c0bc3e$d6942080$3700000a@acmepacket.com> From: "Bob Penfield" To: "Andrew Molitor" , References: Subject: Re: [midcom] SIP MIDCOM flow... Date: Tue, 3 Apr 2001 09:06: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.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: "Andrew Molitor" To: Sent: Monday, April 02, 2001 6:38 PM Subject: Re: [midcom] SIP MIDCOM flow... > > > On Mon, 2 Apr 2001, Abdallah Rayhan wrote: > > > > > Your example shows NAT/pinhole opening as two separate actions. > > It does make sense in certain scenarios. However, the protocol > > should be capable of coupling the two if necessary. For example > > give me NAT'ed address and open the whole at same time. If one > > action fails, the other fails too. To make such a thing possible, > > it might be needed to define the latter in terms of the former. > > That is to say, the subject of the latter is a variable referencing > > the ip to be from the NAT. > > As an architect, I say 'what a good idea!' and as an implementor > with an existing framework, it makes me turn white as a sheet and break > out in a cold sweat. I suspect that it is useful somewhat less frequently > than you might imagine. > > Since the WG is to deal with existing middlebox class devices, > would it be ok to allow this as an optional transaction which might > fail, and cause the client to fall back on the two step version? > > The alternative is to force everyone in the middlebox business > to build a more complex MIDCOM adaptation layer which can handle the two > steps internally. > > This raises a more general question: > > - do we prefer to develop the smallest possible set of > primitives which still manage, perhaps with some effort, to > express everything necessary > or: > - do we prefer to devise more complex primitives which most easily > express everything needed. > We obviously want to keep things as simple as possible, but there are certain sets of operations that clients would like to do in a single operation (like NAT+open pin-hole) to limit traffic between the controller and the middlebox. If a middlebox is capable of this, it should be allowed. > > This really comes down to: > > - make MIDCOM servers easy to write atop existing middleboxes > at the expense of more complex client software > - make MIDCOM servers hard to write atop existing middleboxes > in order to make client software easier to write > > Obviously this isn't really two choices, but a spectrum of them. > Note also the usefulness of 'MIDCOM server' as a separate element > to middlebox ;) > I think we need to be very flexible in the protocol requirements in order to maximize both. I don't think we can necessarily say that a small set of primitives will make it easier to make a MIDCOM server atop an existing middlebox. It all depends on the architecture and design of the middlebox. > > > regards > > Abdallah > > Andrew > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 (781) 933-6166 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Apr 3 10:26: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 KAA02161 for ; Tue, 3 Apr 2001 10:26: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 KAA14863; Tue, 3 Apr 2001 10:21: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 KAA14829 for ; Tue, 3 Apr 2001 10:21:03 -0400 (EDT) Received: from mail.aravox.com ([209.46.41.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01993 for ; Tue, 3 Apr 2001 10:21:02 -0400 (EDT) Received: from linux.aravox.com (mail-gw.aravox.com [209.46.41.66]) by mail.aravox.com (Postfix) with ESMTP id 6C1355430; Tue, 3 Apr 2001 09:20:34 -0500 (CDT) Received: (from jladwig@localhost) by linux.aravox.com (8.9.3/8.9.3) id JAA28151; Tue, 3 Apr 2001 09:20:34 -0500 From: John Ladwig MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15049.56347.939506.647736@linux.aravox.com> Date: Tue, 3 Apr 2001 09:20:11 -0500 (CDT) To: Andrew Molitor Cc: midcom@ietf.org Subject: Re: [midcom] Protocol Requirements Bullet List v2.0 In-Reply-To: Andrew Molitor's message of 2 April 2001 References: <3AC8B31F.CBDCB7AC@americasm01.nt.com> X-Mailer: VM 6.71 under 21.1 (patch 4) "Arches" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit >>>>> On Mon, 2 Apr 2001 13:46:41 -0500 (CDT), Andrew Molitor said: >> > - must support high transaction throughput over highish >> > latency networks (read: must support message streaming.) >> >> High transaction of the middlebox, the transport, the client, >> or the protocol itself. Remove high. Andrew> I don't understand this. If I have an excess 'high' in Andrew> there, my brain refuses to see it (which in no way implies Andrew> that there isn't one -- we all know how our brain locks up Andrew> on these things sometimes!) Suggest: - Midcom protocol must support high transaction throughput, even when the network path has significant latency. (read: must support message streaming.) >> > - must support one or more strong authentication models. >> >> Most firewall if not all implement IPSec. What is the meaning of >> requiring more? >> >> > * - must support one or more privacy models. >> >> See the above comment. Andrew> IPSec is a wonderful thing, but it's unfair to assume that Andrew> all clients will speak it, or that all clients will speak Andrew> it in a manner that is currently interoperable with the Andrew> middleboxes. I confess that I haven't followed IPSec that Andrew> closely, recently. Does it really solve the Andrew> application-to-application problem? I thought it focuses Andrew> more on host-to-host and net-to-net. You are correct, so far as I can tell. Andrew> Anyways, it would be fine with me if MIDCOM wound up Andrew> stating that IPSec or TLS or something was a requirement Andrew> to meet these needs of the protocol. The point is, the Andrew> protocol needs authentication and privacy -- where they Andrew> come from is a problem to be solved soon, but not right Andrew> now! At the Minneapolis pre-conference Security Tutorial, Jeff Schiller explicitly stated that "must run over IPSec" is *not* a general solution for unsecured protocols which pass sensitive information. In particular, he noted that it's not generally possible for an application to determine whether IPSec is in use, much less the specifics of the protection scheme in use to a given host. TLS is a rather different animal, and more appropriate to this application. However, TLS (re: RFC 2246) assumes a reliable transport such as TCP. >> > Specific Operations/Scenarios >> > >> > Note that these are protocol requirements, not box >> > requirements. So, while the protocol must support the ability >> > of a client to ask for a pinhole, the protocol also allows >> > for a middlebox to return 'NO - I am a NAT, dummy.' >> > >> > * - must support a client-to-server transaction which returns >> > * the middlebox capabilities to the client. These capabilities >> > * must include, but not be restricted to: >> > * - firewalling >> > * - NAT >> > * - NAT capabilities (ports and stuff) >> > * - Plumbing information (where does NAT fit >> > * relative to other elements, specifically, >> > * THIS MATTERS!) >> >> I dont believe that it should be the case. The capabilities your >> refer to are provisioning issues which are outside the scope. The >> client should be able to know ahead of time what services a middlebox >> supports and if makes a wrong request, then the result should be >> service not supported and not this is what I support. Andrew> So far I seem to be the only member of the 'Client should Andrew> be able to figure out what the Middlebox can do' camp. Andrew> If anyone else agrees with me, let me know! Otherwise, I Andrew> will assume that the WG collectively thinks Andrew is a Andrew> doofus, and I will cheerfully drop this from my little Andrew> list. In general, I'm (unsurprisingly) on the same page. More specifically, since draft-ietf-midcom-scenarios-00.txt was published this morning, I'm even more on the same page. Unless I read it wrong, the first (2.1 - TCP server behind a firewall/NAT) scenario Christiane Huitema posits direct signalling from a "terminal" (to use H.323 terminology) application to the midcom server. In the absence of site-specific mass-configuration of such applications, and assuming that this scenario is accepted by the WG, I think the midcom client should indeed be able to "figure out" what the midcom server/box can control. More generally, if we're to enable a variety of different sorts of midcom boxes with this protocol, I think we need to allow for different midcom client elements to ascertain the capabilities of midcom server elements. In large networks, there might be several different implementations of midcom servers, whether simultaneously or over time. In the absence of capability negotiation, would not a QoS-capable midcom client be faced with the possibility or likelihood of generating a large number of unfulfillable QoS provisioning requests to the server? Alternatively, the midcom client is going to have to build and track server-capability state, and that seems fragile and unnecessary. I need to go mull over the idea of direct midcom signalling by applications. I can see the appeal, for enabling peer-to-peer applications, but to be quite frank, I'm not enamored of enshrining a general-purpose firewall-avoidance architecture in the midcom WG. All of my thinking to date has been of enabling a controlled signalling infrastructure to update policy as part of provisioning on behalf of endpoints/terminals/applications. The implications of allowing, for example, any IP within a large (and inherently untrustable) metropolitan network to signal changes to the firewall policy are many; the policy engine at the midcom box would have to be quite elaborate and robust for me to feel even slightly comfortable with that, putting on my old academic network-security-admin hat for a moment. -jml _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Apr 3 10:58: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 KAA03288 for ; Tue, 3 Apr 2001 10:58: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 KAA15328; Tue, 3 Apr 2001 10:49: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 KAA15257 for ; Tue, 3 Apr 2001 10:49:22 -0400 (EDT) Received: from web1401.mail.yahoo.com (web1401.mail.yahoo.com [128.11.23.165]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03080 for ; Tue, 3 Apr 2001 10:49:21 -0400 (EDT) Received: (qmail 12511 invoked by uid 60001); 3 Apr 2001 14:49:22 -0000 Message-ID: <20010403144922.12510.qmail@web1401.mail.yahoo.com> Received: from [65.12.33.187] by web1401.mail.yahoo.com; Tue, 03 Apr 2001 07:49:22 PDT Date: Tue, 3 Apr 2001 07:49:22 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Protocol Requirements Bullet List v2.0 To: Abdallah Rayhan , Andrew Molitor Cc: midcom@ietf.org In-Reply-To: <3AC8B31F.CBDCB7AC@americasm01.nt.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 Andrew - Lots of good text for requirements. Fully agree with most of them. (nits commented below ;-). I do have a gripe, however. That is w.r.t. new terms and defintiions. This adds to confusion. Didnt we just agree in Minneapolis to use a single set of terms and that they shall be defined in framework draft? I am open to text changes to add clarity. But, let us simply not proliferate terminology with each conversation. Let us try and reuse the same terms consistently throughout. Thanks. cheers, suresh --- Abdallah Rayhan wrote: > See comments below. > > Andrew Molitor wrote: > > > Throughout, I use this terminology: > > Andrew - We already have a framework draft with terms and definitions. Can we work together to fix the terms and defintions, in just one place. Thanks. > > Client - something that requests pinholes and NAT bindings. For > > example, a MIDCOM aware ALG or SIP proxy. > > > > Server - something which is spoken to by a client. By implication, > > a Server resides in (logically, if not literally) a > > Middlebox, and exposes the services of that Middlebox > > to Clients. > > I disagree with the client-server model. MIDCOM communication is one of peer-to-peer model in that MIDCOM session may be initiated by ether party (Middlebox or MIDCOM agent). The MIDCOM agent is more like a co-processing entity than a client or a server. Asynchronous notification can be sent by either party. Requests are sent by MIDCOM agent (to permit sessions through firewall and create NAT BINDs and sessions) as well as Middlebox (to parse application specific payloads and modify the same). As such, I would like to suggest using the terms "Middlebox" and "Midcom agent" as the two entities taking part in MIDCOM communication. > > Middlebox - a firewall or NAT device which is coupled to a > > MIDCOM server, which offers the firewall/NAT services > > to Clients. MIDCOM protocol support is not a requirement for an entity to be called a middlebox. NAT and firewall devices are middleboxes, irrespective of whether they are party to MIDCOM protocol or not. I believe, Middlebox is an intermediate device that requires application specific intelligence for its operation. > > I dont understand the need for the distinction between the server > and the middlebox in view of the functionality described above. > If the middlebox is considered to be a policy enforcement point (PEP) > and the it is usually controlled by a policy server which is the > policy decision point (PDP). The middlebox may require > to outsource decisions to its policy server which is in alignment > with the policy framework. However, introducing a new server > will add no value and crumble the PEP-PDP relationship. Furthermore, > the server-middlebox will require defining a new interface between > them which is something already being done in the policy framework. > I believe that the client should talk to the middlebox and the > middlebox talks to the policy server when it needs to. If the > objective of the above terminology is to utilize the client-server > concepts into the midcom architecture then it might be better to > say that the middlebox implements the server side of the midcom > protocol rather than introducing a new logical/physical device. > Abdallah - I disagree with the PDP-PEP model youare suggesting. I dont see the Policy Server as equivalent of a PDP. A policy server is merely one that enforces authorization and trust model. Policy Server is out of the way once a registration and trust model is established. ENd-to-End sessions are established between Middlebox and MIDCOM agent. It is also worth noting that the communication between Middlebox and Policy Server need not be based on MIDCOM protocol. > > > Do we want to require a 1-to-1 relationship between Servers > > and Middleboxes? > > In view of what I said before, outside the scope of the WG. > > > Protocol requirements in no particular order: > > > > General Stuff > > ============= > > * - must support low-latency, high-throughput operation, with > > * best effort to maintain low latency in the face of a lossy > network. > > * This is necessary for telecom grade operations -- backoff > > * policies in retransmit timers are not necessarily a good idea > > * on controlled channels controlling equipment. (This boils > > * down to: TCP Considered Harmful -- in rather specific > > * environments.) > > I believe that the kind of protocol we are looking at is an application > protocol as we are not to solve a transport problem here. So, I recommend > separating the requirements into the protocol requirements describing > the functionality and transport requirements for the transport performance > issues. There are protocols like SCTP which is designed for performance > in telecom like scenarios but that should not mean rolling out TCP. > > > * > > * - must also support more ordinary network traffic models for > > * use on standard networks where backoff policies for retransmit > > * timers, and the like, are a good ideas. (This boils down to: > > * TCP is a hell of a good idea most of the time.) > > * > > * [ I think the first bullet above pretty much requires UDP > > * transport with wicked timers, but if there's another option > > * I'd be pleased to hear about it. The situation I am thinking > > * of is: some goober in a POP unplugs the wrong cable for > > * a moment, or there is some other glitch in connectivity. > > * It would Be Bad if this glitch made TCP back off and make > > * the POP unable to complete calls for, say, 2 or 3 seconds > > * AFTER connectivity is restored. This could readily create > > * irritating post-dial delays for several hundred customers > > * over the next 10 seconds while the queue clears. This is the > > * sort of thing that gives telecom geeks nightmares. ] > > > > - should be transport independent, a la SIP. > > > > - must support high transaction throughput over highish > > latency networks (read: must support message streaming.) > > High transaction of the middlebox, the transport, the client, or the > protocol itself. Remove high. > > > - must support one or more strong authentication models. > > Most firewall if not all implement IPSec. What is the meaning of > requiring more? > > > > > * - must support one or more privacy models. > > See the above comment. > > > - must support client-to-server request/response transactions. > > > * - must support server-to-client "alerts" (unacknowledged messages) > > * > > * - should support an acknowledged server-to-client messaging > > * model as well? > > Andrew - Good collection of requirements. They all seem very relevant and valid. > > - must support models in which multiple clients talk to > > multiple servers. > > Is this an architectural or protocol issue? > This is one of a framework/architectural issue. I believe, this is covered in the framework draft. > > Specific Operations/Scenarios > > > > Note that these are protocol requirements, not box > > requirements. So, while the protocol must support the ability > > of a client to ask for a pinhole, the protocol also allows > > for a middlebox to return 'NO - I am a NAT, dummy.' > > > > * - must support a client-to-server transaction which returns > > * the middlebox capabilities to the client. These capabilities > > * must include, but not be restricted to: > > * - firewalling > > * - NAT > > * - NAT capabilities (ports and stuff) > > * - Plumbing information (where does NAT fit > > * relative to other elements, specifically, > > * THIS MATTERS!) > > I dont believe that it should be the case. The capabilities your > refer to are provisioning issues which are outside the scope. The > client should be able to know ahead of time what services a middlebox > supports and if makes a wrong request, then the result should be > service not supported and not this is what I support. > I agree with Andrew's observation. A Midcom agent should be able to query a middlebox and learn of the specific middlebox functions supported. This is different from discovery. A midcom agent may choose to co-opt with one or all of the middlebox functions supported. As for plumbing, I suspect, Andrew is refering to the data path sequencing of the NAT and firewall. I believe, going into the sequencing can be a rat-hole. Anatomy of data path, I believe, should be out of scope for this WG. Section 6.4 of the framework draft punts this, assuming out-of-scope. > Pluming information! What is that? > > > * > > * and should include: > > * - QoS > > * - QoS flavor(s) > > * [ can someone help out with what one might want to say > > * if one WERE a QoS capable middlebox? Is this far enough > > * out of scope to just leave QoS out entirely, burying it > > * in the 'but not be restricted to' part above? ] I think, we should not try and address the QOS issue at this time. Suffices to say that middlebox may also be one that enforces policy based QOS. These issues may be considered while designing the MIDCOM protocol (to make it extensible and usable with a wider set of functions). > > There are other means of doing QoS and the middlebox protocol is and > should not be one of them. > > > - must support a client-to-server transaction to open a > > "pinhole" in the middlebox's traffic policy. > > > > - must support a client-to-server transaction to request > > a NAT binding, associating an IP address/port pair on > > one interface with an IP address/port pair on another. > > > > - it would sure be nice if these binding requests could > > specify information about the expected source of the > > flow initiator. E.G. 'I have a server on the inside > > at 192.168.1.99 port 5000, and I think someone on the > > outside at address 209.46.41.61, I don't know the port' > > will be connecting to my server -- please give me an > > address/port I can advertise to the remote as the phone's > > address/port' > > You might want to call it late port binding feature and along > the same thought late ip binding. A mechanism might be needed > in this case to ensure the authenticity of the binding like > a token sent to the target and returned to the source to > authenticate the binding accordingly. > Abdallah - the trust model is established apriori. No additional mechansims need to be devised into the MIDCOM protocol, specific to a certain type of request. Note, Simple Source-address based security is the least form of security and may be permitted to the most trusted hosts. > > > * - must support means for clients to manage redundant middlebox > > * configurations. This means that it must be possible for a > > * client or clients to: > > * - apply the same NAT binding across multiple (NAT capable) > > * middleboxes. > > * - apply the same pinhole across multiple (pinhole capable) > > * middleboxes (this is actually trivial and impossible > > * to NOT get right -- included for completeness) > > * > > * [ these two boil down to: client can keep a primary > > * and a spare middlebox in synch ] > > Middlebox synchronization is a client issue and not > a protocol nor a middlebox requirement. Leave it out. I agree with Abdallah's comment. Client's redundacy issues are out of scope. > > > * > > * - bring a new middlebox into synch with a set of > > * synchronized redundant middleboxes. > > * > > * [ this boils down to: a client can bring a formerly > > * dead primary middlebox back into service after repairs, > > * without bringing the network down.] > > Out. > Same as above. Out of scope. > > > > - must support a client-to-server transaction to release an > > individual NAT binding. Must also support a transaction to create or release a NAT session. > > > > - must support a client-to-server transaction to release an > > individual pinhole. > > > > - should support a way to identify bundles of state (pinholes > > and NAT) as belonging to the same group (a "session ID" > > specified by the client in a set of requests) > > I propose using the concept of service which could encompass a number > of functions like pinhole and NAT rather than session ID which > could be confused with transport and registration. > A service/function is one of NAT or Firewall. Andrew is suggesting that there be a way to identify session bundling (not service bundling). I dont understand, why it is confusing to have session ID. This is different from MIDCOM transport and MIDCOM registration. The session ID that Andrew is refering to is the end-to-end user sessions, not the Middlebox-MIDCOM-agent sessions. > > - should support a client-to-server transaction to delete all > > the state bundled under a given session ID. > > > > * - should support a way to re-session-ID a bundle. That is, > > * there should be a client-to-server transaction in which > > * the client asks the middlebox to take all the stuff with > > * session ID "A" and re-file it under session ID "B" > > * > > * [ this is a surprisingly useful operation but the uses of it > > * that I know of might be proprietary so I shan't describe them. > > * There are people reading who know whether they are or are not > > * proprietary, so if there is curiosity, hopefully explanations > > * will be forthcoming. Sorry to be so mysterious. ] > > MEGACO utilizes a nice connection model which allows such operations > to take a place. It is very useful and I believe that it would be > more productive if we apply the same concepts here. > > > > > - must support a way to specify a desired timeout value for > > and piece of state created by a client-to-server transaction. > > > > - should support both activity based timeouts as well as > > absolute timeouts (i.e. support both 'if you don't see any > > packets for 60 seconds, please make this NAT binding go > > away by itself' AND 'make this NAT binding go away in 60 > > seconds') > > > > - must support client-to-server transactions to query middlebox > > state, including but not restricted to: > > > > - currently installed pinholes > > - currently installed NAT bindings > > - statistics of various sorts > > MEGACO provides a complete set of queries. I recommend borrowing > from its requirements draft. > > > - should support a client-to-server transaction allowing the > > client to register to receive notifications of various > > sorts from the server. > > > > - should support some server-to-client transactions to inform > > the client of events such as: > > > > - timeouts of pinholes and NATs > > - violations of policy > > - other? > > > > > regards > > Abdallah > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom __________________________________________________ Do You Yahoo!? Get email at your own domain with 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 Apr 3 17:03: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 RAA17050 for ; Tue, 3 Apr 2001 17: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 RAA21547; Tue, 3 Apr 2001 17:01: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 RAA21509 for ; Tue, 3 Apr 2001 17:00:58 -0400 (EDT) Received: from hnssysa.hns.com ([139.85.76.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16936 for ; Tue, 3 Apr 2001 17:00:58 -0400 (EDT) Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id RAA15778; Tue, 3 Apr 2001 17:00:28 -0400 (EDT) Message-ID: <3ACA39D0.E266DD06@hns.com> Date: Tue, 03 Apr 2001 17:00:00 -0400 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Molitor CC: midcom@ietf.org Subject: Re: [midcom] Protocol Requirements Bullet List v2.0 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 > > > Specific Operations/Scenarios > > > > > > Note that these are protocol requirements, not box > > > requirements. So, while the protocol must support the ability > > > of a client to ask for a pinhole, the protocol also allows > > > for a middlebox to return 'NO - I am a NAT, dummy.' > > > > > > * - must support a client-to-server transaction which returns > > > * the middlebox capabilities to the client. These capabilities > > > * must include, but not be restricted to: > > > * - firewalling > > > * - NAT > > > * - NAT capabilities (ports and stuff) > > > * - Plumbing information (where does NAT fit > > > * relative to other elements, specifically, > > > * THIS MATTERS!) > > > > I dont believe that it should be the case. The capabilities your > > refer to are provisioning issues which are outside the scope. The > > client should be able to know ahead of time what services a middlebox > > supports and if makes a wrong request, then the result should be > > service not supported and not this is what I support. > > So far I seem to be the only member of the 'Client should > be able to figure out what the Middlebox can do' camp. If anyone else > agrees with me, let me know! Otherwise, I will assume that the WG > collectively thinks Andrew is a doofus, and I will cheerfully drop > this from my little list. I think this is part of "discovery" so I agree that it is out of scope. But, the protocol does need to include a means to indicate when a "mistake" in provisioning has occured, e.g. a NAT should return some kind of helpful (to the person who will have to debug the problem) response if asked to "do" firewall and vice versa. John _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Apr 4 14:11: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 OAA27843 for ; Wed, 4 Apr 2001 14:11: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 OAA17657; Wed, 4 Apr 2001 14:10: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 OAA17628 for ; Wed, 4 Apr 2001 14:10:07 -0400 (EDT) Received: from zcars04f.ca.nortel.com ([47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27827 for ; Wed, 4 Apr 2001 14:10:05 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 4 Apr 2001 13:50:00 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H9XD35PG; Wed, 4 Apr 2001 13:49:57 -0400 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2A937D9C; Wed, 4 Apr 2001 13:49:58 -0400 Message-ID: <3ACB5FA5.6EBC2C5A@americasm01.nt.com> Date: Wed, 04 Apr 2001 13:53:41 -0400 From: "Abdallah Rayhan" Reply-To: midcom@ietf.org Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Subject: Re: [midcom] Protocol Requirements Bullet List v2.0 References: <3AC8B31F.CBDCB7AC@americasm01.nt.com> <15049.56347.939506.647736@linux.aravox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit See comments below. John Ladwig wrote: > > >>>>> On Mon, 2 Apr 2001 13:46:41 -0500 (CDT), Andrew Molitor said: > > >> > - must support high transaction throughput over highish > >> > latency networks (read: must support message streaming.) > >> > >> High transaction of the middlebox, the transport, the client, > >> or the protocol itself. Remove high. > > Andrew> I don't understand this. If I have an excess 'high' in > Andrew> there, my brain refuses to see it (which in no way implies > Andrew> that there isn't one -- we all know how our brain locks up > Andrew> on these things sometimes!) > > Suggest: > > - Midcom protocol must support high transaction throughput, even > when the network path has significant latency. (read: must > support message streaming.) I am trying to differentiate between protocol requirements and operational requirements. So if we come up with a protocol tomorrow what would constitute a high transaction throughput? In my mind, throughput means how fast you process the requests in a particular machine including the buffer size and complexity of implementation. These are implementation issues and definitely not protocolish. The transport requirements most probably would mandate the support of TCP and UDP. How UDP would provide you with high transaction throughput when there is traffic congestion? As for message streaming, is that really a requirement or a design decision? I believe that it is the latter. Let us focus on the functional requirements. Sigtran and MEGACO looked into these issues before and I believe that they did pretty good job addressing them. btw, I tried to see if SIP has "high transaction throughput" in the requirements. Guess what? It does not appear any where! > > >> > - must support one or more strong authentication models. > >> > >> Most firewall if not all implement IPSec. What is the meaning of > >> requiring more? > >> > >> > * - must support one or more privacy models. > >> > >> See the above comment. > > Andrew> IPSec is a wonderful thing, but it's unfair to assume that > Andrew> all clients will speak it, or that all clients will speak > Andrew> it in a manner that is currently interoperable with the > Andrew> middleboxes. I confess that I haven't followed IPSec that > Andrew> closely, recently. Does it really solve the > Andrew> application-to-application problem? I thought it focuses > Andrew> more on host-to-host and net-to-net. > > You are correct, so far as I can tell. These are transport requirements and deployment issues which I believe that IPSec can take of. This is the IETF where stacks are developed. If necessary, make authentication and confidentiality as transport requirements because they are not protocol requirements. If you are going to require encryption at the application layer, how do you expect to have high transaction throughput then? > Andrew> Anyways, it would be fine with me if MIDCOM wound up > Andrew> stating that IPSec or TLS or something was a requirement > Andrew> to meet these needs of the protocol. The point is, the > Andrew> protocol needs authentication and privacy -- where they > Andrew> come from is a problem to be solved soon, but not right > Andrew> now! > > At the Minneapolis pre-conference Security Tutorial, Jeff Schiller > explicitly stated that "must run over IPSec" is *not* a general > solution for unsecured protocols which pass sensitive information. In > particular, he noted that it's not generally possible for an > application to determine whether IPSec is in use, much less the > specifics of the protection scheme in use to a given host. If that is the case, then why do we have IPSec in the first place? IPSec is being used in the implementation of VPN which has more reaching effect than just one protocol between two devices. > > TLS is a rather different animal, and more appropriate to this > application. However, TLS (re: RFC 2246) assumes a reliable transport > such as TCP. > > >> > Specific Operations/Scenarios > >> > > >> > Note that these are protocol requirements, not box > >> > requirements. So, while the protocol must support the ability > >> > of a client to ask for a pinhole, the protocol also allows > >> > for a middlebox to return 'NO - I am a NAT, dummy.' > >> > > >> > * - must support a client-to-server transaction which returns > >> > * the middlebox capabilities to the client. These capabilities > >> > * must include, but not be restricted to: > >> > * - firewalling > >> > * - NAT > >> > * - NAT capabilities (ports and stuff) > >> > * - Plumbing information (where does NAT fit > >> > * relative to other elements, specifically, > >> > * THIS MATTERS!) > >> > >> I dont believe that it should be the case. The capabilities your > >> refer to are provisioning issues which are outside the scope. The > >> client should be able to know ahead of time what services a middlebox > >> supports and if makes a wrong request, then the result should be > >> service not supported and not this is what I support. > > Andrew> So far I seem to be the only member of the 'Client should > Andrew> be able to figure out what the Middlebox can do' camp. > > Andrew> If anyone else agrees with me, let me know! Otherwise, I > Andrew> will assume that the WG collectively thinks Andrew is a > Andrew> doofus, and I will cheerfully drop this from my little > Andrew> list. > > In general, I'm (unsurprisingly) on the same page. More specifically, > since draft-ietf-midcom-scenarios-00.txt was published this morning, > I'm even more on the same page. Unless I read it wrong, the first > (2.1 - TCP server behind a firewall/NAT) scenario Christiane Huitema > posits direct signalling from a "terminal" (to use H.323 terminology) > application to the midcom server. In the absence of site-specific > mass-configuration of such applications, and assuming that this > scenario is accepted by the WG, I think the midcom client should > indeed be able to "figure out" what the midcom server/box can control. > You can accomplish the same thing without the need to place such a requirement on the middlebox. For example, consider the following scenario. When the client registers with the middlebox, it could request the services it needs. The middlebox would authorize or deny the services accordingly without the need to spill its guts. This way the client would know if it can carry out its duties with that particular middlebox or not. This state is global and there is no complexity in keeping it in the client. The client needs to register anyway with the middlebox before communications starts. regards Abdallah _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Apr 4 20:03: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 UAA04876 for ; Wed, 4 Apr 2001 20:03: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 UAA24092; Wed, 4 Apr 2001 20:02: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 UAA24064 for ; Wed, 4 Apr 2001 20:02:32 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04858 for ; Wed, 4 Apr 2001 20:02:31 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA09720; Wed, 4 Apr 2001 17:02:03 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f3501xv15078; Wed, 4 Apr 2001 17:01:59 -0700 (PDT) Message-ID: <3ACBB5F6.4EC098B8@cisco.com> Date: Wed, 04 Apr 2001 17:01:58 -0700 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: march@external.cisco.com, midcom@ietf.org Content-Type: multipart/mixed; boundary="------------4DD3A82E83B73E6E52104E77" Subject: [midcom] MIDCOM discovery 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 This is a multi-part message in MIME format. --------------4DD3A82E83B73E6E52104E77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, As promised I've posted a draft on discovery requirements. It's a little rough around the edges, but I would appreciate your feedback on the diagrams, as they are presented in the draft. It's a short document, so here it is... -- Eliot Lear lear@cisco.com --------------4DD3A82E83B73E6E52104E77 Content-Type: text/plain; charset=iso-8859-1; name="draft-lear-middlebox-discovery-requirements-00.txt" Content-Disposition: inline; filename="draft-lear-middlebox-discovery-requirements-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group Eliot Lear INTERNET-DRAFT Cisco Systems Category: Informational April 4, 2001 Requirements for Discovering Middleboxes 1 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 2 Abstract The end to end nature of the Internet has been broken. Boxes within the middle of the network may change contents of packets at the Internet layer or above without the knowledge of the end devices. As these middleboxes such as NATs and firewalls have proliferated within the Internet, protocols are being developed to communicate with them. This document addresses requirements for discovery of those boxes. 3 Introduction The IPv4 Internet consists of a network of interconnected networks that may use public or private address space. The use of private address space [BCP5] has broken the classic connection model that applications use to speak to other devices. Similarly, many networks are separated by firewalls. Lear Expires October 5, 2001 [Page = 1]=0C In some cases, a firewall or a NAT may silently inhibit a communication between end hosts, either by design or incidental to the middlebox's function. Such failures may leave application developers, end users, or their administrators baffled as to the cause. Herein we will review the nature of those sorts of communications, and we will develop requirements for mechanisms that would notify the end user of the possibility or eventuality of such failures. The reader should be familiar with RFCs 1918, 2663, and 2775. We do not intend to fix all problems related to NATs or firewalls with this architecture. For instance, one will not find below a way to save a TCP connection in the face of a NAT failure. Instead, one may find a way to determine that in fact a failure has occurred, requiring the end hosts to attempt to re-establish communiations. 3.1 Terminology All the terminology in this internet draft is subject to change, and will, in the end, conform to the consensus of appropriate working groups. It is assumed by the author that work on terminology will proceed elsewhere. Therefore, for brevity's sake the following terms are defined for purposes of this document. Private Realm (PR) - an administratively defined group of computers, routers, and links that a middlebox may affect. ADs may encompass one another. Internal Host (IH) - a device within an PR. External Host (EH) - a device outside an PR. Middlebox - a device that sits on the edge of an PR within the packet flow between an internal host and an external host, whose function is to inhibit, modify, or divert packets. For purposes of this document, a packet is modified if data other the IP TOS or TTL fields has been altered. Application Controller (AC) - a device that actively manages application level communications between two devices. Application Proxy - a device that represents an internal host to an external host, such that layer 3 knowledge of the internal host is completely kept from the external host. Connection direction - the direction in which a transport connection is initiated. 4 The Simple Picture Figure 1 contains a basic example of a deployment. There are XXX communications that must be considered in the context of middlebox discovery. Lear Expires October 5, 2001 [Page = 2]=0C ______________________________ | | | Private Realm | | | | [AC] | | | ------- [OH-1] | | / \ | [IH-1] [middle box] |Internet| | | \ / [OH-2] | [IH-2] | \------/ | | ------------------------------- Figure 1. 4.1 Base Case: Non-use of Middleboxes The first case is the case where either IH-1 and IH-2 communicate, or when OH-1 and OH-2 communicate. In this case, there is no middlebox to discovery. Any discovery mechanism MUST NOT burden or break this communication as it is the communication that is assumed by all existing applications. The devices IH-1 and IH-2 MUST not be required to have any additional topological knowledge, over and above what they would have today, in order to communicate. We will call this case "Duh". 4.1.2 Modified Duh Similarly, a discovery mechanism MUST NOT require application controllers to participate, so long as only only internal hosts are involved. Thus, an H.323 gatekeeper serving IH-1 and IH-2 MUST be able to process signaling between those two devices, just as they do today. 4.2 Internal to External, No Application Controller In an IH to EH communication, the IH will have at its disposal the IP address and protocol information necessary to connect to the EH. Any such information MAY be used by the IH in a discovery protocol to determine which middleboxes may affect the communication. Examples of IH to EH communication would include a web connection, or a direct SIP connection. When an internal host initiates a connection to an external host, the architecture MUST NOT require that either end host participate in the routing system more so than they do already. Put another way, it is unreasonable for end hosts to have topological knowledge of the network for purposes of middlebox discovery, and even more unreasonable for them to have to indicate changes of that topology to the routing system. Aside from security concerns existing recommended Internet routing protocols are not well suited to the task of having every edge device participate. Lear Expires October 5, 2001 [Page = 3]=0C 4.3 External to Internal, No Application Controller If we simply look at the flow between an internal and external host, the difference between this case and the previous is that the intended transport flow is reversed. Policy permitting, discovery of middleboxes should be no different than the previous case. However, the situation is a bit more complex. Prior to connecting, an external host must acquire an IP address for the internal host. That internal host may not have an address in the external host's realm, and the internal host's address in its own realm may be temporary. Thus, some interaction with a name service will be required. In order for this to occur, the internal host must have established a binding between its address in its realm and its address in the external host's realm. If the internal host's realm is adjacent to more than one realm, the internal host may need more than one external address, and it will need to discover all the middleboxes adjacent to all the realms to which it wishes to make itself known. = 4.4 Application Controller In this case, the application controller is contacted by either the internal or external host prior to them contacting each other. The application controller may or may not be in the data flow, but the AC is contacted explicitly. The AC may then return communication parameters so that a transport connection would be established. The AC, however, is required to discover the middlebox. Because the AC may not be in the data flow this could pose complications for discovery. 5 Usage Examples Below are a number of network topologies in which discovery could occur. An AC can be found in each figure. However, the case should also be considered without the AC. Similarly, since an AC may itself be a middlebox, consider the cases where it and the router are combined. Lear Expires October 5, 2001 [Page = 4]=0C _______ | | _______ | AC | ___________________ | | |_______| | | | IH1 | ___|____ | | |_______|------| | | | __| router | | | _______ / |________| | Internet | | |__/ | | | | IH2 | | | | _______ |_______| ___|___ | | | | | | | |-------| OH1 | |middle |-----|___________________| |_______| | box | |_______| Figure 2: Simple Network Topology The best example of the use of an AC is that of an incoming SIP call. See [HUITEMA] for a flow diagram. The key point to note in this diagram is that the AC will want to determine whether or not the middlebox will affect communication between IH1 and IH2 or between IH1 and OH1. Moreover, the AC must also keep track of which middlebox is used. _______ | | _______ | IH1 | | | |_______| ____| AC | | / |_______| ___|___ / _______ | |____/ _______ | |---------------| R1 | | | | M1 | |_______|------------| M3 | |_______| ___|___ |_______| | | | | | | M2 | | | |_______| | _|___________ ______|_______ ________|____ | | | | | | | | | | | | | Realm A | | Realm B | | Internet | | | | | | | |_____________| |______________| |_____________| | | | __|____ ___|___ ___|___ | | | | | | | OH1 | | OH2 | | OH3 | |_______| |_______| |_______| Figure 3: Corporate Network with Private Connections Lear Expires October 5, 2001 [Page = 5]=0C Figure 3 depicts a case in which the application controller must not only determine that IH1 will use a middlebox to communicate with OH1, which is located in Realm A, but that it will use Middlebox M1, as opposed to M2 or M3. And of course, for IH1 to communicate with OH3, M3 will be used instead. Indeed M1, M2, and M3 may implement very different policies. For instance, Realm A may be within the same enterprise, whereas Realm B might be a private link to a partner, such as a supplier. Assuming each of these middleboxes are NATs, the addresses given will be specific to the realms of OH and OH2, and global for the case of OH3. This becomes important in our next case. _______ | | | AC | |_______| | _______ ___|___ _______ _______ _______ | | | | | | | | | | | IH1 |---| R1 |---| M1 |---| R2 |---| M2 | |_______| |_______| |_______| |_______| |_______| | | __|____ | | | | | R3 | ________|____ |_______| | | | | | __|____ | Internet | | | | | | OH2 | |_____________| |_______| | __|____ | | | OH1 | |_______| Figure 4: Mass Chaos In this case, the application controller must discover either one or two middleboxes, depending on whether IH1 will communicate with OH1 or OH2. Note that it is possible that Middlebox M2 won't be in the same address realm as AC, making knowledge of the topology a difficult option under existing technology. Also note in this example that the information that OH1 wants is the global address to use for IH1. Thus, information provided by middlebox M1 to AC1 is at best of no use and certainly misleading. It is possible to combine figures 3 and 4 to be truely horrifying. Lear Expires October 5, 2001 [Page = 6]=0C 6 Requirements What can we conclude about requirements for discovery, based on the above cases? First, we must handle both the existance and non-existance of application controllers. In addition, whereever there is a middlebox there will be policy associated with that middlebox. If policy does not permit it to do so, a middlebox MAY NOT respond to any form of discovery. Discovery mechganisms, therefore SHOULD be configurable within a middlebox (we say "SHOULD" in with the hopes that they will be present at all). Discovery SHOULD be possible in the presence of multiple middleboxes, both in the case where they are serially between two end hosts, or where there is a choice between two middleboxes based on the destination. Discovery messages themselves may need to be modified by middleboxes. = In order for internal hosts to function as servers, discovery of a middlebox may need to occur prior PRIOR to a communication with any external host. = 7 Security Considerations There are numerous security considerations that middle boxes will encounter, and the ones we list below should be viewed as far from complete. The diagnostics and discovery discussed in this draft are useful only within the boundaries of a single administrative domain. The middle boxes on the borders of that domain should prevent external devices from participating by not transmitting diagnostic messages outside, and by not listening for signaling requests on interfaces external to that domain. 8 IANA Considerations None. 9 References [1] Rekhter et. al., "Address Allocation for Private Internets", RFC 1918, February 1996. [2] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [3] Srisuresh, P., Holdrege, M., "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August, 1999. [4] Huitema, C., "Middlebox Scenarios", Internet Draft, April 2001. Lear Expires October 5, 2001 [Page = 7]=0C = 10 Author's Address Eliot Lear Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134-1706 Email: lear@cisco.com Phone: +1 (408) 527 4020 11 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, Lear Expires October 5, 2001 [Page = 8]=0C EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 17 Expiration Date This memo is filed as , and expires October 5, 2001. --------------4DD3A82E83B73E6E52104E77-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 5 06:42: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 GAA26716 for ; Thu, 5 Apr 2001 06:42: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 GAA09866; Thu, 5 Apr 2001 06:41: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 GAA09838 for ; Thu, 5 Apr 2001 06:41:38 -0400 (EDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26645 for ; Thu, 5 Apr 2001 06:41:37 -0400 (EDT) Message-Id: <200104051041.GAA26645@ietf.org> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:03:12 -0100 From: "Rita de Groot" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 11:00:42 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [midcom] huidziekte Sender: 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 Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Apr 6 05:21:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06715 for ; Fri, 6 Apr 2001 05:21: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 FAA07919; Fri, 6 Apr 2001 05:14:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07889 for ; Fri, 6 Apr 2001 05:14:09 -0400 (EDT) Received: from gandalf.axion.bt.co.uk ([132.146.17.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06642 for ; Fri, 6 Apr 2001 05:14:08 -0400 (EDT) From: graham.travers@bt.com Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP; Fri, 6 Apr 2001 10:11:44 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Fri, 6 Apr 2001 10:11:57 +0100 Message-ID: <451D45016C2CD2119DA50000F8FE7F070C1A991E@mlngcbnt01.hc.bt.com> To: lear@cisco.com, midcom@ietf.org Subject: RE: [midcom] MIDCOM discovery requirements Date: Fri, 6 Apr 2001 10:11:50 +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 Eliot, I thought discovery had been ruled "out of scope" for Midcom. Regards, Graham. -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: 05 April 2001 01:02 To: march@external.cisco.com; midcom@ietf.org Subject: [midcom] MIDCOM discovery requirements Hi, As promised I've posted a draft on discovery requirements. It's a little rough around the edges, but I would appreciate your feedback on the diagrams, as they are presented in the draft. It's a short document, so here it is... -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Apr 6 08:58: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 IAA08467 for ; Fri, 6 Apr 2001 08:58: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 IAA10598; Fri, 6 Apr 2001 08:54: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 IAA10567 for ; Fri, 6 Apr 2001 08:54:33 -0400 (EDT) Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08360 for ; Fri, 6 Apr 2001 08:54:32 -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.9.3/8.9.1) with ESMTP id FAA04247; Fri, 6 Apr 2001 05:54:25 -0700 (PDT) Received: from spandex (rtp-vpn-270.cisco.com [10.82.193.14]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AAG65403; Fri, 6 Apr 2001 05:54:00 -0700 (PDT) Message-ID: <009f01c0be98$f18f9840$d45904d1@cisco.com> From: "Melinda Shore" To: , , References: <451D45016C2CD2119DA50000F8FE7F070C1A991E@mlngcbnt01.hc.bt.com> Subject: Re: [midcom] MIDCOM discovery requirements Date: Fri, 6 Apr 2001 08:56:05 -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 thought discovery had been ruled "out of scope" for Midcom. It is, but that doesn't preclude submitting individual drafts (which, of course, would be of interest to many midcom participants). Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Apr 18 06:18: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 GAA08819 for ; Wed, 18 Apr 2001 06:18: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 GAA22265; Wed, 18 Apr 2001 06:06: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 GAA22240 for ; Wed, 18 Apr 2001 06:06:37 -0400 (EDT) Received: from hoemail2.firewall.lucent.com ([192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08750 for ; Wed, 18 Apr 2001 06:06:40 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA08405 for ; Wed, 18 Apr 2001 06:06:40 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA08390 for ; Wed, 18 Apr 2001 06:06:39 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA08814; Wed, 18 Apr 2001 12:06:38 +0200 (MET DST) Cc: midcom@ietf.org Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA08801; Wed, 18 Apr 2001 12:06:35 +0200 (MET DST) Message-ID: <3ADD679E.7C466CAB@lucent.com> Date: Wed, 18 Apr 2001 12:08:30 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Molitor Original-CC: midcom@ietf.org Subject: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) 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 Dragging myself out of a pile of outher work.... I believe that the terminology below is correct. > Throughout, I use this terminology: > > Client - something that requests pinholes and NAT bindings. For > example, a MIDCOM aware ALG or SIP proxy. > > Server - something which is spoken to by a client. By implication, > a Server resides in (logically, if not literally) a > Middlebox, and exposes the services of that Middlebox > to Clients. > > Middlebox - a firewall or NAT device which is coupled to a > MIDCOM server, which offers the firewall/NAT services > to Clients. Using this terminology we do not into terminology conflicts when we need to introduce MIDCOM proxies to off-load authorisation of Client requests. This comes in when you answer the next question: > > Do we want to require a 1-to-1 relationship between Servers > and Middleboxes? yes. Even if you assume that one firewall will be spoken to from one domain of control (i.e. clients under one ownership) you will want to allow redundancy in that, so there may be requests coming in from several Clients. Now in pratical cases you will want to allow several SIP proxies and other application server all to establish flows through the firewall. So the Middlebox really is a server, it will control the handing out of flows through it and will have to authorise the requests. When you look at this at carrier scale, introduction of a MIDCOM proxy seem very likely so the box can just execute requests (in such a deployment). IF we set the requirement right and get the protocol right, it will allow such a deployment and not hamper other deployments. Paul -- Paul Sijben Tel:+31 356874774 Lucent Technologies Message:+31 208702874 Forward Looking Work Fax: +31 208702874 Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Apr 18 09:45: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 JAA11139 for ; Wed, 18 Apr 2001 09:45: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 JAA25204; Wed, 18 Apr 2001 09:37: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 JAA25177 for ; Wed, 18 Apr 2001 09:37:14 -0400 (EDT) Received: from acmepacket.com ([63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11010 for ; Wed, 18 Apr 2001 09:37:18 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A83C173003A; Wed, 18 Apr 2001 09:35:56 -0400 Message-ID: <004a01c0c80c$ce364600$2300000a@acmepacket.com> From: "Bob Penfield" To: "Paul Sijben" , "Andrew Molitor" Cc: References: <3ADD679E.7C466CAB@lucent.com> Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Date: Wed, 18 Apr 2001 09:38:07 -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: "Paul Sijben" To: "Andrew Molitor" Cc: Sent: Wednesday, April 18, 2001 6:08 AM Subject: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) > > Dragging myself out of a pile of outher work.... > > I believe that the terminology below is correct. > > > Throughout, I use this terminology: > > > > Client - something that requests pinholes and NAT bindings. For > > example, a MIDCOM aware ALG or SIP proxy. > > > > Server - something which is spoken to by a client. By implication, > > a Server resides in (logically, if not literally) a > > Middlebox, and exposes the services of that Middlebox > > to Clients. > > > > Middlebox - a firewall or NAT device which is coupled to a > > MIDCOM server, which offers the firewall/NAT services > > to Clients. > > Using this terminology we do not into terminology conflicts when we need to > introduce MIDCOM proxies to off-load authorisation of Client requests. > This comes in when you answer the next question: > > > > Do we want to require a 1-to-1 relationship between Servers > > and Middleboxes? > > > yes. Even if you assume that one firewall will be spoken to from one domain of > control (i.e. clients under one ownership) you will want to allow redundancy > in that, so there may be requests coming in from several Clients. Now in > pratical cases you will want to allow several SIP proxies and other > application server all to establish flows through the firewall. So the > Middlebox really is a server, it will control the handing out of flows through > it and will have to authorise the requests. I think that defining a relationship between the server and the middlebox is beyond the scope of the WG. If the charter is to define a protocol, we can define the requirements of the server to handle the protocol and provide the services. As far as the client is concerned, the server is the middlebox. What difference does it make if a given middlebox has more than one server? > > When you look at this at carrier scale, introduction of a MIDCOM proxy seem > very likely so the box can just execute requests (in such a deployment). > > IF we set the requirement right and get the protocol right, it will allow such > a deployment and not hamper other deployments. > > Paul > > > -- > Paul Sijben Tel:+31 356874774 > Lucent Technologies Message:+31 208702874 > Forward Looking Work Fax: +31 208702874 > Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) > > _______________________________________________ > 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 Apr 18 14:40: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 OAA15487 for ; Wed, 18 Apr 2001 14:40: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 OAA00416; Wed, 18 Apr 2001 14:24: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 OAA00387 for ; Wed, 18 Apr 2001 14:24:35 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15229 for ; Wed, 18 Apr 2001 14:24:39 -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.9.3/8.9.1) with ESMTP id LAA01779; Wed, 18 Apr 2001 11:24:32 -0700 (PDT) Received: from spandex (rtp-vpn-64.cisco.com [10.82.192.64]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ACB12446; Wed, 18 Apr 2001 11:24:07 -0700 (PDT) Message-ID: <001001c0c835$113239a0$d45904d1@cisco.com> From: "Melinda Shore" To: "Bob Penfield" Cc: References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Date: Wed, 18 Apr 2001 14:26:19 -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 that defining a relationship between the server and the middlebox is > beyond the scope of the WG. If the charter is to define a protocol, we can > define the requirements of the server to handle the protocol and provide the > services. As far as the client is concerned, the server is the middlebox. > What difference does it make if a given middlebox has more than one server? A protocol between a server and middlebox absolutely is out-of-scope. However, we need to consider the case of a multi-function middlebox - combined NAT/firewall, etc. In that case there's the possibility of having multiple "servers" on the middlebox - one for each function. I personally think that's not a particularly desirable design, but we do have to consider that possibility. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 19 09:00: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 JAA10555 for ; Thu, 19 Apr 2001 09:00: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 IAA22830; Thu, 19 Apr 2001 08:52: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 IAA22801 for ; Thu, 19 Apr 2001 08:52:33 -0400 (EDT) Received: from hoemlsrv.firewall.lucent.com ([192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10498 for ; Thu, 19 Apr 2001 08:52:37 -0400 (EDT) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA15534 for ; Thu, 19 Apr 2001 08:52:33 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA15507 for ; Thu, 19 Apr 2001 08:52:31 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA15048; Thu, 19 Apr 2001 14:52:31 +0200 (MET DST) Cc: Bob Penfield , midcom@ietf.org Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA15025; Thu, 19 Apr 2001 14:52:28 +0200 (MET DST) Message-ID: <3ADED209.B46FDF4F@lucent.com> Date: Thu, 19 Apr 2001 13:54:49 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore Original-CC: Bob Penfield , midcom@ietf.org Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> <001001c0c835$113239a0$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 TIMEOUT! as far as I am concerned the Middlebox IS a MIDCOM server. It is a server for the protocol and the application or its proxy is a MIDCOM client. The point I tried to make is that if we choose the terminology right, they are not the ONLY clients and servers one may see, allowing the introduction of a MIDCOM proxy, when (not if) we need it. Paul Melinda Shore wrote: > > > I think that defining a relationship between the server and the middlebox is > > beyond the scope of the WG. If the charter is to define a protocol, we can > > define the requirements of the server to handle the protocol and provide the > > services. As far as the client is concerned, the server is the middlebox. > > What difference does it make if a given middlebox has more than one server? > > A protocol between a server and middlebox absolutely > is out-of-scope. However, we need to consider the case > of a multi-function middlebox - combined NAT/firewall, > etc. In that case there's the possibility of having > multiple "servers" on the middlebox - one for each > function. I personally think that's not a particularly > desirable design, but we do have to consider that > possibility. > > Melinda > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- Paul Sijben Tel:+31 356874774 Lucent Technologies Message:+31 208702874 Forward Looking Work Fax: +31 208702874 Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 19 09:25:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10729 for ; Thu, 19 Apr 2001 09:25: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 JAA23221; Thu, 19 Apr 2001 09:09: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 JAA23193 for ; Thu, 19 Apr 2001 09:09:34 -0400 (EDT) Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10630 for ; Thu, 19 Apr 2001 09:09:33 -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.9.3/8.9.1) with ESMTP id GAA08119; Thu, 19 Apr 2001 06:07:39 -0700 (PDT) Received: from spandex (rtp-vpn-77.cisco.com [10.82.192.77]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ACH02575; Thu, 19 Apr 2001 06:08:31 -0700 (PDT) Message-ID: <01b701c0c8d2$2565f4a0$d45904d1@cisco.com> From: "Melinda Shore" To: "Paul Sijben" Cc: References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> <001001c0c835$113239a0$d45904d1@cisco.com> <3ADED209.B46FDF4F@lucent.com> Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Date: Thu, 19 Apr 2001 09:10: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 > as far as I am concerned the Middlebox IS a MIDCOM server. It is a server for > the protocol and the application or its proxy is a MIDCOM client. We do need to address, however, the multifunction middlebox. They're very common (probably found more often than not). What I'd prefer to see happen here is to choose terminology that's consistent with common usage and have it documented clearly in our deliverables, making sure to resolve any ambiguities that might result from the particulars of what we're doing. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 19 10:05: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 KAA11232 for ; Thu, 19 Apr 2001 10:05: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 JAA24029; Thu, 19 Apr 2001 09:58: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 JAA23998 for ; Thu, 19 Apr 2001 09:58: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 JAA11147 for ; Thu, 19 Apr 2001 09:58:25 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id GAE04552; Thu, 19 Apr 2001 06:57:57 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn-330.cisco.com [10.21.65.74]) by airborne.cisco.com (Mirapoint) with SMTP id AAT07268; Thu, 19 Apr 2001 06:57:51 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 19 Apr 2001 09:57:50 -0400 Date: Thu, 19 Apr 2001 09:57:50 -0400 From: Scott Brim To: Melinda Shore Cc: Paul Sijben , midcom@ietf.org Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Message-ID: <20010419095750.C1632@SBRIM-W2K> Mail-Followup-To: Scott Brim , Melinda Shore , Paul Sijben , midcom@ietf.org References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> <001001c0c835$113239a0$d45904d1@cisco.com> <3ADED209.B46FDF4F@lucent.com> <01b701c0c8d2$2565f4a0$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: <01b701c0c8d2$2565f4a0$d45904d1@cisco.com>; from mshore@cisco.com on Thu, Apr 19, 2001 at 09:10:45AM -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 Thu, Apr 19, 2001 at 09:10:45AM -0400, Melinda Shore wrote: > We do need to address, however, the multifunction > middlebox. box != function (!!!). There's a server FUNCTION etc. One of the nice agreements to come out of the IETF meeting, and one that I REALLY look forward to seeing in the new framework draft. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 19 10:17: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 KAA11408 for ; Thu, 19 Apr 2001 10:17: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 KAA24435; Thu, 19 Apr 2001 10:11: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 KAA24404 for ; Thu, 19 Apr 2001 10:11:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11308 for ; Thu, 19 Apr 2001 10:11:17 -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.9.3/8.9.1) with ESMTP id HAA23969; Thu, 19 Apr 2001 07:11:11 -0700 (PDT) Received: from spandex (rtp-vpn-77.cisco.com [10.82.192.77]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ACH03281; Thu, 19 Apr 2001 07:09:37 -0700 (PDT) Message-ID: <01de01c0c8da$aec44d20$d45904d1@cisco.com> From: "Melinda Shore" To: "Scott Brim" Cc: References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> <001001c0c835$113239a0$d45904d1@cisco.com> <3ADED209.B46FDF4F@lucent.com> <01b701c0c8d2$2565f4a0$d45904d1@cisco.com> <20010419095750.C1632@SBRIM-W2K> Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Date: Thu, 19 Apr 2001 10:11: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 > On Thu, Apr 19, 2001 at 09:10:45AM -0400, Melinda Shore wrote: > > We do need to address, however, the multifunction > > middlebox. > box != function (!!!). There's a server FUNCTION etc. Understood. That doesn't address, however, the question of how to approach the situation in which you've got a combined firewall/NAT. There's the possibility that each function may have its own server/interface, or that there's a single server/ interface which demuxes and manages messages from clients. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 19 11:42:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13005 for ; Thu, 19 Apr 2001 11:42: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 LAA26308; Thu, 19 Apr 2001 11:30: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 LAA26281 for ; Thu, 19 Apr 2001 11:30:27 -0400 (EDT) Received: from hoemail2.firewall.lucent.com ([192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12760 for ; Thu, 19 Apr 2001 11:30:32 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA15019 for ; Thu, 19 Apr 2001 11:30:30 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA15005 for ; Thu, 19 Apr 2001 11:30:29 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA07758; Thu, 19 Apr 2001 17:30:28 +0200 (MET DST) Cc: Scott Brim , midcom@ietf.org Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA07742; Thu, 19 Apr 2001 17:30:26 +0200 (MET DST) Message-ID: <3ADF0505.69ED174A@lucent.com> Date: Thu, 19 Apr 2001 17:32:21 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore Original-CC: Scott Brim , midcom@ietf.org Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> <001001c0c835$113239a0$d45904d1@cisco.com> <3ADED209.B46FDF4F@lucent.com> <01b701c0c8d2$2565f4a0$d45904d1@cisco.com> <20010419095750.C1632@SBRIM-W2K> <01de01c0c8da$aec44d20$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 ?????????? Now you got me seriously confused. Could you please explain why you think that these pose a problem? Paul Melinda Shore wrote: > > > On Thu, Apr 19, 2001 at 09:10:45AM -0400, Melinda Shore wrote: > > > We do need to address, however, the multifunction > > > middlebox. > > box != function (!!!). There's a server FUNCTION etc. > > Understood. That doesn't address, however, the > question of how to approach the situation in which > you've got a combined firewall/NAT. There's the > possibility that each function may have its own > server/interface, or that there's a single server/ > interface which demuxes and manages messages from > clients. > > Melinda > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- Paul Sijben Tel:+31 356874774 Lucent Technologies Message:+31 208702874 Forward Looking Work Fax: +31 208702874 Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 19 11:51: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 LAA13234 for ; Thu, 19 Apr 2001 11:51: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 LAA26592; Thu, 19 Apr 2001 11:42: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 LAA26565 for ; Thu, 19 Apr 2001 11:42:11 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13017 for ; Thu, 19 Apr 2001 11:42:15 -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.9.3/8.9.1) with ESMTP id IAA21509; Thu, 19 Apr 2001 08:42:09 -0700 (PDT) Received: from spandex (rtp-vpn-77.cisco.com [10.82.192.77]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ACH05219; Thu, 19 Apr 2001 08:41:41 -0700 (PDT) Message-ID: <025001c0c8e7$8b70cd00$d45904d1@cisco.com> From: "Melinda Shore" To: "Paul Sijben" Cc: "Scott Brim" , References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> <001001c0c835$113239a0$d45904d1@cisco.com> <3ADED209.B46FDF4F@lucent.com> <01b701c0c8d2$2565f4a0$d45904d1@cisco.com> <20010419095750.C1632@SBRIM-W2K> <01de01c0c8da$aec44d20$d45904d1@cisco.com> <3ADF0505.69ED174A@lucent.com> Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Date: Thu, 19 Apr 2001 11:43:54 -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 > Now you got me seriously confused. Could you please explain why you think > that these pose a problem? I'd like us to take some care to avoid a situation in which compliant implementations are not interoperable. That would be a bummer. If we say that a server is an interface to a function and somebody (say, everybody) implements multiple functions within their box, we want to make sure that we specify that either one server controls multiple functions *or* that we've explicitly addressed the implications of having multiple servers running on a box. Andrew has brought up the importance of being able to manage the ordering of operations, and probably the easiest way to control that is single threading and atomicity. If we're going to accept his requirement and we're going to reject atomicity/single threading as the way to handle the requirement, I think we need to document some very strong reasons for choosing a more complex approach. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 19 12:23: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 MAA13909 for ; Thu, 19 Apr 2001 12:23: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 MAA27334; Thu, 19 Apr 2001 12:15: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 MAA27305 for ; Thu, 19 Apr 2001 12:15:22 -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 MAA13781 for ; Thu, 19 Apr 2001 12:15:26 -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 RAA08018; Thu, 19 Apr 2001 17:14:33 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA52240; Thu, 19 Apr 2001 17:14:27 +0100 Message-ID: <3ADF0E76.6BC1DFBE@hursley.ibm.com> Date: Thu, 19 Apr 2001 11:12:38 -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: Paul Sijben , Scott Brim , midcom@ietf.org Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> <001001c0c835$113239a0$d45904d1@cisco.com> <3ADED209.B46FDF4F@lucent.com> <01b701c0c8d2$2565f4a0$d45904d1@cisco.com> <20010419095750.C1632@SBRIM-W2K> <01de01c0c8da$aec44d20$d45904d1@cisco.com> <3ADF0505.69ED174A@lucent.com> <025001c0c8e7$8b70cd00$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 Terminology matters. It's been pointed out in the midtax discussion that "box" implies a physical box, which is why the Web folk mainly talk about "intermediaries", and of course one physical box can contain multiple intermediaries. I'll be tweaking the midtax draft to point out that middle boxes are not in 1:1 correspondence with physical boxes. Over in network management land this is hardly a new concept; one box can contain many MIBs but only needs one SNMP agent. Brian Melinda Shore wrote: > > > Now you got me seriously confused. Could you please explain why you think > > that these pose a problem? > > I'd like us to take some care to avoid a situation > in which compliant implementations are not interoperable. > That would be a bummer. > > If we say that a server is an interface to a function > and somebody (say, everybody) implements multiple functions > within their box, we want to make sure that we specify that > either one server controls multiple functions *or* that we've > explicitly addressed the implications of having multiple > servers running on a box. Andrew has brought up the importance > of being able to manage the ordering of operations, and > probably the easiest way to control that is single threading > and atomicity. If we're going to accept his requirement and > we're going to reject atomicity/single threading as the way > to handle the requirement, I think we need to document some > very strong reasons for choosing a more complex approach. > > Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 19 13:46: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 NAA15174 for ; Thu, 19 Apr 2001 13:46: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 NAA28742; Thu, 19 Apr 2001 13:38: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 NAA28711 for ; Thu, 19 Apr 2001 13:38:14 -0400 (EDT) Received: from hebe.or.intel.com ([134.134.248.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15057 for ; Thu, 19 Apr 2001 13:38:20 -0400 (EDT) Received: from condryvaio-desk.intel.com (condryvaio-desk.jf.intel.com [134.134.159.68]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with ESMTP id RAA07182; Thu, 19 Apr 2001 17:38:14 GMT Message-Id: <5.0.2.1.2.20010419103607.01994008@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 19 Apr 2001 10:36:32 -0700 To: "Melinda Shore" , "Paul Sijben" From: "Michael W. Condry" Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Cc: In-Reply-To: <01b701c0c8d2$2565f4a0$d45904d1@cisco.com> References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> <001001c0c835$113239a0$d45904d1@cisco.com> <3ADED209.B46FDF4F@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Do not you need to re-charter or address this in the future? At 09:10 AM 4/19/2001 -0400, Melinda Shore wrote: > > as far as I am concerned the Middlebox IS a MIDCOM server. It is a > server for > > the protocol and the application or its proxy is a MIDCOM client. > >We do need to address, however, the multifunction >middlebox. They're very common (probably found more >often than not). What I'd prefer to see happen here >is to choose terminology that's consistent with >common usage and have it documented clearly in our >deliverables, making sure to resolve any ambiguities >that might result from the particulars of what we're >doing. > >Melinda > > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >http://www.ietf.org/mailman/listinfo/midcom Michael W. Condry Director, Network Edge Technology _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Apr 19 14:00: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 OAA15399 for ; Thu, 19 Apr 2001 14:00: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 NAA28924; Thu, 19 Apr 2001 13:50: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 NAA28893 for ; Thu, 19 Apr 2001 13:50:46 -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 NAA15246 for ; Thu, 19 Apr 2001 13:50:52 -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.9.3/8.9.1) with ESMTP id KAA13167; Thu, 19 Apr 2001 10:50:24 -0700 (PDT) Received: from spandex (rtp-vpn-77.cisco.com [10.82.192.77]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ACJ03133; Thu, 19 Apr 2001 10:50:16 -0700 (PDT) Message-ID: <031401c0c8f9$81cecec0$d45904d1@cisco.com> From: "Melinda Shore" To: "Paul Sijben" , "Michael W. Condry" Cc: References: <3ADD679E.7C466CAB@lucent.com><004a01c0c80c$ce364600$2300000a@acmepacket.com><001001c0c835$113239a0$d45904d1@cisco.com><3ADED209.B46FDF4F@lucent.com> <5.0.2.1.2.20010419103607.01994008@FMSMSX63.fm.intel.com> Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Date: Thu, 19 Apr 2001 13:52:29 -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 > Do not you need to re-charter or address this > in the future? I don't see why we would - what we're talking about here is ensuring that the work we're chartered to do is clear and correct. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Apr 20 07:58: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 HAA10587 for ; Fri, 20 Apr 2001 07:58: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 HAA21827; Fri, 20 Apr 2001 07:47: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 HAA21797 for ; Fri, 20 Apr 2001 07:47:45 -0400 (EDT) Received: from auemail1.firewall.lucent.com ([192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10534 for ; Fri, 20 Apr 2001 07:47:43 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3KBlfa08582 for ; Fri, 20 Apr 2001 07:47:41 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3KBlec08531 for ; Fri, 20 Apr 2001 07:47:40 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA08593; Fri, 20 Apr 2001 13:47:39 +0200 (MET DST) Cc: Scott Brim , midcom@ietf.org Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA08584; Fri, 20 Apr 2001 13:47:37 +0200 (MET DST) Message-ID: <3AE02248.6AC3C3C9@lucent.com> Date: Fri, 20 Apr 2001 13:49:29 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore Original-CC: Scott Brim , midcom@ietf.org Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) References: <3ADD679E.7C466CAB@lucent.com> <004a01c0c80c$ce364600$2300000a@acmepacket.com> <001001c0c835$113239a0$d45904d1@cisco.com> <3ADED209.B46FDF4F@lucent.com> <01b701c0c8d2$2565f4a0$d45904d1@cisco.com> <20010419095750.C1632@SBRIM-W2K> <01de01c0c8da$aec44d20$d45904d1@cisco.com> <3ADF0505.69ED174A@lucent.com> <025001c0c8e7$8b70cd00$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 Melinda Shore wrote: > > > Now you got me seriously confused. Could you please explain why you think > > that these pose a problem? > > I'd like us to take some care to avoid a situation > in which compliant implementations are not interoperable. > That would be a bummer. Sure. > > If we say that a server is an interface to a function > and somebody (say, everybody) implements multiple functions > within their box, we want to make sure that we specify that > either one server controls multiple functions *or* that we've > explicitly addressed the implications of having multiple > servers running on a box. Ah, there is the disconnect. Like I posted, way, way back when on either the foglamps list or the TIPHON security list, I fully agree that there are multiple functions to discern in one box. Such functions may be: - filtering (or selective forwarding) - flowspec policing - header rewriting (which as I have been told is something different from NAT which also may modify payload) - etc. Since all of these functions may happen on ONE packet flow, I would be very unhappy if we were to insist that each will have a separate interface on the box. I would rather see one protocol identifying the flow and several parts/plugings/packages that can be used to identify what to do with it. So I would like to see one MIDCOM server per flow. It may be the case that one will find multiple MIDCOM servers on the same box but pertaining to different flows. Paul > Andrew has brought up the importance > of being able to manage the ordering of operations, and > probably the easiest way to control that is single threading > and atomicity. If we're going to accept his requirement and > we're going to reject atomicity/single threading as the way > to handle the requirement, I think we need to document some > very strong reasons for choosing a more complex approach. > > Melinda -- Paul Sijben Tel:+31 356874774 Lucent Technologies Message:+31 208702874 Forward Looking Work Fax: +31 208702874 Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Apr 20 11:49: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 LAA13431 for ; Fri, 20 Apr 2001 11:49: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 LAA25513; Fri, 20 Apr 2001 11:43: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 LAA25486 for ; Fri, 20 Apr 2001 11:43:50 -0400 (EDT) Received: from df-inet1.exchange.microsoft.com ([131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13346 for ; Fri, 20 Apr 2001 11:43:49 -0400 (EDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 08:44:04 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Apr 2001 08:43:13 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 08:43:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4693.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Apr 2001 08:43:13 -0700 Message-ID: Thread-Topic: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Thread-Index: AcDJlFJZFQGRtidPSPOVgl/lEVu8JAAHBCOA From: "Christian Huitema" To: "Paul Sijben" , "Melinda Shore" Cc: "Scott Brim" , X-OriginalArrivalTime: 20 Apr 2001 15:43:13.0641 (UTC) FILETIME=[9C14CD90:01C0C9B0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA25487 Sender: 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 believe that "opening the guts of the box" is particularly useful. If we start from the scenarios document, we see only one function of relevance, the passing/blocking/natting of packets based on addresses and port numbers. We should concentrate on that. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Apr 20 12:12: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 MAA13930 for ; Fri, 20 Apr 2001 12:12: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 MAA26081; Fri, 20 Apr 2001 12:00: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 MAA26053 for ; Fri, 20 Apr 2001 12:00:42 -0400 (EDT) Received: from pallas.host4u.net ([216.71.64.48]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13663 for ; Fri, 20 Apr 2001 12:00:41 -0400 (EDT) Received: from C1380748B (c1380748-b.snvl1.sfba.home.com [65.11.102.112]) by pallas.host4u.net (8.8.5/8.8.5) with SMTP id KAA14846; Fri, 20 Apr 2001 10:49:09 -0500 From: "Shai Mohaban" To: "Paul Sijben" , "Melinda Shore" Cc: "Scott Brim" , Subject: RE: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Date: Fri, 20 Apr 2001 08:55:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3AE02248.6AC3C3C9@lucent.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 > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On > Behalf Of Paul Sijben > Sent: Friday, April 20, 2001 4:49 AM > To: Melinda Shore > Cc: Scott Brim; midcom@ietf.org > Subject: Re: terminology (was Re: [midcom] Protocol Requirements > Bullet List v2.0) > > > > > Melinda Shore wrote: > > > > > Now you got me seriously confused. Could you please explain > why you think > > > that these pose a problem? > > > > I'd like us to take some care to avoid a situation > > in which compliant implementations are not interoperable. > > That would be a bummer. > > Sure. > > > > If we say that a server is an interface to a function > > and somebody (say, everybody) implements multiple functions > > within their box, we want to make sure that we specify that > > either one server controls multiple functions *or* that we've > > explicitly addressed the implications of having multiple > > servers running on a box. > > Ah, there is the disconnect. Like I posted, way, way back when on > either the > foglamps list or the TIPHON security list, I fully agree that there are > multiple functions to discern in one box. Such functions may be: > > - filtering (or selective forwarding) > - flowspec policing > - header rewriting (which as I have been told is something > different from NAT > which also may modify payload) > - etc. > > Since all of these functions may happen on ONE packet flow, I > would be very > unhappy if we were to insist that each will have a separate > interface on the > box. I would rather see one protocol identifying the flow and several > parts/plugings/packages that can be used to identify what to do with it. > > So I would like to see one MIDCOM server per flow. It may be the > case that one > will find multiple MIDCOM servers on the same box but pertaining > to different > flows. This might be true on a single MidBox but you might have multiple MidBoxes in a row (e.g. one performing firewall/NAT while the other deals with QoS). In that case you will have to have multiple MidCom servers per flow hence the requirement. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Apr 21 23:10: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 XAA15252 for ; Sat, 21 Apr 2001 23:10: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 WAA29277; Sat, 21 Apr 2001 22:50: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 WAA29247 for ; Sat, 21 Apr 2001 22:50:46 -0400 (EDT) Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15203 for ; Sat, 21 Apr 2001 22:50:41 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GC60019IAJQ8Y@firewall.mcit.com> for midcom@ietf.org; Sun, 22 Apr 2001 02:50:15 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GC600E01AJQB1@pmismtp01.wcomnet.com> for midcom@ietf.org; Sun, 22 Apr 2001 02:50:14 +0000 (GMT) Received: from Steveb1 ([166.44.247.139]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GC600865AIV67@pmismtp01.wcomnet.com> for midcom@ietf.org; Sun, 22 Apr 2001 02:50:02 +0000 (GMT) Date: Sat, 21 Apr 2001 21:49:38 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] Protocol Requirements Bullet List v2.0 In-reply-to: <3ACB5FA5.6EBC2C5A@americasm01.nt.com> To: midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <000001c0cad6$e0035220$29e023a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit There are a couple of concerns near the end of this thread with my thoughts that I feel should be addressed further. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Abdallah Rayhan > Sent: Wednesday, April 04, 2001 12:54 PM > To: midcom@ietf.org > Subject: Re: [midcom] Protocol Requirements Bullet List v2.0 > > > See comments below. > > John Ladwig wrote: > > > > >>>>> On Mon, 2 Apr 2001 13:46:41 -0500 (CDT), Andrew > Molitor said: > > > > >> > - must support high transaction throughput > over highish > > >> > latency networks (read: must support > message streaming.) > > >> > > >> High transaction of the middlebox, the transport, the client, > > >> or the protocol itself. Remove high. > > > > Andrew> I don't understand this. If I have an excess 'high' in > > Andrew> there, my brain refuses to see it (which in no > way implies > > Andrew> that there isn't one -- we all know how our > brain locks up > > Andrew> on these things sometimes!) > > > > Suggest: > > > > - Midcom protocol must support high transaction throughput, even > > when the network path has significant latency. (read: must > > support message streaming.) > > I am trying to differentiate between protocol requirements and > operational requirements. So if we come up with a protocol > tomorrow what would constitute a high transaction throughput? > In my mind, throughput means how fast you process the requests > in a particular machine including the buffer size and complexity > of implementation. These are implementation issues and definitely > not protocolish. The transport requirements most probably would > mandate the support of TCP and UDP. How UDP would provide you > with high transaction throughput when there is traffic congestion? > As for message streaming, is that really a requirement or a > design decision? I believe that it is the latter. > > Let us focus on the functional requirements. Sigtran and MEGACO > looked into these issues before and I believe that they did > pretty good job addressing them. btw, I tried to see if SIP > has "high transaction throughput" in the requirements. Guess > what? It does not appear any where! > > > > > >> > - must support one or more strong > authentication models. > > >> > > >> Most firewall if not all implement IPSec. What is > the meaning of > > >> requiring more? > > >> > > >> > * - must support one or more privacy models. > > >> > > >> See the above comment. > > > > Andrew> IPSec is a wonderful thing, but it's unfair to > assume that > > Andrew> all clients will speak it, or that all clients > will speak > > Andrew> it in a manner that is currently interoperable with the > > Andrew> middleboxes. I confess that I haven't followed > IPSec that > > Andrew> closely, recently. Does it really solve the > > Andrew> application-to-application problem? I thought it focuses > > Andrew> more on host-to-host and net-to-net. > > > > You are correct, so far as I can tell. > > These are transport requirements and deployment issues which I > believe that IPSec can take of. This is the IETF where stacks > are developed. If necessary, make authentication and confidentiality > as transport requirements because they are not protocol requirements. > If you are going to require encryption at the application layer, > how do you expect to have high transaction throughput then? > > > Andrew> Anyways, it would be fine with me if MIDCOM wound up > > Andrew> stating that IPSec or TLS or something was a requirement > > Andrew> to meet these needs of the protocol. The point is, the > > Andrew> protocol needs authentication and privacy -- where they > > Andrew> come from is a problem to be solved soon, but not right > > Andrew> now! > > > > At the Minneapolis pre-conference Security Tutorial, Jeff Schiller > > explicitly stated that "must run over IPSec" is *not* a general > > solution for unsecured protocols which pass sensitive > information. In > > particular, he noted that it's not generally possible for an > > application to determine whether IPSec is in use, much less the > > specifics of the protection scheme in use to a given host. > > If that is the case, then why do we have IPSec in the first place? > IPSec is being used in the implementation of VPN which has more > reaching effect than just one protocol between two devices. > > > > > TLS is a rather different animal, and more appropriate to this > > application. However, TLS (re: RFC 2246) assumes a > reliable transport > > such as TCP. > > > > >> > Specific Operations/Scenarios > > >> > > > >> > Note that these are protocol requirements, not box > > >> > requirements. So, while the protocol must support > the ability > > >> > of a client to ask for a pinhole, the protocol also allows > > >> > for a middlebox to return 'NO - I am a NAT, dummy.' > > >> > > > >> > * - must support a client-to-server > transaction which returns > > >> > * the middlebox capabilities to the > client. These capabilities > > >> > * must include, but not be restricted to: > > >> > * - firewalling > > >> > * - NAT > > >> > * - NAT capabilities (ports > and stuff) > > >> > * - Plumbing information (where does NAT fit > > >> > * relative to other elements, specifically, > > >> > * THIS MATTERS!) > > >> > > >> I dont believe that it should be the case. The > capabilities your > > >> refer to are provisioning issues which are outside > the scope. The > > >> client should be able to know ahead of time what > services a middlebox > > >> supports and if makes a wrong request, then the > result should be > > >> service not supported and not this is what I support. > > > > Andrew> So far I seem to be the only member of the > 'Client should > > Andrew> be able to figure out what the Middlebox can do' camp. > > > > Andrew> If anyone else agrees with me, let me know! Otherwise, I > > Andrew> will assume that the WG collectively thinks Andrew is a > > Andrew> doofus, and I will cheerfully drop this from my little > > Andrew> list. > > > > In general, I'm (unsurprisingly) on the same page. More > specifically, > > since draft-ietf-midcom-scenarios-00.txt was published this morning, > > I'm even more on the same page. Unless I read it wrong, the first > > (2.1 - TCP server behind a firewall/NAT) scenario Christiane Huitema > > posits direct signalling from a "terminal" (to use H.323 > terminology) > > application to the midcom server. In the absence of site-specific > > mass-configuration of such applications, and assuming that this > > scenario is accepted by the WG, I think the midcom client should > > indeed be able to "figure out" what the midcom server/box > can control. > > > > > You can accomplish the same thing without the need to place > such a requirement on the middlebox. For example, consider the > following scenario. > > When the client registers with the middlebox, it could - Clients should not be allowed to communicate directly with a middlebox. Proxies/midcom controllers should be the only devices to communicate with a middlebox. - Internal clients may need to obtain NAT bindings just as they would today in a "traditional" scenario (where most internal clients are allowed to initiate communications with the outside world. In a situation like this, whether the midcom controller is internal to the client or external (on the outside), - the client should still receive its bindings and communicate with the midcom controller, since we are talking protocol specific control such as for SIP communications. - The midcom controller, whether implemented as a function on the middlebox or externally, will then communicate the pinholes/bindings on the middle box. For security the following should be adhered to in order to maintain integrity of the middlebox. This doesnt protect the proxy from being fooled into subverting the middlebox, but does shield the middlebox from direct control from any external client. - internal clients always communicate with the application proxy which initiates the midcom protocol - external clients always communicate with the application proxy to the internal clients. We are not touching the mechanisms to provide accountability between clients and application proxies but we do segregate the middlebox from direct control by folowing these guidelines. > request the services it needs. The middlebox would > authorize or deny the services accordingly without the need > to spill its guts. This way the client would know if it can > carry out its duties with that particular middlebox or not. > This state is global and there is no complexity in keeping > it in the client. The client needs to register anyway with > the middlebox before communications starts. > > regards > Abdallah > > _______________________________________________ > 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 Apr 23 08:33: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 IAA03880 for ; Mon, 23 Apr 2001 08:33: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 IAA05190; Mon, 23 Apr 2001 08:24: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 IAA05161 for ; Mon, 23 Apr 2001 08:24:42 -0400 (EDT) Received: from alemail1.firewall.lucent.com ([192.11.221.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03845 for ; Mon, 23 Apr 2001 08:24:40 -0400 (EDT) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3NCOeU03391 for ; Mon, 23 Apr 2001 08:24:40 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3NCOdP03378 for ; Mon, 23 Apr 2001 08:24:39 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA08777; Mon, 23 Apr 2001 14:24:38 +0200 (MET DST) Cc: Melinda Shore , Scott Brim , midcom@ietf.org Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA08760; Mon, 23 Apr 2001 14:24:35 +0200 (MET DST) Message-ID: <3AE41F7C.43EA1C01@lucent.com> Date: Mon, 23 Apr 2001 14:26:36 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema Original-CC: Melinda Shore , Scott Brim , midcom@ietf.org Subject: Re: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) 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 agree we do not need to open it up. We do however need to identify the functions of the middlebox and their parameters to see what the MIDCOM protocol needs to express. Paul Christian Huitema wrote: > > I don't believe that "opening the guts of the box" is particularly > useful. If we start from the scenarios document, we see only one > function of relevance, the passing/blocking/natting of packets based on > addresses and port numbers. We should concentrate on that. > > -- Christian Huitema -- Paul Sijben Tel:+31 356874774 Lucent Technologies Message:+31 208702874 Forward Looking Work Fax: +31 208702874 Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 23 10:25: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 KAA04808 for ; Mon, 23 Apr 2001 10:25: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 KAA07384; Mon, 23 Apr 2001 10:17: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 KAA07357 for ; Mon, 23 Apr 2001 10:17:18 -0400 (EDT) Received: from df-inet1.exchange.microsoft.com ([131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04696 for ; Mon, 23 Apr 2001 10:17:15 -0400 (EDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Mon, 23 Apr 2001 07:17:30 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Apr 2001 07:16:40 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Mon, 23 Apr 2001 07:15:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4693.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Date: Mon, 23 Apr 2001 07:15:53 -0700 Message-ID: Thread-Topic: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Thread-Index: AcDL8F7vwK6V+3ZSRrWv/apl68+PswADrRIg From: "Christian Huitema" To: "Paul Sijben" Cc: X-OriginalArrivalTime: 23 Apr 2001 14:15:54.0381 (UTC) FILETIME=[E87A6BD0:01C0CBFF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07358 Sender: 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 In fact, I don't agree with that either. We can agree that the protocol should be extensible to handle functions that are outside the "initial scenarios", but we do not need to actually specify these functions. From a scenario analysis, we need: 1) To open a hole based on a combination of addresses, protocol type, and port numbers, any of which can possibly be replaced by wild cards. 2) To obtain the "external" mapping of an address + port pair. That is about the end of our "functional" requirements. We have then operational requirements, e.g. fate sharing or soft state, and security requirements, e.g. authenticate the requestor of a command. -- Christian Huitema > From: Paul Sijben [mailto:sijben@lucent.com] > > I agree we do not need to open it up. We do however need to identify the > functions of the middlebox and their parameters to see what the MIDCOM > protocol needs to express. > > Paul > > Christian Huitema wrote: > > > > I don't believe that "opening the guts of the box" is particularly > > useful. If we start from the scenarios document, we see only one > > function of relevance, the passing/blocking/natting of packets based on > > addresses and port numbers. We should concentrate on that. > > > > -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Apr 23 10:43: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 KAA04981 for ; Mon, 23 Apr 2001 10:43: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 KAA07772; Mon, 23 Apr 2001 10:35: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 KAA07739 for ; Mon, 23 Apr 2001 10:35:05 -0400 (EDT) Received: from Mitel.COM ([198.53.180.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04937 for ; Mon, 23 Apr 2001 10:35:03 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id KAA22317; Mon, 23 Apr 2001 10:35:01 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A37.00501ABB ; Mon, 23 Apr 2001 10:34:57 -0400 X-Lotus-FromDomain: MITEL To: "Christian Huitema" cc: "Paul Sijben" , midcom@ietf.org Message-ID: <85256A37.00501981.00@kanmta01.software.mitel.com> Date: Mon, 23 Apr 2001 10:34:54 -0400 Subject: RE: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: 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: Tom Gray@MITEL on 04/23/2001 10:34 AM There should also be distinct consideration of stakeholder and non-functional requirements which seem to be being confounded with functional requirements in the discussion. There should also be a distinct category of 'non-functional' requirements that describe how the functional requirements will operate. Non-functionals describe the operation of a system but do not dictate it. So all issues of quality, extendibility, responsivity ... fall within the NFR purview. They should be kept distinct because they are not firmly bound to any set of functional requirements or proposed solutions to these requirements. They act as parameters which can be used to characterise the match of any proposed solution or set of functional requirements to the stakeholder requirements which have been discovered earlier. "Christian Huitema" on 04/23/2001 10:15:53 AM To: "Paul Sijben" cc: midcom@ietf.org (bcc: Tom Gray/Kan/Mitel) Subject: RE: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0) In fact, I don't agree with that either. We can agree that the protocol should be extensible to handle functions that are outside the "initial scenarios", but we do not need to actually specify these functions. From a scenario analysis, we need: 1) To open a hole based on a combination of addresses, protocol type, and port numbers, any of which can possibly be replaced by wild cards. 2) To obtain the "external" mapping of an address + port pair. That is about the end of our "functional" requirements. We have then operational requirements, e.g. fate sharing or soft state, and security requirements, e.g. authenticate the requestor of a command. -- Christian Huitema > From: Paul Sijben [mailto:sijben@lucent.com] > > I agree we do not need to open it up. We do however need to identify the > functions of the middlebox and their parameters to see what the MIDCOM > protocol needs to express. > > Paul > > Christian Huitema wrote: > > > > I don't believe that "opening the guts of the box" is particularly > > useful. If we start from the scenarios document, we see only one > > function of relevance, the passing/blocking/natting of packets based on > > addresses and port numbers. We should concentrate on that. > > > > -- 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