From midcom-admin@ietf.org Thu Feb 1 00: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 AAA07121 for ; Thu, 1 Feb 2001 00:35:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20271; Thu, 1 Feb 2001 00:25:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20240 for ; Thu, 1 Feb 2001 00:25:21 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07029 for ; Thu, 1 Feb 2001 00:25:22 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id AAA21043; Thu, 1 Feb 2001 00:24:58 -0500 (EST) Message-Id: <200102010524.AAA21043@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: smd@ebone.net (Sean Doran) cc: midcom@ietf.org, huitema@Exchange.Microsoft.com Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Thu, 01 Feb 2001 05:26:56 +0100." <20010201042656.9322B817@sean.ebone.net> Date: Thu, 01 Feb 2001 00:24:58 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > | The point being that if you have an arbitrary bunch of firewalls and > | NATs between any two points, then you are forced into telephone-like > | "call set-up" scenarios, which don't really scale to large groups, > | specially when the application consists of sporadic messages to > | arbitrary destinations. > > So the middle box joins a multicast group and forwards on behalf > of the things behind it messages to the group, who said anything about multicast? Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 01:26: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 BAA09625 for ; Thu, 1 Feb 2001 01:26:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25521; Thu, 1 Feb 2001 01:08:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25443 for ; Thu, 1 Feb 2001 01:08:33 -0500 (EST) Received: from web1405.mail.yahoo.com (web1405.mail.yahoo.com [128.11.23.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07610 for ; Thu, 1 Feb 2001 01:08:33 -0500 (EST) Received: (qmail 18753 invoked by uid 60001); 1 Feb 2001 06:08:33 -0000 Message-ID: <20010201060833.18752.qmail@web1405.mail.yahoo.com> Received: from [24.4.254.105] by web1405.mail.yahoo.com; Wed, 31 Jan 2001 22:08:33 PST Date: Wed, 31 Jan 2001 22:08:33 -0800 (PST) From: Pyda Srisuresh Subject: RE: [midcom] WG scope/deliverables To: midcom@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Christian Huitema wrote: > Well, maybe we should keep the Midcom discussion in Midcom without > spamming the whole IETF list... > Sounds good. > I actually believe that Keith has a point. The point is not whether or > not we deal with NAT; we know we have to, at least in the short term. > The real point is that we have to aim for simplicity. Basically, Midcom Agreed. > can do one of two things: study a grand design for a new Internet > architecture based on a patchwork of firewalled networks, or come out > with a short term fix for crossing the NAT and firewalls that we have > today. I have absolutely no confidence that an IETF working group could > solve the general problem in any reasonable time frame, and thus I > believe we should focus on a simple short term solution. > Agreed. I dont believe, we are assuming a paradigm in which there are multiple NATs and firewalls along the way. Certainly, NAT/firewall discovery is out of the ascope of this work group. In my mind, we are merely pursuing a much simpler scenario in which you have a single middlebox (running NAT or firewall) along the application route. This, I believe, is basicaly the applicability statement. > I believe that the short term requirements are quite simple. Many users > want to run real-time applications such as VoIP, or peer-to-peer > applications such as Napster. The real-time applications require that > one establish a "pin-hole" in the firewalls to let the media flow pass. > The peer-to-peer application require that the host behind the NAT can > publish an IP address and a port, and receive TCP connections to that > port. > > Both requirements can actually be met by the current generation of > firewall and NAT products. Firewalls can open a hole based on a > "5-tuple"; NAT products all allow for some form of "DMZ" or "service > host" configuration that allow users to specify that an inside host will > serve a specific outside port. The problem is thus not to create a new > functionality, but to create a unified, standard way to exercize an > existing functionality. Now, that should be a problem that an IETF WG > can solve... By adapting the new MIDCOM protocol, the NAT and firewall devices will be able to support newer applications (as listed above) they have not been able to support thus far. But, we certainly are not changing the fundamental NAT and firewall functions in these devices. > > -- Christian Huitema > Thanks. regards, suresh __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 02:37: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 CAA21251 for ; Thu, 1 Feb 2001 02:37:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27936; Thu, 1 Feb 2001 02:26:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27888 for ; Thu, 1 Feb 2001 02:26:08 -0500 (EST) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21110 for ; Thu, 1 Feb 2001 02:26:09 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA11397; Thu, 1 Feb 2001 02:29:01 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 02:22:32 -0500 Message-ID: From: Jonathan Rosenberg To: "'Pyda Srisuresh'" , midcom@ietf.org Subject: RE: [midcom] WG scope/deliverables Date: Thu, 1 Feb 2001 02:22:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Thursday, February 01, 2001 1:09 AM > To: midcom@ietf.org > Subject: RE: [midcom] WG scope/deliverables > > > --- Christian Huitema wrote: > > Well, maybe we should keep the Midcom discussion in Midcom without > > spamming the whole IETF list... > > > > Sounds good. > > > I actually believe that Keith has a point. The point is not > whether or > > not we deal with NAT; we know we have to, at least in the > short term. > > The real point is that we have to aim for simplicity. > Basically, Midcom > > Agreed. > > > can do one of two things: study a grand design for a new Internet > > architecture based on a patchwork of firewalled networks, > or come out > > with a short term fix for crossing the NAT and firewalls > that we have > > today. I have absolutely no confidence that an IETF working > group could > > solve the general problem in any reasonable time frame, and thus I > > believe we should focus on a simple short term solution. > > > > Agreed. I dont believe, we are assuming a paradigm in which there are > multiple NATs and firewalls along the way. Certainly, NAT/firewall > discovery is out of the ascope of this work group. > > In my mind, we are merely pursuing a much simpler scenario in which > you have a single middlebox (running NAT or firewall) along the > application route. This, I believe, is basicaly the applicability > statement. Yes. I really like the notion of characterizing the problem of one of "decomposition". Right now, existing firewall and NAT products have application layer functionality in them, which they use to examine/rewrite application layer packets, and also they have a pure transport layer piece, which just examines/mucks around with the 5-tuples in IP packets. The architecture we are describing here allows me to decompose the application layer intelligence external to the fast packet IP processing. The decomposition is identical to megaco. In megaco, a gateway (which has application layer, i.e., signaling, and media path processing) is decomposed into a pure application component, usually software (called the MGC), and a pure media processing piece, called the MG. Between them is a protocol for control/reporting, and thats megaco. Thats what we want here. We want to extract the application layer intelligence into one component, and maintain the application unaware (at least, unaware beyond port numbers), fast packet processing in a separate component. We put a protocol between them, and thats the protocol we are discussing here. Whether the application aware component is an end system, like a PC application, or whether its a network application device, like a SIP proxy or H.323 gatekeeper, is orthogonal, although it has impacts on the security models, as we have discussed. The decomposition viewpoint (and thats all it is) helps clarify the scope of the problem, I think. -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 Thu Feb 1 03:45:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22098 for ; Thu, 1 Feb 2001 03:45:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28933; Thu, 1 Feb 2001 03:34:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28904 for ; Thu, 1 Feb 2001 03:34:36 -0500 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22008 for ; Thu, 1 Feb 2001 03:34:35 -0500 (EST) Received: from cisco.com (elear-dsl4.cisco.com [10.19.144.53]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id AAA07175; Thu, 1 Feb 2001 00:34:04 -0800 (PST) Message-ID: <3A791F93.6C9F7657@cisco.com> Date: Thu, 01 Feb 2001 00:34:27 -0800 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Pyda Srisuresh'" , midcom@ietf.org, march@external.cisco.com Subject: Re: [midcom] WG scope/deliverables 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 Jonathan Rosenberg wrote: > [Pyda] > > In my mind, we are merely pursuing a much simpler scenario in which > > you have a single middlebox (running NAT or firewall) along the > > application route. This, I believe, is basicaly the applicability > > statement. Jonathan: > Yes. > [...] > Whether the application aware component is an end system, like a PC > application, or whether its a network application device, like a SIP proxy > or H.323 gatekeeper, is orthogonal, although it has impacts on the security > models, as we have discussed. Christian, Keith, and others have pointed out that the hard part is in the listener portion of all of this. It is one thing to have an H.323 gateway listen for call set up and then communicate that information to both the firewall and the end. It is quite something else if there is no notion of a gatekeeper or gateway. How do you listen() such that the firewall "gets it"? And then, in a large deployment of multiple middle boxes, which firewall needs to get it? And then what are the ramifications for the middle box? If the end application registers with all middleboxes and requires NAT functionality, then it will need to be aware of multiple addresses that it could have, assuming it would need to know the mapping for one reason or another. Let's assume that the service is established. This requires that the middlebox actually manage DNS to allow for the appropriate management of translations. For example: iHOST=10.1.1.1 oHOST=128.6.4.4 oHOST wants to communicate with iHOST through the internet, but iHOST is not addressable. That requires a middlebox to establish an A record for iHOST, and bind a given address / port translation. OR there's an ALG. Messy messy. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 05:09:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22781 for ; Thu, 1 Feb 2001 05:09:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29591; Thu, 1 Feb 2001 04:56:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29563 for ; Thu, 1 Feb 2001 04:55:59 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22522 for ; Thu, 1 Feb 2001 04:55:57 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 9C84B817; Thu, 1 Feb 2001 10:55:58 +0100 (CET) To: lear@cisco.com Subject: Re: [midcom] WG scope/deliverables Cc: midcom@ietf.org Message-Id: <20010201095558.9C84B817@sean.ebone.net> Date: Thu, 1 Feb 2001 10:55:58 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: 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 Lear writes: | oHOST wants to communicate with iHOST through the internet, but iHOST is | not addressable. You mean iHost's own idea of its own address is not the same as oHost's idea of iHost's address, yes? oHost surely thinks iHost's address is the address of the outside interface of the middlebox. | That requires a middlebox to establish an A record for | iHOST, and bind a given address / port translation. | |... | | Messy messy. RFC 2782 makes it less messy messy, and indeed, the SRV RRs should be issued in a way that mirrors what the middle box offers to the "outside". There's nothing particularly new in having the middle box doing DNS for subdomains which have hosts living on the "inside". Sean. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From mailman-owner@ietf.org Thu Feb 1 05:27:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23112 for ; Thu, 1 Feb 2001 05:27:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17026 for ; Thu, 1 Feb 2001 05:27:24 -0500 (EST) Date: Thu, 1 Feb 2001 05:27:24 -0500 (EST) Message-Id: <200102011027.FAA17026@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: midcom-web-archive@ns.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, midcom-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for midcom-web-archive@optimus.ietf.org: List Password // URL ---- -------- midcom@ietf.org yYVU http://www.ietf.org/mailman/options/midcom/midcom-web-archive@optimus.ietf.org From midcom-admin@ietf.org Thu Feb 1 07:44:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25165 for ; Thu, 1 Feb 2001 07:44:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22745; Thu, 1 Feb 2001 07:32:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27520 for ; Thu, 1 Feb 2001 01:35:58 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10865; Thu, 1 Feb 2001 01:35:53 -0500 (EST) Received: from isi.edu (ras34.isi.edu [128.9.176.134]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id WAA19501; Wed, 31 Jan 2001 22:29:13 -0800 (PST) Message-ID: <3A7901DF.441EB775@isi.edu> Date: Wed, 31 Jan 2001 22:27:43 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ed Gerck CC: Keith Moore , "J. Noel Chiappa" , midcom@ietf.org, ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.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 Ed Gerck wrote: > > Keith Moore wrote: > > > I expressed an opinion that this group should confine itself to addressing > > short-term goals rather than trying to make NATs a part of the Internet > > architecture. > > NATs are already part of the Internet, and gaining share. An alternate perspective is that the Internet continues to (mostly) work despite the presence of NATs. It is a paradox to begin one standard by selectively omitting current standards (e.g., RFC1122). Joe _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 07:44: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 HAA25181 for ; Thu, 1 Feb 2001 07:44:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22799; Thu, 1 Feb 2001 07:33:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28834 for ; Thu, 1 Feb 2001 03:30:43 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21985 for ; Thu, 1 Feb 2001 03:30:42 -0500 (EST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Feb 2001 08:27:22 +0000 To: Ed Gerck cc: Keith Moore , "J. Noel Chiappa" , midcom@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Wed, 31 Jan 2001 15:05:34 PST." <3A789A3E.63620B61@nma.com> Date: Thu, 01 Feb 2001 08:27:22 +0000 Message-ID: <29151.981016042@cs.ucl.ac.uk> From: Jon Crowcroft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org NATs are very useful sensible local optimisation devices to remove the need for a number of other more complicated solutions - most of the more complicated solutions are architectural and internetworking solutions which NAT are not address translation, as part of a set of techniques (address aggregation, filtering, dynamic address allocation and lease/lifetime control, address scoping, whether for unicast or multicast) should be part of the midcom discussion consideration of any protocol for global coordination of address translation (e.g. so you can do 2 way or n-way natting, leads to the conclusion that perhaps other techniques (e.g. ipv6) are easier or actually no different (pace, yakov:-) in terms of funcitonality (e.g. a distribution and synchronisation protocol why i keep mentioning GSE is that it does _partial_ NAT, which is dfefinitily worth pursuing imho In message <3A789A3E.63620B61@nma.com>, Ed Gerck typed: >> >> >>Keith Moore wrote: >> >>> I expressed an opinion that this group should confine itself to addressing >>> short-term goals rather than trying to make NATs a part of the Internet >>> architecture. >> >>NATs are already part of the Internet, and gaining share. >> >>> I said this because I've looked at the problem quite extensively. >>> The more I have done so, the more have concluded that there's no way >>> to restore the valuable functionality that NATs have removed from the >>> Internet without providing another global address space, and that it's >>> much more efficient and less painful to embellish the NATs to become >>> IPv6 routers than it is to embellish both the NATs and applications to >>> support a segmented address space. >> >>You miss at least one other possibility. If it is possible to develop >>an addressing scheme that works in a heterogeneous network, then >>we can have point-to-point functionality across system borders and >>do not require a homogeneous address space to do so. Now, if you >>look into the science of Thermodynamics (for example) you will see that >>this involves a meta-problem that was already solved two centuries ago. >> >>NATs are a consequence of a choice rather than makers of a choice. >>The choice is to use heterogeneous networks. I contend that the reasons >>for this choice can be found in Nature -- for example, to adapt to local needs >>without imposing more expensive non-local changes. This is not an Internet >>phenomenon, it is IMO the reflection of a more general principle. >> >>BTW, I agree with Noel's solution that a NAT-haters list might be in order. >>Maybe you could call it NAT-not list, to avoid the "hate". Meanwhile, the >>rest of the world would continue to pursue ways to deal with the real-world >>needs answered by NATs (and things to come). >> >>Cheers, >> >>Ed Gerck >> >> cheers jon _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 07:46: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 HAA25251 for ; Thu, 1 Feb 2001 07:46:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22523; Thu, 1 Feb 2001 07:28:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16141 for ; Wed, 31 Jan 2001 18:06:15 -0500 (EST) Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27469 for ; Wed, 31 Jan 2001 18:06:14 -0500 (EST) Received: (qmail 18713 invoked from network); 31 Jan 2001 23:06:17 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 31 Jan 2001 23:06:17 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Wed, 31 Jan 2001 17:06:14 -0600 Message-ID: <3A789A3E.63620B61@nma.com> Date: Wed, 31 Jan 2001 15:05:34 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: "J. Noel Chiappa" , midcom@ietf.org, ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables References: <200101312118.QAA15700@astro.cs.utk.edu> 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 Keith Moore wrote: > I expressed an opinion that this group should confine itself to addressing > short-term goals rather than trying to make NATs a part of the Internet > architecture. NATs are already part of the Internet, and gaining share. > I said this because I've looked at the problem quite extensively. > The more I have done so, the more have concluded that there's no way > to restore the valuable functionality that NATs have removed from the > Internet without providing another global address space, and that it's > much more efficient and less painful to embellish the NATs to become > IPv6 routers than it is to embellish both the NATs and applications to > support a segmented address space. You miss at least one other possibility. If it is possible to develop an addressing scheme that works in a heterogeneous network, then we can have point-to-point functionality across system borders and do not require a homogeneous address space to do so. Now, if you look into the science of Thermodynamics (for example) you will see that this involves a meta-problem that was already solved two centuries ago. NATs are a consequence of a choice rather than makers of a choice. The choice is to use heterogeneous networks. I contend that the reasons for this choice can be found in Nature -- for example, to adapt to local needs without imposing more expensive non-local changes. This is not an Internet phenomenon, it is IMO the reflection of a more general principle. BTW, I agree with Noel's solution that a NAT-haters list might be in order. Maybe you could call it NAT-not list, to avoid the "hate". Meanwhile, the rest of the world would continue to pursue ways to deal with the real-world needs answered by NATs (and things to come). Cheers, Ed Gerck _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 08:23: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 IAA26626 for ; Thu, 1 Feb 2001 08:23:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23369; Thu, 1 Feb 2001 08:13:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23338 for ; Thu, 1 Feb 2001 08:13:10 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26255 for ; Thu, 1 Feb 2001 08:13:09 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id IAA21151; Thu, 1 Feb 2001 08:12:51 -0500 (EST) Message-Id: <200102011312.IAA21151@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: smd@ebone.net (Sean Doran) cc: lear@cisco.com, midcom@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Thu, 01 Feb 2001 10:55:58 +0100." <20010201095558.9C84B817@sean.ebone.net> Date: Thu, 01 Feb 2001 08:12:51 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > | oHOST wants to communicate with iHOST through the internet, but iHOST is > | not addressable. > > You mean iHost's own idea of its own address is not the same as > oHost's idea of iHost's address, yes? oHost surely thinks iHost's > address is the address of the outside interface of the middlebox. yes, but in general iHost doesn't know which view oHost has - whether it be inside or outside of the NAT (and this is a simplistic view with only one NAT) > | That requires a middlebox to establish an A record for > | iHOST, and bind a given address / port translation. > | > |... > | > | Messy messy. > > RFC 2782 makes it less messy messy, and indeed, the SRV RRs should > be issued in a way that mirrors what the middle box offers to the "outside". > There's nothing particularly new in having the middle box doing DNS for > subdomains which have hosts living on the "inside". SRV RRs only apply to applications which are specified to use them. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 09:45: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 JAA28288 for ; Thu, 1 Feb 2001 09:45:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25022; Thu, 1 Feb 2001 09:33:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24993 for ; Thu, 1 Feb 2001 09:33:54 -0500 (EST) Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27967 for ; Thu, 1 Feb 2001 09:33:52 -0500 (EST) Received: from rac2.wam.umd.edu (IDENT:root@rac2.wam.umd.edu [128.8.10.142]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA21184; Thu, 1 Feb 2001 09:33:52 -0500 (EST) Received: from rac2.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac2.wam.umd.edu (8.9.3/8.9.3) with SMTP id JAA01770; Thu, 1 Feb 2001 09:33:52 -0500 (EST) Received: from localhost (karir@localhost) by rac2.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA01766; Thu, 1 Feb 2001 09:33:52 -0500 (EST) X-Authentication-Warning: rac2.wam.umd.edu: karir owned process doing -bs Date: Thu, 1 Feb 2001 09:33:52 -0500 (EST) From: Manish Karir To: Pyda Srisuresh cc: midcom@ietf.org Subject: RE: [midcom] WG scope/deliverables In-Reply-To: <20010201060833.18752.qmail@web1405.mail.yahoo.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 does the defination of middle box include - proxies/caches? manish karir On Wed, 31 Jan 2001, Pyda Srisuresh wrote: > > By adapting the new MIDCOM protocol, the NAT and firewall devices will > be able to support newer applications (as listed above) they have not > been able to support thus far. But, we certainly are not changing the > fundamental NAT and firewall functions in these devices. > > Thanks. > > regards, > suresh _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 10:08: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 KAA28869 for ; Thu, 1 Feb 2001 10:08:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25394; Thu, 1 Feb 2001 09:56:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25363 for ; Thu, 1 Feb 2001 09:56:49 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28557 for ; Thu, 1 Feb 2001 09:56:46 -0500 (EST) 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 GAA26801 for ; Thu, 1 Feb 2001 06:56:20 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id AFT02899; Thu, 1 Feb 2001 06:56:16 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.90 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: <14969.29581.793958.70520@localhost.localdomain> Date: Thu, 1 Feb 2001 09:32:45 -0500 To: Subject: RE: [midcom] WG scope/deliverables In-Reply-To: References: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 31 Jan 2001 at 15:52 -0800, Christian Huitema apparently wrote: > The real point is that we have to aim for simplicity. Basically, Midcom > can do one of two things: study a grand design for a new Internet > architecture based on a patchwork of firewalled networks, or come out > with a short term fix for crossing the NAT and firewalls that we have > today. I have absolutely no confidence that an IETF working group could > solve the general problem in any reasonable time frame, and thus I > believe we should focus on a simple short term solution. That's why we've been stressing requirements. We probably don't even need a new protocol. On the other hand a framework which essentially captures this discussion, giving a perspective on what we're doing and where we fit into the longer term engineering of the Internet, does not detract from that. Yes, you need to keep engineers reined in or they start solving problems when they're supposed to be figuring out needs, but that's normal. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 11:22: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 LAA00374 for ; Thu, 1 Feb 2001 11:22:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26979; Thu, 1 Feb 2001 11:10:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26808 for ; Thu, 1 Feb 2001 11:00:39 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29818; Thu, 1 Feb 2001 11:00:35 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14OM2g-00046P-00; Thu, 01 Feb 2001 15:53:02 +0000 Date: Thu, 1 Feb 2001 15:53:01 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Ed Gerck cc: midcom@ietf.org, ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-Reply-To: <3A789A3E.63620B61@nma.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, 31 Jan 2001, Ed Gerck wrote: > You miss at least one other possibility. If it is possible to develop > an addressing scheme that works in a heterogeneous network, then > we can have point-to-point functionality across system borders and > do not require a homogeneous address space to do so. Now, if you > look into the science of Thermodynamics (for example) you will see that > this involves a meta-problem that was already solved two centuries ago. Explain. > NATs are a consequence of a choice rather than makers of a choice. > The choice is to use heterogeneous networks. NATs fake a homogeneous address space for disjoint/overlapping *homogeneous networks*. You just layer IP over the top of the heterogeneous networks - so we already have that addressing scheme you want. NATs are primarily a consequence of heterogeneous administration with short-term local-optimisation goals that dictate use of homogeneous network technology. (Address space shortages are also a result of heterogeneous administration of a homogeneous and limited resource. As are most things.) Considered use of truly heterogeneous networks does not offer the local optimisation NATs do (more translation, gateway maintenance), and is rejected. > I contend that the reasons for this choice can be found in Nature well, yes. everything can be found in nature. > -- for example, to adapt to local needs > without imposing more expensive non-local changes. This is not an Internet > phenomenon, it is IMO the reflection of a more general principle. Oh, right. Since we're waffling; http://pespmc1.vub.ac.be/SUBOPTIM.html and Gleick's 'Faster' (and Vinge's 'Deepness in the Sky', for that matter) make some interesting statements and predictions about the system-wide dangers of local optimisations. The zeroth law of thermodynamics does not, IMO; entropy analogies can be highly misleading. It's useful to reflect on why we should be designing protocols with a lot of overhead, redundancy, and slack in them. Contrast the success, adaptability, longevity and utility of the ever-so-slack http with that of the bit-efficient gopher. The lack of slack in the ATM header. Or the slack in the GSM control channel that led almost by accident to SMS. If there's no slack, there's no serendipity, no escaping the local minimum by subverting it. That doesn't have much to do with anything other than the work required to handle the protocol reliably in NAT, though. L. IETF: optimising everything into a dead-end local minimum since 1986. PGP _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 13:17: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 NAA05371 for ; Thu, 1 Feb 2001 13:17:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29007; Thu, 1 Feb 2001 13:06:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28976 for ; Thu, 1 Feb 2001 13:06:12 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04884 for ; Thu, 1 Feb 2001 13:06:10 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA11698; Thu, 1 Feb 2001 10:05:55 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f11I5eT22894; Thu, 1 Feb 2001 10:05:40 -0800 (PST) Message-ID: <3A79A58B.63711C16@cisco.com> Date: Thu, 01 Feb 2001 10:06:03 -0800 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Doran CC: midcom@ietf.org Subject: Re: [midcom] WG scope/deliverables References: <20010201095558.9C84B817@sean.ebone.net> 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 The argument is one of complexity. And while you mention subdomains, if you're a provider, GFL trying to manage all that. But... I did omit the idea of using SRV records, which solves the "all I got is this stinking packet" problem without a hint as to what it is meant for, or with everyone wanting to use port 80, and all I got is this one address. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 13:30: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 NAA06012 for ; Thu, 1 Feb 2001 13:30:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29334; Thu, 1 Feb 2001 13:19:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29211 for ; Thu, 1 Feb 2001 13:18:16 -0500 (EST) Received: from postal.redback.com (hiddenuser@prattle.redback.com [155.53.12.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05406; Thu, 1 Feb 2001 13:18:15 -0500 (EST) Received: from red.redback.com (red.redback.com [155.53.42.56]) by postal.redback.com (Postfix) with ESMTP id 0F1FCB76784; Thu, 1 Feb 2001 10:18:15 -0800 (PST) Received: from red.redback.com by red.redback.com (8.9.3) id KAA55749; Thu, 1 Feb 2001 10:18:06 -0800 (PST) Message-Id: <200102011818.KAA55749@red.redback.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: L.Wood@eim.surrey.ac.uk Cc: Ed Gerck , midcom@ietf.org, ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Thu, 01 Feb 2001 15:53:01 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 2001 10:18:06 -0800 From: Greg Minshall Sender: 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 some of the discussion, esp. yesterday, i had thoughts of deriving an anti-NAT polemic and posting it. i planned on mentioning all of the other brain-dead, obsolete technologies "we" (IP) had in the past ignored, and how we had triumphed while they had died off. i was thinking of things like IBM mainframes, BSC, SDLC, and ultimately got around to thinking of things "in our community" such as UUCP over asynch (mostly) phone lines, etc. but as i thought of it, i realized that what "we" successfully ignored in the past were things that had little use (the ISO acronym popped up in my mind). things that were heavily used, we somehow brought into the fold and, in some sense, stepped on their shoulders on our way to "the world of greater connectivity". the examples are numerous, and happened in different ways. "we" invented ways of interconnecting (at least at the level of e-mail, the killer app of the 80s) with IBM mainframes, VMS boxes, etc. we ran IP over BSC and SDLC. we invented MX records, as well as bizarre addressing formats (!%.etc.), to interconnect between the SMTP world and the UUCP world. i guess if i think anything about all that, it is that if NATs are ubiquitous, we should figure out how to deal with them. and, that (hopefully), we will achieve the "greater interconnectivity" on top of, and to some extent in spite of NATs. cheers, Greg Minshall _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 13:38: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 NAA06469 for ; Thu, 1 Feb 2001 13:38:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29294; Thu, 1 Feb 2001 13:19:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29080 for ; Thu, 1 Feb 2001 13:10:50 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05062; Thu, 1 Feb 2001 13:10:49 -0500 (EST) Received: from DC-DESK.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA16913; Thu, 1 Feb 2001 10:08:41 -0800 Message-Id: <5.0.2.1.2.20010201100341.02c775d8@dcrocker.songbird.com> X-Sender: dhc2@dcrocker.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 01 Feb 2001 10:05:39 -0800 To: Ed Gerck From: Dave Crocker Subject: Re: [midcom] WG scope/deliverables Cc: Keith Moore , "J. Noel Chiappa" , midcom@ietf.org, ietf@ietf.org In-Reply-To: <3A789A3E.63620B61@nma.com> References: <200101312118.QAA15700@astro.cs.utk.edu> 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 At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: >You miss at least one other possibility. If it is possible to develop >an addressing scheme that works in a heterogeneous network, then >we can have point-to-point functionality across system borders and >do not require a homogeneous address space to do so. There is roughly 30 years of experience in this realm that suggests otherwise. The difference between theory and practise is practise. If you wish to formulate a detailed technical specification, and subject it to community review and testing, perhaps you will indeed show show us an approach that will work. Until then, your suggestion is just an untested theory. d/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 14:03: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 OAA07866 for ; Thu, 1 Feb 2001 14:03:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29880; Thu, 1 Feb 2001 13:52:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29847 for ; Thu, 1 Feb 2001 13:52:57 -0500 (EST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07305; Thu, 1 Feb 2001 13:52:56 -0500 (EST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 01 Feb 2001 11:52:12 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 01 Feb 2001 11:52:03 -0700 From: "Hilarie Orman" To: , Cc: , , , Subject: Re: [midcom] WG scope/deliverables Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA29848 Sender: 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 Dave Cheriton's TRIAD is an example of such a proposal. Hilarie >>> Dave Crocker 02/01/01 11:05AM >>> At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: >You miss at least one other possibility. If it is possible to develop >an addressing scheme that works in a heterogeneous network, then >we can have point-to-point functionality across system borders and >do not require a homogeneous address space to do so. There is roughly 30 years of experience in this realm that suggests otherwise. The difference between theory and practise is practise. If you wish to formulate a detailed technical specification, and subject it to community review and testing, perhaps you will indeed show show us an approach that will work. Until then, your suggestion is just an untested theory. d/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 16:33:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12036 for ; Thu, 1 Feb 2001 16:33:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02272; Thu, 1 Feb 2001 16:13:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02241 for ; Thu, 1 Feb 2001 16:13:25 -0500 (EST) Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11754 for ; Thu, 1 Feb 2001 16:13:23 -0500 (EST) Received: from rac3.wam.umd.edu (IDENT:root@rac3.wam.umd.edu [128.8.10.143]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id QAA04233; Thu, 1 Feb 2001 16:13:24 -0500 (EST) Received: from rac3.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac3.wam.umd.edu (8.9.3/8.9.3) with SMTP id QAA11349; Thu, 1 Feb 2001 16:13:24 -0500 (EST) Received: from localhost (karir@localhost) by rac3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id QAA11345; Thu, 1 Feb 2001 16:13:24 -0500 (EST) X-Authentication-Warning: rac3.wam.umd.edu: karir owned process doing -bs Date: Thu, 1 Feb 2001 16:13:24 -0500 (EST) From: Manish Karir To: midcom@ietf.org cc: brian@icair.org In-Reply-To: <200102011817.KAA19930@boreas.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [midcom] Re: I-D ACTION:draft-carpenter-midtax-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 Brian, Overall I thought this was quite a good start for the midcom group, finally we can atleast all try to agree on what a middle box is?. and what different types they can be.. However, I thought the section on TCP spoofers was somewhat inaccurate... section 2.1.5 I dont think its correct to say that TCP spoofers are mainly propritary, some implementations are freely available..moreover, it is also incorrect to say that they have been charaterized only when they introduce interoperability problems with standard TCP. TCP spoofers have been studied quite extensively. Correct implementations interoperate quite seamlessly with standard TCP. It is also wrong to say that they introduce not only TCP errors, but also changes in TCP adaptive behaviour. Correct implementations do not introduce any TCP errors, and the changes that the introduce in TCP behavior are intentional and desirable. Note: they are only used in cases where the modifications are desired. A few references: Snoop Protocol http://www.cs.berkeley.edu/~hari/papers/snoop.html TCP Connection Splitting http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_TR_99-34/CSHCN_TR_99-34.phtml http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_TR_99-11/CSHCN_TR_99-11.phtml http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_MS_99-7/CSHCN_MS_99-7.phtml manish karir On Thu, 1 Feb 2001, Bob Braden wrote: > _____________________________________________________________ > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Middle boxes: taxonomy and issues > Author(s) : B. Carpenter > Filename : draft-carpenter-midtax-00.txt > Pages : 15 > Date : 30-Jan-01 > > This document is intended as input to IETF discussion about 'middle > boxes' - defined as any intermediary box performing functions apart > from normal, standard functions of an IP router on the data path > between a source host and destination host. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-midtax-00.txt _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 17:13: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 RAA12885 for ; Thu, 1 Feb 2001 17:13:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03049; Thu, 1 Feb 2001 17:02:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03019 for ; Thu, 1 Feb 2001 17:02:00 -0500 (EST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12636 for ; Thu, 1 Feb 2001 17:01:57 -0500 (EST) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id RAA21200; Thu, 1 Feb 2001 17:01:44 -0500 (EST) Posted-Date: Thu, 01 Feb 2001 17:05:54 -0500 Message-Id: <10102012205.AA17209@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Thu, 1 Feb 01 17:05:59 EST To: Manish Karir Cc: brian@icair.org, midcom@ietf.org, aaron@panamsat.com, spencer.dawkins@fnc.fujitsu.com Reply-To: mankin@east.isi.edu Subject: Re: [midcom] Re: I-D ACTION:draft-carpenter-midtax-00.txt In-Reply-To: Your message of Thu, 01 Feb 2001 16:13:24 -0500. Date: Thu, 01 Feb 2001 17:05:54 -0500 From: Allison Mankin Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Manish, Here's the text your mail addresses: > Many TCP PEPs are proprietary and > have been characterised in the open Internet primarily when they > introduce interoperability errors with standard TCP. As with TLGs, > there are circumstances in which a TCP PEP is seen to meet needs not > otherwise met. For example, a TCP PEP may provide re-spacing of ACKs > that have been bunched together by a link with bursty service, thus > avoiding undesireable data segment bursts. The PILC (Performance > Implications of Link Characteristics) working group has analyzed > types of TCP PEPs and their applicability [PILCPEP]. The section does not say that PEPs are "mainly" proprietary, but does want to draw attention to the impact of proprieatry ones. Knowledge of the range of vendors suggests there is a good number of proprietary ones, and some measurement studies suggest that the proprietary ones can be noticed/recognized when they break something. Maybe the wording about "errors" could be improved. On non-proprietary forms of PEPs, the section is meant to imply that there's detail in the PILCPEC document cited. SNOOP is discussed there, for instance. It seems the wording could be improved to make sure that the pointer is clear. PILCPEP has a fairly long references section, which includes both publicly documented and available spoofers, and urls for some products. There's a plan to update those references before the document progresses (and also comments on PILCPEP are timely and welcome). Allison (speaking for PILCPEP as its AD :) > Date: Thu, 01 Feb 2001 16:13:24 EST > Subject: [midcom] Re: I-D ACTION:draft-carpenter-midtax-00.txt > From: Manish Karir > -------- > > > Brian, > > Overall I thought this was quite a good start for the midcom > group, finally we can atleast all try to agree on what > a middle box is?. and what different types they can be.. > > However, I thought the section on TCP spoofers was somewhat inaccurate... > section 2.1.5 > > I dont think its correct to say that TCP spoofers are mainly propritary, > some implementations are freely available..moreover, it is also > incorrect to say that they have been charaterized only when they > introduce interoperability problems with standard TCP. TCP spoofers > have been studied quite extensively. Correct implementations interoperate > quite seamlessly with standard TCP. It is also wrong to say that > they introduce not only TCP errors, but also changes in TCP adaptive > behaviour. Correct implementations do not introduce any TCP errors, > and the changes that the introduce in TCP behavior are intentional > and desirable. Note: they are only used in cases where the modifications > are desired. > > A few references: > Snoop Protocol > http://www.cs.berkeley.edu/~hari/papers/snoop.html > TCP Connection Splitting > http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_TR_99-34/CSHCN_TR_99-34.pht > ml > http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_TR_99-11/CSHCN_TR_99-11.pht > ml > http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_MS_99-7/CSHCN_MS_99-7.phtml > > manish karir > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 18:28: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 SAA14399 for ; Thu, 1 Feb 2001 18:28:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04126; Thu, 1 Feb 2001 18:16:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04014 for ; Thu, 1 Feb 2001 18:09:09 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14052 for ; Thu, 1 Feb 2001 18:09:05 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA62152; Thu, 1 Feb 2001 15:08:21 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA06892; Thu, 1 Feb 2001 15:08:20 -0800 Message-ID: <3A79EB7C.F8FA47B2@hursley.ibm.com> Date: Thu, 01 Feb 2001 17:04:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Manish Karir CC: mankin@east.isi.edu, midcom@ietf.org, aaron@panamsat.com, spencer.dawkins@fnc.fujitsu.com Subject: Re: [midcom] Re: I-D ACTION:draft-carpenter-midtax-00.txt References: <10102012205.AA17209@maia.east.isi.edu> 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 Manish, > > Brian, > > > > Overall I thought this was quite a good start for the midcom > > group, finally we can atleast all try to agree on what > > a middle box is?. and what different types they can be.. The draft is not aimed specifically at midcom - it's currently an orphan - but, hey, if midcom likes it who am I to complain? Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 1 18:48: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 SAA14845 for ; Thu, 1 Feb 2001 18:48:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04562; Thu, 1 Feb 2001 18:38:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04254 for ; Thu, 1 Feb 2001 18:28:40 -0500 (EST) Received: from splice.east.isi.edu (splice.east.isi.edu [38.245.76.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14412 for ; Thu, 1 Feb 2001 18:28:38 -0500 (EST) Received: (from dartisie@localhost) by splice.east.isi.edu (8.9.3/8.9.3) id XAA37189 for midcom@ietf.org; Thu, 1 Feb 2001 23:40:42 GMT (envelope-from dartisie) Date: Thu, 1 Feb 2001 23:40:42 GMT From: Allison Mankin Message-Id: <200102012340.XAA37189@splice.east.isi.edu> To: midcom@ietf.org Subject: [midcom] What is the security approach for authorization? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I wonder if anyone can point me to the IETF's protocols related to authorization of individuals, say a good survey of what there is and how it is used? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Feb 2 10:43: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 KAA12466 for ; Fri, 2 Feb 2001 10:43:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20389; Fri, 2 Feb 2001 10:27:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20304 for ; Fri, 2 Feb 2001 10:24:43 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11759 for ; Fri, 2 Feb 2001 10:24:42 -0500 (EST) 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 HAA25682; Fri, 2 Feb 2001 07:24:14 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id AFY01927; Fri, 2 Feb 2001 07:24:09 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.90 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: <14970.53533.181915.704947@localhost.localdomain> Date: Fri, 2 Feb 2001 10:24:13 -0500 To: midcom@ietf.org, brian@icair.org Subject: Re: [midcom] Re: I-D ACTION:draft-carpenter-midtax-00.txt In-Reply-To: References: <200102011817.KAA19930@boreas.isi.edu> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Brian, it seems that the only reason an HTTP proxy is not an ALG in your taxonomy is that you don't think ALGs terminate sessions, they only do field substitution. I think of ALGs as terminating sessions (anything that doesn't terminate a session is some kind of relay), and I think of HTTP proxies as a special case of ALG. I would add what I call application-level replicators, also known as application-level multicast "routers". Example: CU-SeeMe. Oh, and relays are known in some circles as interworking functions. See you ... Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Feb 2 11:19:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13698 for ; Fri, 2 Feb 2001 11:19:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21092; Fri, 2 Feb 2001 11:04:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20792 for ; Fri, 2 Feb 2001 10:56:42 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12900 for ; Fri, 2 Feb 2001 10:56:41 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA44110; Fri, 2 Feb 2001 07:56:07 -0800 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 HAA17650; Fri, 2 Feb 2001 07:56:11 -0800 Message-ID: <3A7AD81A.7B3FF1CF@hursley.ibm.com> Date: Fri, 02 Feb 2001 09:54:02 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Scott Brim CC: midcom@ietf.org Subject: Re: [midcom] Re: I-D ACTION:draft-carpenter-midtax-00.txt References: <200102011817.KAA19930@boreas.isi.edu> <14970.53533.181915.704947@localhost.localdomain> 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 Hmm. I will need to be more precise in the language since both ways of looking at this are valid. Thanks. Brian Scott Brim wrote: > > Brian, it seems that the only reason an HTTP proxy is not an ALG in your > taxonomy is that you don't think ALGs terminate sessions, they only do > field substitution. I think of ALGs as terminating sessions (anything > that doesn't terminate a session is some kind of relay), and I think of > HTTP proxies as a special case of ALG. > > I would add what I call application-level replicators, also known as > application-level multicast "routers". Example: CU-SeeMe. > > Oh, and relays are known in some circles as interworking functions. > > See you ... Scott > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Feb 2 11:39:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14702 for ; Fri, 2 Feb 2001 11:39:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21338; Fri, 2 Feb 2001 11:28:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21183 for ; Fri, 2 Feb 2001 11:16:18 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13619 for ; Fri, 2 Feb 2001 11:16:16 -0500 (EST) 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 IAA01202; Fri, 2 Feb 2001 08:15:51 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id AFY02467; Fri, 2 Feb 2001 08:15:46 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.90 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: <14970.56629.726676.843068@localhost.localdomain> Date: Fri, 2 Feb 2001 11:15:49 -0500 To: Brian E Carpenter Cc: midcom@ietf.org Subject: Re: [midcom] Re: I-D ACTION:draft-carpenter-midtax-00.txt In-Reply-To: <3A7AD81A.7B3FF1CF@hursley.ibm.com> References: <200102011817.KAA19930@boreas.isi.edu> <14970.53533.181915.704947@localhost.localdomain> <3A7AD81A.7B3FF1CF@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 2 Feb 2001 at 09:54 -0600, Brian E Carpenter apparently wrote: > Hmm. I will need to be more precise in the language since both ways > of looking at this are valid. Thanks. One of the reasons I didn't follow through on a career in plant taxonomy is because I discovered how arbitrary taxonomy can be. Anything works; we'll see what's most useful as we apply it. > Scott Brim wrote: > > > > Brian, it seems that the only reason an HTTP proxy is not an ALG in your > > taxonomy is that you don't think ALGs terminate sessions, they only do > > field substitution. I think of ALGs as terminating sessions (anything > > that doesn't terminate a session is some kind of relay), and I think of > > HTTP proxies as a special case of ALG. > > > > I would add what I call application-level replicators, also known as > > application-level multicast "routers". Example: CU-SeeMe. > > > > Oh, and relays are known in some circles as interworking functions. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Feb 5 09:28:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06527 for ; Mon, 5 Feb 2001 09:28:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18856; Mon, 5 Feb 2001 09:25:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18825 for ; Mon, 5 Feb 2001 09:25:18 -0500 (EST) Received: from cbsvr1.crossbeamsys.com (ns1.crossbeamsys.com [63.96.67.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06473 for ; Mon, 5 Feb 2001 09:25:17 -0500 (EST) Received: by cbsvr1.crossbeamsys.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 09:24:47 -0500 Received: from crossbeamsys.com (PHISH [10.2.1.85]) by cbsvr1.crossbeamsys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DG1GMDFT; Mon, 5 Feb 2001 09:24:36 -0500 From: JC Ferguson To: Allison Mankin Cc: midcom@ietf.org Message-ID: <3A7EB79F.1E9F68C0@crossbeamsys.com> Date: Mon, 05 Feb 2001 09:24:31 -0500 Organization: Crossbeam Systems Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [midcom] What is the security approach for authorization? References: <200102012340.XAA37189@splice.east.isi.edu> 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 A good place to start is the security working groups: http://www.ietf.org/html.charters/wg-dir.html#Security_Area Allison Mankin wrote: > > I wonder if anyone can point me to the IETF's protocols > related to authorization of individuals, say a good survey > of what there is and how it is used? > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- email: jc@crossbeamsys.com / voice:978-318-7555 / fax:978-287-4210 "Control for smilers can't be bought" _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Feb 7 09:58:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01009 for ; Wed, 7 Feb 2001 09:58:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05326; Wed, 7 Feb 2001 09:51:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05295 for ; Wed, 7 Feb 2001 09:51:09 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00746 for ; Wed, 7 Feb 2001 09:51:09 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id GAA15494 for ; Wed, 7 Feb 2001 06:50:42 -0800 (PST) Received: from spandex (rtp-vpn-40.cisco.com [10.82.192.40]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AEH30917; Wed, 7 Feb 2001 06:50:37 -0800 (PST) Message-ID: <013d01c09115$89ee2400$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Wed, 7 Feb 2001 09:52:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] Meeting deadlines and all that Sender: 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 deadline for draft submission prior to the Minneapolis meeting is 23 February at 5pm EST. Please note, however, that the IETF does the bulk of its work via email discussions. Note, as well, that the meetings are not for technology presentations but rather for face time to resolve outstanding issues. What should be inferred from this is that the meeting deadlines should probably not be regarded as having some necessary relationship to progression of the deliverables. For those who have material that they feel needs attention in Minneapolis, it would be useful to get your drafts in early enough for us to be able to get a handle on what the outstanding issues are in advance of the meeting. Many thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Feb 12 14:59: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 OAA20105 for ; Mon, 12 Feb 2001 14:59:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24138; Mon, 12 Feb 2001 14:44:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24113 for ; Mon, 12 Feb 2001 14:44:23 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19660 for ; Mon, 12 Feb 2001 14:44:22 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA11035 for ; Mon, 12 Feb 2001 11:44:07 -0800 (PST) Received: from spandex (rtp-vpn-103.cisco.com [10.82.192.103]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AEO03824; Mon, 12 Feb 2001 11:43:51 -0800 (PST) Message-ID: <030001c0952c$56cdc740$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Mon, 12 Feb 2001 14:45:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [midcom] meeting schedule Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit We're slotted in for Thursday, 22 march at 9am - 11:30am. Here's what we're scheduled against: APP webdav WWW Distributed Authoring and Versioning WG OPS mboned MBONE Deployment WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC idwg Intrusion Detection Exchange Format WG TSV midcom Middlebox Communication WG TSV sigtran Signaling Transport WG Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Feb 13 12:08:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24501 for ; Tue, 13 Feb 2001 12:08:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17021; Tue, 13 Feb 2001 11:50:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16993 for ; Tue, 13 Feb 2001 11:49:59 -0500 (EST) Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23766 for ; Tue, 13 Feb 2001 11:50:00 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G8P00E01G0HV2@firewall.mcit.com> for midcom@ietf.org; Tue, 13 Feb 2001 16:48:17 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G8P00E5PG0H9I@firewall.mcit.com> for midcom@ietf.org; Tue, 13 Feb 2001 16:48:17 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G8P00J01G0F95@dgismtp02.wcomnet.com> for midcom@ietf.org; Tue, 13 Feb 2001 16:48:17 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0G8P00GQOG034L@dgismtp02.wcomnet.com> for midcom@ietf.org; Tue, 13 Feb 2001 16:48:03 +0000 (GMT) Date: Tue, 13 Feb 2001 10:47:57 -0600 From: "Christopher A. Martin" To: midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <004401c095dc$b8b53140$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [midcom] FW: [SIP] NAT, SOCKS 5 proxies, win proxies Sender: 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 folowing thread was actually on the SIP working group mail-list I responded to it there but I thought that we should discuss this in our forum. Another one will follow. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com] On Behalf Of Christopher A. Martin Sent: Friday, February 09, 2001 11:46 PM To: 'Jonathan Rosenberg'; 'John Lazzaro'; sip@lists.bell-labs.com Subject: RE: [SIP] NAT, SOCKS 5 proxies, win proxies Jonathan, I believe that workarounds for firewall inadequacies is no better than removing the firewall. The issue of trust compounds the already insecure nature of SIP without adding a possible avenue of attack from an untrusted public source, through the use of SSL or TLS. by at least creating the functionality at or on the firewall one could at least have a fighting chance. Also as we know vulnerabilities exist, but also can be created by unsound architectures. Already SSL has been determined to be flawed in a lab environment, causing a systme vulnerability that may allow access to the server running it. TLS is supposed to fix alot of the downside to SSL, as well as become the standards based form of SSL, but does it also have the vulnerability? In the draft you state "The other alternative, embedding a SIP ALG within enterprise NATs and firewalls, has not happened. The top commercial firewall and NAT products continue to be SIP-unaware. Even if SIP ALG support were added immediately, there is still a huge installed based of firewalls and NATs that do not understand SIP." As an assumption on my part I would like to go out on a limb and state that just as SIP is evolving, and growing in support, so will the firewall vendors in implementing the solution. I also believe that if an enterprise has made the decision to implement SIP, whether to save money or take advantage of the new functionality offered at such a scale, they have already signaled that they are willing to do what it takes to support SIP. If the existing firewall technology cannot accomodate the business requirement to implement SIP, the enterprise will most likely find a vendor that can. As we know a couple of vendors have already begun to support SIP functionality, and others are following suit. But I've rambled my personal agenda long enough, on to the task at hand. Lets make the standards based methodology needed to propagate SIP to the world through NAT, short lived though it may be. :^) Christopher A. Martin SR. Security Integration Engineer IP Communications Engineering, WorldCom 972-729-4569 > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Thursday, February 08, 2001 9:22 PM > To: 'John Lazzaro'; sip@lists.bell-labs.com > Subject: RE: [SIP] NAT, SOCKS 5 proxies, win proxies > > > All solutions for nat and firewall traversal that assume no enterprise > support are ugly. I have proposed one solution: > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-ent > fw-00.txt > > which relies on a B2BUA outside of the firewall, coupled with > SIP over TLS. > > -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 > > > > -----Original Message----- > > From: John Lazzaro [mailto:lazzaro@CS.Berkeley.EDU] > > Sent: Thursday, February 08, 2001 8:00 PM > > To: sip@lists.bell-labs.com > > Subject: Re: [SIP] NAT, SOCKS 5 proxies, win proxies > > > > > > > > afarhan@rediffmail.com writes: > > > a) SIP and RTP should be able to work from a single UDP port. > > > > This basic idea can work -- sooner or later I hope to write up > > a SIP B2BUA I've implemented for multi-party conference > > initialization that takes this route, mostly following the > > "Activision" techniques described in the recent "Protocol > > Complications with NAT" RFC. The ugliest aspect of this is > > that unless you also want to multiplex RTP and RTCP on the > > same UDP port, you need to have parallel SIP sessions going > > on two ports, on for the RTP port and one for the RTCP port. > > In my SDP-specific implementation for the B2BUA, the NAT > > information specified in the Activision algorithm gets > > embedded in SDP fmt lines by the SIP conference server, > > which is another ugly aspect ... although I believe that > > if the received tag for Via was a hostport, you might be able > > to legally embed this NAT information in the SIP itself. > > > > However, I think there's a big difference between "it can > > be made to work" and "everyone should do it" -- using the > > OS to do multiplexing is a pretty key concept in ALF, and > > when you ignore it all sorts of bad things result. > > One that immediately comes to mind -- you can't connect() > > the socket on the client if you're using the Activision > > algorithm in the multi-party case, since you're using the > > same socket to send RTP to several parties, as well as > > the SIP conference B2BUA. The result is, you can't get > > ICMP feedback to tell if you're UDP packets aren't being > > listened to, and need to use timeouts exclusively ... > > > > -------------------------------------------------------------- > > ----------- > > John Lazzaro -- Research Specialist -- CS Division -- EECS -- > > UC Berkeley > > lazzaro [at] cs [dot] berkeley [dot] edu > www.cs.berkeley.edu/~lazzaro > -------------------------------------------------------------- > ----------- > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Feb 13 23:14:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07379 for ; Tue, 13 Feb 2001 23:14:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00427; Tue, 13 Feb 2001 23:04:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00403 for ; Tue, 13 Feb 2001 23:04:35 -0500 (EST) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.37.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07313 for ; Tue, 13 Feb 2001 23:04:35 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id UAA12384 for midcom@ietf.org; Tue, 13 Feb 2001 20:06:36 -0800 Date: Tue, 13 Feb 2001 20:06:36 -0800 From: John Lazzaro Message-Id: <200102140406.UAA12384@snap.CS.Berkeley.EDU> To: midcom@ietf.org Subject: [midcom] RE: [SIP] NAT, SOCKS 5 proxies, win proxies Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org "Christopher A. Martin" writes [...] > I also believe that if an enterprise has made the decision to > implement SIP, whether to save money or take advantage of the new > functionality offered at such a scale, they have already signaled that > they are willing to do what it takes to support SIP. But how do enterprises make that decision? It happens because "Sparky the change agent" downloads an application demo, gets enthused, and starts a process of building consensus in an organization around the idea. Sparky needs subterfuge to get that application working, though, if a firewall or NAT stands in the way. Enter draft-rosenberg-sip-ent and other such tricks. > If the existing firewall technology cannot accomodate the business > requirement to implement SIP, the enterprise will most likely find a > vendor that can. The real goal of SIP solutions to work around firewalls and NATs is to let sparky do the demo to her manager's manager, who will reorder the priorities of the 10 items on the overworked network administrator's list of things to do, and put "finding a new firewall vendor who supports SIP" at the top. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Feb 14 10:42:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03052 for ; Wed, 14 Feb 2001 10:42:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16528; Wed, 14 Feb 2001 10:30:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16501 for ; Wed, 14 Feb 2001 10:30:47 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02373 for ; Wed, 14 Feb 2001 10:30:48 -0500 (EST) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G8R0023W71E4S@firewall.mcit.com> for midcom@ietf.org; Wed, 14 Feb 2001 15:29:38 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8R0040170KZN@pmismtp04.wcomnet.com>; Wed, 14 Feb 2001 15:29:38 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8R0039370G2A@pmismtp04.wcomnet.com>; Wed, 14 Feb 2001 15:29:05 +0000 (GMT) Date: Wed, 14 Feb 2001 09:29:01 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] RE: [SIP] NAT, SOCKS 5 proxies, win proxies In-reply-to: <200102140406.UAA12384@snap.CS.Berkeley.EDU> To: "'John Lazzaro'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <000901c0969a$dc571b40$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Comments are inline, > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > John Lazzaro > Sent: Tuesday, February 13, 2001 10:07 PM > To: midcom@ietf.org > Subject: [midcom] RE: [SIP] NAT, SOCKS 5 proxies, win proxies > > > > > "Christopher A. Martin" writes > [...] > > > I also believe that if an enterprise has made the decision to > > implement SIP, whether to save money or take advantage of the new > > functionality offered at such a scale, they have already > signaled that > > they are willing to do what it takes to support SIP. > > But how do enterprises make that decision? It happens because > "Sparky the change agent" downloads an application demo, gets > enthused, > and starts a process of building consensus in an organization > around the idea. > Actually this may happen in smaller organizations, but in the larger disciplined organizations IT personnel attend seminars, meet with vendors and attempt to stay on top of current technology. This also applies to the telecommunications departments. And lets not forget the vendor sales people that want to pawn their latest and greatest, they wont let the above individuals forget that theres a new toy in town either. > Sparky needs subterfuge to get that application working, though, if a > firewall or NAT stands in the way. Enter draft-rosenberg-sip-ent and > other such tricks. > For the smaller organizations, where sparky works, if sparky is authorized to download and install programs for testing then sparky should not have a problem connecting it the unprotected side of the firewall and showing off the new gadget. If sparky is not authorized then management most likely wouldnt hear about this cool new toy. In addition, if sparky performs subterfuge on my network, and risks damage to the business operations, then sparky can go look for another job. > > If the existing firewall technology cannot accomodate the business > > requirement to implement SIP, the enterprise will most likely find a > > vendor that can. > > The real goal of SIP solutions to work around firewalls and NATs is to > let sparky do the demo to her manager's manager, who will reorder the > priorities of the 10 items on the overworked network administrator's > list of things to do, and put "finding a new firewall vendor who > supports SIP" at the top. > Thank you, that was my point! The firewall vendor needs to accomodate SIP not the other way around. This thread was trying to find a solution by modifying SIP and/or RTP to accomodate the firewall. Now for testing and prioritiization, if sparky is authorized, and the firewall admin does not wish to make the rules to permit this traffic, hopefully the light will turn on in sparky's head to makes sparky realize that this could be tested on the open network (the unprotected side of the firewall. Then management can see the demo and determine priorities all day long. Thats a lot of "if's" and "and's", but since we're writing a story here let me embellish a little. ;^> Chris > -------------------------------------------------------------- > ----------- > John Lazzaro -- Research Specialist -- CS Division -- EECS -- > UC Berkeley > lazzaro [at] cs [dot] berkeley [dot] edu > www.cs.berkeley.edu/~lazzaro > -------------------------------------------------------------- > ----------- > > _______________________________________________ > 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 Feb 14 10:44:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03233 for ; Wed, 14 Feb 2001 10:44:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16624; Wed, 14 Feb 2001 10:36:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16593 for ; Wed, 14 Feb 2001 10:36:17 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02661 for ; Wed, 14 Feb 2001 10:36:18 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA71616 for ; Wed, 14 Feb 2001 07:35:42 -0800 Received: from hursley.ibm.com (ss5.bld.socks.ibm.com [9.14.4.70]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA20412 for ; Wed, 14 Feb 2001 07:35:46 -0800 Message-ID: <3A8AA552.5A822DFD@hursley.ibm.com> Date: Wed, 14 Feb 2001 09:33:38 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] [Fwd: Middlebox taxonomy draft & BOF] Sender: 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 -------- Subject: Middlebox taxonomy draft & BOF Date: Wed, 14 Feb 2001 09:31:44 -0600 From: Brian E Carpenter Organization: IBM To: ietf@ietf.org If you are interested in middleboxes in general and a draft taxonomy of 20 different types of middlebox... See http://www.ietf.org/internet-drafts/draft-carpenter-midtax-00.txt Plan on attending the midtax BOF in Minneapolis. Ad hoc mailing list thanks to Rob Austein: Post: midtax@lists.hactrn.net (Un)Subscribe: midtax-request@lists.hactrn.net Archive: exists, but no web access to it yet Brian Carpenter _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Feb 14 13:47:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11986 for ; Wed, 14 Feb 2001 13:47:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20046; Wed, 14 Feb 2001 13:33:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20017 for ; Wed, 14 Feb 2001 13:33:38 -0500 (EST) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.37.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10652 for ; Wed, 14 Feb 2001 13:33:39 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id KAA13061 for midcom@ietf.org; Wed, 14 Feb 2001 10:35:36 -0800 Date: Wed, 14 Feb 2001 10:35:36 -0800 From: John Lazzaro Message-Id: <200102141835.KAA13061@snap.CS.Berkeley.EDU> To: midcom@ietf.org Subject: RE: [midcom] RE: [SIP] NAT, SOCKS 5 proxies, win proxies Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org "Christopher A. Martin" writes: > Thank you, that was my point! The firewall vendor needs to accomodate SIP > not the other way around. This thread was trying to find a solution by > modifying SIP and/or RTP to accomodate the firewall. For the record, I think we need both, and my own interest is the latter -- to combine the Activision technique described in RFC 3027 and also in: http://www.alumni.caltech.edu/~dank/peer-nat.html with SIP, for getting UDP RTP and SIP through NAT's. It's not clear to me that this sort of technique has a place in midcom -- I'm still paging through the 20 different types of middeboxes in draft-carpenter-midtax-00.txt to see if it fits anywhere :-). But since its a UDP approach to draft-rosenberg-sip-ent's TCP approach, it does seem to be a valid potential topic for the SIP WG, although given the incredible workload of SIP WG, it certainly isn't a priority ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Feb 22 07:13: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 HAA08294 for ; Thu, 22 Feb 2001 07:13:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13950; Thu, 22 Feb 2001 07:04:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13926 for ; Thu, 22 Feb 2001 07:04:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07860; Thu, 22 Feb 2001 07:04:53 -0500 (EST) Message-Id: <200102221204.HAA07860@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 22 Feb 2001 07:04:52 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-framework-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 : Middlebox Communication Architecture and framework Author(s) : P. Srisuresh, J. Kuthan, J. Rosenberg Filename : draft-ietf-midcom-framework-00.txt Pages : 19 Date : 21-Feb-01 There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Many of the applications in use are complex and the datagrams pertaining to these applications cannot be identified by merely examining packet headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-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-framework-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-framework-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: <20010221145558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010221145558.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Feb 23 13:36:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14164 for ; Fri, 23 Feb 2001 13:36:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22227; Fri, 23 Feb 2001 13:27:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22196 for ; Fri, 23 Feb 2001 13:27:30 -0500 (EST) Received: from pop.mainstreet.net (smtp.mainstreet.net [207.5.0.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13419 for ; Fri, 23 Feb 2001 13:27:28 -0500 (EST) Received: from saqibj (saqibj.mainstreet.net [207.5.1.168]) by pop.mainstreet.net (8.9.2/8.9.2) with SMTP id KAA27128 for ; Fri, 23 Feb 2001 10:27:25 -0800 (PST) Reply-To: From: "Saqib Jang" To: Date: Fri, 23 Feb 2001 10:34:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [midcom] Questions Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I've recently joined the midcom mailing list and have a couple of quick questions. Are there specific assumptions being made in the midcom work about where the boxes with application intelligence (e.g. gatekeepers) and middle boxes reside? Specifically, is the assumption that both types of systems will be on the same side of a firewall or on different sides of a firewall. I'm concerned about the security implications of a middlebox being "controlled" by a GK-type of box that is in a different IP network? Plus the middlebox protocol would itself need to be able to easily traverse firewalls. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Feb 27 09:24: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 JAA09479 for ; Tue, 27 Feb 2001 09:24:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24365; Tue, 27 Feb 2001 09:13:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24337 for ; Tue, 27 Feb 2001 09:13:45 -0500 (EST) Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08991 for ; Tue, 27 Feb 2001 09:13:43 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G9F00ICW64SW5@firewall.mcit.com> for midcom@ietf.org; Tue, 27 Feb 2001 14:12:28 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9F0020164MHP@pmismtp02.wcomnet.com> for midcom@ietf.org; Tue, 27 Feb 2001 14:12:28 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9F000IM64E7U@pmismtp02.wcomnet.com> for midcom@ietf.org; Tue, 27 Feb 2001 14:12:14 +0000 (GMT) Date: Tue, 27 Feb 2001 08:12:11 -0600 From: "Christopher A. Martin" To: midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <000b01c0a0c7$47603f80$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [midcom] (no subject) Sender: 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 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 : SIP through NAT Enabled Firewall Callflows Author(s) : Christopher A. Martin, Alan Johnston Filename : draft-martin-midcom-sip-natfw-callflows-00.txt Pages : 32 Date : 22-Feb-01 This document is intended to define the basic minimum requirement for the operation of SIP through NAT enabled firewalls; both call flow, as well as firewall and NAT functionality will be addressed. The underlying intent is to offer guidance and identify specific considerations to the global community for the development of compliant products for the rapid deployment of SIP. It does not address control by external proxies or firewall control mechanisms, or DNS host naming conventions between private and public realms. However, these flows do give an idea of the information exchange necessary between the Middlebox (NAT and firewall) and the MIDCOM agent (transparent SIP proxy) [4]. ftp://ftp.ietf.org/internet-drafts/draft-martin-midcom-sip-natfw-callflows-0 0.txt Christopher A. Martin Engineer, IP Communication Engineering WORLDCOM 972.729.4569 _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Feb 27 12:27:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19298 for ; Tue, 27 Feb 2001 12:27:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27765; Tue, 27 Feb 2001 12:12:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27734 for ; Tue, 27 Feb 2001 12:12:26 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18571 for ; Tue, 27 Feb 2001 12:12:24 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA28747; Tue, 27 Feb 2001 09:12:13 -0800 (PST) Received: from spandex (rtp-vpn-31.cisco.com [10.82.192.31]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AFU37531; Tue, 27 Feb 2001 09:11:41 -0800 (PST) Message-ID: <037601c0a0e0$97a70dc0$d45904d1@cisco.com> From: "Melinda Shore" To: , References: <000b01c0a0c7$47603f80$6401010a@mcit.com> Subject: Re: [midcom] (no subject) Date: Tue, 27 Feb 2001 12:13:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > This draft is a work item of the Middlebox Communication Working Group of > the IETF. To clarify: This draft is relevant to both midcom deliverables, but is not a work item itself. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Feb 27 13:23:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22007 for ; Tue, 27 Feb 2001 13:23:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29034; Tue, 27 Feb 2001 13:09:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29003 for ; Tue, 27 Feb 2001 13:09:28 -0500 (EST) Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21286 for ; Tue, 27 Feb 2001 13:09:27 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V6.0-24 #47741) with ESMTP id <0G9F00E7CGJP90@firewall.mcit.com> for midcom@ietf.org; Tue, 27 Feb 2001 17:57:25 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9F00701GJNFO@pmismtp02.wcomnet.com>; Tue, 27 Feb 2001 17:57:25 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9F0064MGJDWI@pmismtp02.wcomnet.com>; Tue, 27 Feb 2001 17:57:14 +0000 (GMT) Date: Tue, 27 Feb 2001 11:57:09 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] (no subject) In-reply-to: <037601c0a0e0$97a70dc0$d45904d1@cisco.com> To: "'Melinda Shore'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <003e01c0a0e6$b4bd4900$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, February 27, 2001 11:13 AM > To: christopher.a.martin@wcom.com; midcom@ietf.org > Subject: Re: [midcom] (no subject) > > > > This draft is a work item of the Middlebox Communication > Working Group of > > the IETF. Sorry, bad choice of words. The draft is intended to be a guide to the operation of SIP through NAT and tasks to be accomplished by the firewall/middlebox. > > To clarify: This draft is relevant to both midcom > deliverables, but is not a work item itself. > > Melinda > > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom